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Use this guide to understand the MPLS technology and MPLS applications functions, and to configure 
MPLS and other feature modules deploying the MPLS applications. 


| Documentation and Release Notes 


To obtain the most current version of all Juniper Networks’ technical documentation, see the product 


documentation page on the Juniper Networks website at https://www.juniper.net/documentation/. 


If the information in the latest release notes differs from the information in the documentation, follow the 
product Release Notes. 


Juniper Networks Books publishes books by Juniper Networks engineers and subject matter experts. 
These books go beyond the technical documentation to explore the nuances of network architecture, 
deployment, and administration. The current list can be viewed at https://www.juniper.net/books. 


| Using the Examples in This Manual 


If you want to use the examples in this manual, you can use the load merge or the load merge relative 
command. These commands cause the software to merge the incoming configuration into the current 
candidate configuration. The example does not become active until you commit the candidate configuration. 


If the example configuration contains the top level of the hierarchy (or multiple hierarchies), the example 
is a full example. In this case, use the load merge command. 


x\viii 


If the example configuration does not start at the top level of the hierarchy, the example is a snippet. In 
this case, use the load merge relative command. These procedures are described in the following sections. 


Merging a Full Example 


To merge a full example, follow these steps: 


1. From the HTML or PDF version of the manual, copy a configuration example into a text file, save the 
file with a name, and copy the file to a directory on your routing platform. 


For example, copy the following configuration to a file and name the file ex-script.conf. Copy the 
ex-script.conf file to the /var/tmp directory on your routing platform. 


system { 
scripts { 
commit { 
file ex-script.xsl; 


} 
interfaces { 
fxpO { 
disable; 
unit O { 
family inet { 
address 10.0.0.1/24; 


2. Merge the contents of the file into your routing platform configuration by issuing the load merge 


configuration mode command: 


[edit] 
user@host# load merge /var/tmp/ex-script.conf 


load complete 
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Merging a Snippet 


To merge a snippet, follow these steps: 


1. From the HTML or PDF version of the manual, copy a configuration snippet into a text file, save the 
file with a name, and copy the file to a directory on your routing platform. 


For example, copy the following snippet to a file and name the file ex-script-snippet.conf. Copy the 
ex-script-snippet.conf file to the /var/tmp directory on your routing platform. 


commit { 
file ex-script-snippet.xsl; } 


2. Move to the hierarchy level that is relevant for this snippet by issuing the following configuration mode 
command: 
[edit] 


user@host# edit system scripts 
[edit system scripts] 


3. Merge the contents of the file into your routing platform configuration by issuing the load merge 
relative configuration mode command: 


[edit system scripts] 
user@host# load merge relative /var/tmp/ex-script-snippet.conf 
load complete 


For more information about the load command, see CLI Explorer. 


| Documentation Conventions 


Table 1 on page | defines notice icons used in this guide. 


Table 1: Notice Icons 


Meaning 


Informational note 


Caution 


Warning 


Laser warning 


Tip 


Best practice 


oO > > P Oo: 


Description 


Indicates important features or instructions. 


Indicates a situation that might result in loss of data or hardware 


damage. 


Alerts you to the risk of personal injury or death. 


Alerts you to the risk of personal injury from a laser. 


Indicates helpful information. 


Alerts you to a recommended use or implementation. 


Table 2 on page | defines the text and syntax conventions used in this guide. 


Table 2: Text and Syntax Conventions 


Convention 


Bold text like this 


Fixed-width text like this 


Italic text like this 


Description 


Represents text that you type. 


Represents output that appears on 
the terminal screen. 


e Introduces or emphasizes important 


new terms. 
e Identifies guide names. 


e Identifies RFC and Internet draft 
titles. 


Examples 


To enter configuration mode, type 
the configure command: 


user@host> configure 


user@host> show chassis alarms 


No alarms currently active 


e A policy term is a named structure 
that defines match conditions and 
actions. 


e Junos OS CLI User Guide 


e RFC 1997, BGP Communities 
Attribute 


Table 2: Text and Syntax Conventions (continued) 


Convention 


Italic text like this 


Text like this 


< > (angle brackets) 


| (pipe symbol) 


# (pound sign) 


[ ] (square brackets) 


Indention and braces ( { }) 


; (semicolon) 


GUI Conventions 


Description 


Represents variables (options for 
which you substitute a value) in 
commands or configuration 
statements. 


Represents names of configuration 
statements, commands, files, and 
directories; configuration hierarchy 
levels; or labels on routing platform 
components. 


Encloses optional keywords or 
variables. 


Indicates a choice between the 
mutually exclusive keywords or 
variables on either side of the symbol. 
The set of choices is often enclosed 
in parentheses for clarity. 


Indicates a comment specified on the 
same line as the configuration 
statement to which it applies. 


Encloses a variable for which you can 
substitute one or more values. 


Identifies a level in the configuration 
hierarchy. 


Identifies a leaf statement at a 
configuration hierarchy level. 


Examples 


Configure the machine’s domain 


name: 


[edit] 
root@# set system domain-name 
domain-name 


e Toconfigure a stub area, include 
the stub statement at the [edit 
protocols ospf area area-id] 
hierarchy level. 


e The console port is labeled 
CONSOLE. 


stub <default-metric metric>; 


broadcast | multicast 


(string1 | string2 | string3) 


rsvp { # Required for dynamic MPLS 
only 


community name members [ 
community-ids ] 


[edit] 
routing-options { 
static { 
route default { 
nexthop address; 
retain; 


Table 2: Text and Syntax Conventions (continued) 


Convention Description Examples 
Bold text like this Represents graphical user interface e Inthe Logical Interfaces box, select 
(GUI) items you click or select. All Interfaces. 


e Tocancel the configuration, click 


Cancel. 
> (bold right angle bracket) Separates levels in a hierarchy of In the configuration editor hierarchy, 
menu selections. select Protocols>Ospf. 


| Documentation Feedback 


We encourage you to provide feedback so that we can improve our documentation. You can use either 


of the following methods: 


e Online feedback system—Click TechLibrary Feedback, on the lower right of any page on the Juniper 
Networks TechLibrary site, and do one of the following: 


ga Feedback - 


Is this page helpful? 


e Click the thumbs-up icon if the information on the page was helpful to you. 


e Click the thumbs-down icon if the information on the page was not helpful to you or if you have 
suggestions for improvement, and use the pop-up form to provide feedback. 


e E-mail—Send your comments to techpubs-comments@juniper.net. Include the document or topic name, 
URL or page number, and software version (if applicable). 


| Requesting Technical Support 


Technical product support is available through the Juniper Networks Technical Assistance Center (JTAC). 
If you are a customer with an active Juniper Care or Partner Support Services support contract, or are 


covered under warranty, and need post-sales technical support, you can access our tools and resources 
online or open a case with JTAC. 


e JTAC policies—For a complete understanding of our JTAC procedures and policies, review the JTAC User 
Guide located at https://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf. 


e Product warranties—For product warranty information, visit https://www.juniper.net/support/warranty/. 


e JTAC hours of operation—The JTAC centers have resources available 24 hours a day, 7 days a week, 
365 days a year. 


Self-Help Online Tools and Resources 


For quick and easy problem resolution, Juniper Networks has designed an online self-service portal called 
the Customer Support Center (CSC) that provides you with the following features: 


Find CSC offerings: https://www.juniper.net/customers/support/ 


Search for known bugs: https://prsearch.juniper.net/ 


Find product documentation: https://www.juniper.net/documentation/ 


Find solutions and answer questions using our Knowledge Base: https://kb.juniper.net/ 


Download the latest versions of software and review release notes: 


https://www.juniper.net/customers/csc/software/ 


Search technical bulletins for relevant hardware and software notifications: 
https://kb.juniper.net/InfoCenter/ 


e Join and participate in the Juniper Networks Community Forum: 
https://www.juniper.net/company/communities/ 


e Create a service request online: https://myjuniper.juniper.net 
To verify service entitlement by product serial number, use our Serial Number Entitlement (SNE) Tool: 


https://entitlementsearch.juniper.net/entitlementsearch/ 


Creating a Service Request with JTAC 


You can create a service request with JTAC on the Web or by telephone. 
e Visit https://myjuniper.juniper.net. 
e Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico). 


For international or direct-dial options in countries without toll-free numbers, see 
https://support.juniper.net/support/requesting-support/. 
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MPLS Overview 
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Multiprotocol Label Switching (MPLS) is a protocol that uses labels to route packets instead of using IP 
addresses. In a traditional network, each switch performs an IP routing lookup, determines a next-hop 
based on its routing table, and then forwards a packet to that next-hop. With MPLS, only the first device 
does a routing lookup, and, instead of finding the next-hop, finds the ultimate destination along with a 
path to that destination. The path of an MPLS packet is called a label-switched path (LSP). 


MPLS applies one or more labels to a packet so it can follow the LSP to the destination. Each switch pops 
off its label and sends the packet to the next switch label in the sequence. 


The Junos OS includes everything you need to configure MPLS. You do not need to install any additional 
programs or protocols. MPLS is supported on switches with a subset of the commands supported on 
routers. The Junos MPLS-configured switches can interact with each other and with Junos MPLS-configured 
routers. 


MPLS has the following advantages over conventional packet forwarding: 


e Packets arriving on different ports can be assigned different labels. 


e A packet arriving at a particular provider edge (PE) switch can be assigned a label that is different from 
that of the same packet entering the network at a different PE switch. As a result, forwarding decisions 
that depend on the ingress PE switch can be easily made. 


e Sometimes it is desirable to force a packet to follow a particular route that is explicitly chosen at or 
before the time the packet enters the network, rather than letting it follow the route chosen by the 
normal dynamic routing algorithm as the packet travels through the network. In MPLS, a label can be 
used to represent the route so that the packet need not carry the identity of the explicit route. 


This topic describes: 


Why Use MPLS? 


MPLS reduces the use of the forwarding table by using labels instead of the forwarding table. The size of 
forwarding tables on a switch are limited by silicon and using exact matching for forwarding to destination 
devices is cheaper than buying more sophisticated hardware. In addition, MPLS allows you to control 
where and how traffic is routed on your network - this is called traffic engineering. 


Some reasons to use MPLS instead of another switching solution are: 


e MPLS can connect different technologies that would not otherwise be compatible---service providers 
have this compatibility issue when connecting clients with different autonomous systems in their networks. 
In addition, MPLS has a feature called Fast Reroute that provides alternate backups for paths - this 
prevents network degradation in case of a switch failure. 


e e Other IP-based encapsulations such as Generic Route Encapsulation (GRE) or Virtual Extensible Local 
Area Networks (VXLAN) support only two levels of hierarchy, one for the transport tunnel and one piece 
of metadata. Using virtual servers means that you need multiple hierarchy levels. For example, one label 
is needed for top-of-rack (ToR), one label for the egress port that identifies the server, and one for the 
virtual server. 


Why Not Use MPLS? 


There are no protocols to auto-discover MPLS enabled nodes. MPLS protocol just exchanges label values 
for an LSP. They do not create the LSPs. 


You must build the MPLS mesh, switch by switch. We recommend using scripts for this repetitive process. 
MPLS hides suboptimal topologies from BGP where multiple exits may exist for the same route. 


Large LSPs are limited by the circuits they traverse. You can work around this by creating multiple, parallel 
LSPs. 


How Do | Configure MPLS? 

There are three types of switches you must set up for MPLS: 

e Label Edge Router/Switch (LER) or ingress node to the MPLS network. This switch encapsulates the 
packets. 


e Label Switching Routers/Switches (LSR). One or more switches that transfer MPLS packets in the MPLS 
network. 


e Egress router/switch is the final MPLS device that removes the last label before packets leave the MPLS 
network. 


Service providers (SP) use the term provider router (P) for a backbone router/switch doing label switching 
only. The customer-facing router at the SP is called a provider edge router (PE). Each customer needs a 
customer edge router (CE) to communicate with the PE. Customer facing routers typically can terminate 
IP addresses, L83VPNs, L2VPNs/ pseudowires, and VPLS before packets are transferred to the CE. 


Configure the MPLS LER (Ingress) Switch and the Egress Switch 


To configure MPLS, you must first create one or more named paths on the ingress and egress routers. For 
each path, you can specify some or all transit routers in the path, or you can leave it empty. See “Configuring 
the Ingress and Egress Router Addresses for LSPs” on page 485 and “Configuring the Connection Between 
Ingress and Egress Routers” on page 493. 


Configure LSRs for MPLS 
Configure one or more MPLS LSRs by following these steps: 


1. Configure interfaces on each switch to transmit and receive MPLS packets using the usual interface 
command with MPLS appended. For example: 


[edit interfaces ge-0/0/0 unit O] family mpls; 


2. Add those same interfaces under [edit protocols mpls]. For example: 


[edit protocols mpls] 


interface ge-0/0/0; 


3. Configure the interfaces on each switch to handle MPLS labels with a protocol. For example, for LDP: 


[edit protocols Idp] 
Interface ge-0/0/0.0; 


To watch a demo of these configurations, see https://www.youtube.com/watch?v=xegWBCUJ4tE. 


What Does the MPLS Protocol Do? 


Multiprotocol Label Switching (MPLS) is an Internet Engineering Task Force (IETF)-specified framework 
that provides for the designation, routing, forwarding and switching of traffic flows through the network. 
In addition, MPLS: 


Specifies mechanisms to manage traffic flows of various granularities, such as flows between different 
hardware, machines, or even flows between different applications. 


Remains independent of the layer-2 and layer-3 protocols. 


Provides a means to map IP addresses to simple, fixed-length labels used by different packet-forwarding 
and packet-switching technologies. 


Interfaces to existing routing protocols, such as Resource ReSerVation Protocol (RSVP) and Open Shortest 
PathFirst (OSPF). 


Supports IP, ATM, and Frame Relay layer-2 protocols. 
e Uses these additional technologies: 


e FRR: MPLS Fast Reroute improves convergence during a failure by mapping out alternate LSPs in 
advance. 


e Link Protection/ Next-hop backup: A bypass LSP is created for every possible link failure. 
e Node Protection/ Next-hop backup: A bypass LSP is created for every possible switch (node) failure. 


e VPLS: Creates Ethernet multipoint switching service over MPLS and emulates functions of an L2 
switch. 


e L3VPN: IP-based VPN customers get individual virtual routing domains. 


How Does MPLS Interface to Other Protocols? 
Some of the protocols that work with MPLS are: 
e RSVP-TE: Resource Reservation Protocol - Traffic Engineering reserves bandwidth for LSPs. 


e LDP: Label Distribution Protocol is the defacto protocol used for distribution of MPLS packets and is 
usually configured to tunnel inside RSVP-TE. 


IGP: Interior Gateway Protocol is a routing protocol. Edge routers (PE-routers) run BGP between 
themselves to exchange external (customer) prefixes. Edge and core (P) routers run IGP (usually OSPF 
or IS-1S) to find optimum path toward BGP next hops. P- and PE-routers use LDP to exchange labels for 
known IP prefixes (including BGP next hops). LDP indirectly builds end-to-end LSPs across the network 
core. 


BGP: Border Gateway Protocol (BGP) allows policy-based routing to take place, using TCP as its transport 
protocol on port 179 to establish connections. The Junos OS routing protocol software includes BGP 
version 4. You do not configure BGP---configuring interfaces with MPLS and LDP/RSVP establishes the 
labels and the ability to transmit packets. BGP automatically determines the routes packets take. 


OSPF and ISIS: These protocols are used for routing between the MPLS PE and CE. Open Shortest Path 
First (OSPF) is perhaps the most widely used interior gateway protocol (IGP) in large enterprise networks. 
IS-IS, another link-state dynamic routing protocol, is more common in large service provider networks. 
Assuming you're running L3VPN to your customers, on the SP edge between the PE and the CE you can 
run any protocol that your platform supports as a VRF aware instance. 


If | Have Used Cisco MPLS, What Do I Need to Know? 


Cisco Networks and Juniper Networks use different MPLS terminology. 


What Cisco Calls: Juniper Calls: 
affinities admin-groups 
autoroute announce TE shortcuts 
forwarding adjacency LSP-advertise 
tunnel LSP 
make-before-break adaptive 
application-window adjust-interval 
shared risk link groups fate-sharing 


TTL Processing on Incoming MPLS Packets 


The flow chart on Figure 1 on page 7 illustrates TTL processing on incoming MPLS packets. On a transit 


LSR or an egress LER, MPLS pops one or more labels and can push one or more labels. The incoming TTL 


of the packet is determined by the configured TTL processing tunnel model. 


When all of the following conditions are met, the incoming TTL is set to the TTL value found in the 


immediate inner header: 


e The outer label is popped as opposed to being swapped 
e The TTL processing model is configured to pipe 


e The inner header is MPLS or IP 


If any of those conditions is not met, then the incoming TTL is set to the TTL value found in the outermost 
label. In all cases, the TTL values of any further inner labels are ignored. 


When an IP packet is exposed after MPLS pops all the labels that should be popped, MPLS passes the 
packet to IP for further processing, including TTL checking. When the uniform tunnel model for TTL 
processing is in effect, MPLS sets the TTL value of the IP packet to the incoming TTL value that was just 
set. In other words, the TTL value is copied from the outermost label to the IP packet. When the pipe 
model for TTL processing is in effect, the TTL value in the IP header is left unchanged. 


If an IP packet is not exposed by the label popping, then MPLS performs the TTL validation. If the incoming 
TTLis less than 2, the packet is dropped. If innermost packet is IP, an ICMP packet is built and sent. If the 
TTL does not expire and the packet needs to be sent out, the outgoing TTL is determined by the rules for 
outgoing MPLS packets. 


Figure 1: TTL Processing on Incoming MPLS Packets 
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Link-Layer Support in MPLS 


MPLS supports the following link-layer protocols, which are all supported in the Junos OS MPLS 
implementation: 


Point-to-Point Protocol (PPP)—Protocol ID 0x0281, Network Control Protocol (NCP) protocol ID 0x8281. 


Ethernet/Cisco High-level Data Link Control (HDLC)—Ethernet type 0x8847. 


Asynchronous Transfer Mode (ATM)—Subnetwork attachment point encoded (SNAP-encoded) Ethernet 
type 0x8847. Support is included for both point-to-point mode or nonbroadcast multiaccess (NBMA) 
mode. Support is not included for encoding MPLS labels as part of ATM virtual path identifier/virtual 
circuit identifier (VPI/VCl). 


Frame Relay—SNAP-encoded, Ethernet type 0x8847. Support is not included for encoding MPLS labels 
as part of Frame Relay data-link connection identifier (DLCI). 


Generic routing encapsulation (GRE) tunnel—Ethernet type 0x8847. 


MPLS Overview for ACX Series Universal Metro Routers 


Multiprotocol Label Switching (MPLS) provides a mechanism for engineering network traffic patterns that 
is independent of routing tables by assigning short labels to network packets, which describe how to 
forward them through the network. MPLS is independent of any routing protocol and can be used for 
unicast packets. On the ACX Series routers, the following MPLS features are supported: 


e The configuration of a label-switching router (LSR) for processing of label-switched packets and forwarding 
of packets based on their labels. 


e The configuration of an ingress label edge router (LER) where IP packets are encapsulated within MPLS 
packets and forwarded to the MPLS domain, and as an egress LER where MPLS packets are decapsulated 
and the IP packets contained within the MPLS packets are forwarded using information in the IP 
forwarding table. Configuring MPLS on the LER is the same as configuring an LSR. 


e Uniform and pipe mode configuration providing different types of visibility in the MPLS network. Uniform 
mode makes all the nodes that a label-switched path (LSP) traverses visible to nodes outside the LSP 
tunnel. Uniform mode is the default. Pipe mode makes only the LSP ingress and egress points visible to 
nodes outside the LSP tunnel. Pipe mode acts like a circuit and must be enabled with the global 
no-propagate-ttl statement at the [edit protocols mpls] hierarchy level on each router that is in the path 
of the LSP. The no-propagate-ttl statement disables time-to-live (TTL) propagation at the router level 
and affects all RSVP-signalled or LDP-signalled LSPs. Only the global configuration of TTL propagation 
is supported. 


Exception packet handling of IP packets not processed by the normal packet flow through the Packet 


Forwarding Engine. The following types of exception packet handling are supported: 
e Router alert 
e Time-to-live (TTL) expiry value 


e Virtual circuit connection verification (VCCV) 


e LSP hot standby for secondary paths configuration to maintain a path in a hot-standby state enabling 
swift cut over to the secondary path when downstream routers on the current active path indicate 


connectivity problems. 


Redundancy for a label-switched path (LSP) path with the configuration of fast reroute. 


Configuration of link protection to ensure that traffic traversing a specific interface from one router to 
another can continue to reach its destination in the event that this interface fails. 


MPLS for EX Series Switches Overview 


IN THIS SECTION 


@ Benefits of MPLS | 10 
@ = Additional Benefits of MPLS and Traffic Engineering | 10 
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You can configure Junos OS MPLS on Juniper Networks EX Series Ethernet Switches to increase transport 
efficiency in the network. MPLS services can be used to connect various sites to a backbone network and 
to ensure better performance for low-latency applications such as voice over IP (VoIP) and other 
business-critical functions. 


NOTE: MPLS configurations on EX Series switches are compatible with configurations on other 
Juniper Networks devices that support MPLS and MPLS-based circuit cross-connect (CCC). 
MPLS features available on the switches depend upon which switch you are using. For information 
about the software features on the EX Series switches, see Feature Explorer. 


NOTE: MPLS configurations on the switches do not support: 


e Q-in-Q tunneling 


This topic describes: 


Benefits of MPLS 


MPLS has the following advantages over conventional packet forwarding: 


e Packets arriving on different ports can be assigned different labels. 


e A packet arriving at a particular provider edge (PE) switch can be assigned a label that is different from 
that of the same packet entering the network at a different PE switch. As a result, forwarding decisions 
that depend on the ingress PE switch can be easily made. 


e Sometimes it is desirable to force a packet to follow a particular route that is explicitly chosen at or 
before the time the packet enters the network, rather than letting it follow the route chosen by the 
normal dynamic routing algorithm as the packet travels through the network. In MPLS, a label can be 
used to represent the route so that the packet need not carry the identity of the explicit route. 


Additional Benefits of MPLS and Traffic Engineering 


MPLS is the packet-forwarding component of the Junos OS traffic engineering architecture. Traffic 
engineering provides the capabilities to do the following: 


e Route primary paths around known bottlenecks or points of congestion in the network. 


e Provide precise control over how traffic is rerouted when the primary path is faced with single or multiple 
failures. 


e Provide efficient use of available aggregate bandwidth and long-haul fiber by ensuring that certain 
subsets of the network are not overutilized while other subsets of the network along potential alternate 
paths are underutilized. 


e Maximize operational efficiency. 
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e Enhance the traffic-oriented performance characteristics of the network by minimizing packet loss, 


minimizing prolonged periods of congestion, and maximizing throughput. 


e Enhance statistically bound performance characteristics of the network (such as loss ratio, delay variation, 


and transfer delay) required to support a multiservice Internet. 


MPLS Feature Support on QFX Series and EX4600 Switches 


IN THIS SECTION 


@ Supported Features | 11 


This topic describes the MPLS features that are supported on the QFX Series, EX4600, EX4650 switches. 
Be sure to check for any exceptions to this support in “MPLS Limitations on QFX Series and EX4600 


Switches” on page 22. Configuring unsupported statements on the switch does not affect its operation. 


NOTE: EX4600 and EX4650 switches use the same chipset as QFX5100 switches—this is why 
EX Series switches are included here along with QFX Series switches. Other EX Series switches 


also support MPLS but with a different feature set. 


Supported Features 


The tables in this section lists the MPLS features that are supported on the QFX Series, EX4600, EX4650 
switches, and the Junos OS release in which they were introduced. Table 3 on page 11 lists the features 
for QFX10000 switches. Table 4 on page 14 lists the features for QFX3500, QFX5100, QFX5120, QFX5110, 
QFX5200, QFX5210 switches.Table 5 on page 20 lists the features for EX4600 and EX4650 switches. 


Table 3: QFX10000 MPLS Features 


Feature QFX10002 


QFX10000 standalone switch as an 15.1X53-D10 
MPLS provider edge (PE) switch or 
provider switch 


Label edge router (LER) 15.1X53-D10 
Label-switching router (LSR) 15.1X53-D10 
BGP MPLS Ethernet VPN (EVPN) 17.4R1 


QFX10008 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


17.4R1 


QFX10016 


15.1X53-D60 


15.1X53-D60 


15.1X53-D60 


17.4R1 


Table 3: QFX10000 MPLS Features (continued) 


Feature 


BGP route reflectors 


Automatic bandwidth and dynamic 
label-switched path (LSP) count sizing 


BGP labeled unicast 


BGP link state distribution 


Carrier-of-carriers and interprovider 
Layer 3 VPNs 


Entropy labels 
Ethernet-over-MPLS (L2 circuit) 
Fast reroute, one-to-one local 
protection and many-to-one local 


protection 


Fast reroute using detours and 
secondary LSP 


Flexible Ethernet services 


Firewall filters 


RSVP graceful restart for OSPF 


IP-over-MPLS LSPs, both static and 
dynamic links 


IPvé tunneling over an IPv4 network 
(6PE) 


LDP tunneling over RSVP 


L2 Circuit on aggregated interfaces 


L3VPNs for both IPv4 and IPv6é 


QFX10002 


15.1X53-D10 


15.1X53-D60 


15.1X53-D10 


17.1R1 


17.1R1 


17.2R1 


15.1X53-D60 


15.1X53-D10 


15.1X53-D10 


17.3R1 


15.1X53-D30 


15.1X53-D10 


15.1X53-D10 


15.1X53-D10 


15.1X53-D10 


17.3R1 


15.1X53-D10 


QFX10008 


15.1X53-D30 


15.1X53-D60, 17.2R1 


15.1X53-D30 


17.1R1 


17.1R1 


17.2R1 


15.1X53-D60 


15.1X53-D30 


15.1X53-D30 


17.3R1 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


17.3R1 


15.1X53-D30 
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QFX10016 


15.1X53-D60 


15.1X53-D60, 17.2R1 


15.1X53-D60 


17.1R1 


17.1R1 


17.2R1 


15.1X53-D60 


15.1X53-D60 


15.1X53-D60 


17.3R1 


15.1X53-D60 


15.1X53-D60 


15.1X53-D60 


15.1X53-D60 


15.1X53-D60 


17.3R1 


15.1X53-D60 


Table 3: QFX10000 MPLS Features (continued) 


Feature 


MPLS over integrated bridging and 
routing (IRB) interfaces 


MPLS over UDP 

MTU signaling in RSVP 

Operation, Administration, and 
Maintenance (OAM) including ping, 
traceroute and Bidirectional 
Forwarding Detection (BFD) 


OSPF TE 


OSPF v2 as an interior gateway 
protocol (IGP) 


Path Computation Element Protocol 
for RSVP-TE 


Pseudowire-over-aggregated Ethernet 
interfaces (core-facing interface) 


RSVP support, including bandwidth 
allocation and traffic engineering 


RSVP fast reroute (FRR), including 
link-protection, node-link-protection, 
fast reroute using detours, and 
secondary LSP 

SNMP MIB support 


Static and dynamic LSPs 


Traffic engineering extensions 
(OSPF-TE, IS-IS-TE) 


QFX10002 


15.1X53-D10 


18.3R1 


15.1X53-D10 


15.1X53-D10 


15.1X53-D10 


15.1X53-D10 


16.3R1 


15.1X53-D60 (supported 
only on 
network-to-network (NNI) 
interfaces) 


15.1X53-D10 


15.1X53-D10 


15.1X53-D10 


15.1X53-D10 


15.1X53-D10 


QFX10008 


15.1X53-D30 


18.3R1 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


16.3R1 


15.1X53-D60 


(supported only on 


NNI interfaces) 


15.1X53-D30 


15.1X53-D30 


15.1X54-D30 


15.1X53-D30 


15.1X53-D30 


QFX10016 


15.1X53-D60 


18.3R1 


15.1X53-D60 


15.1X53-D60 


15.1X53-D60 


15.1X53-D60 


16.3R1 


15.1X53-D60 


(supported only on NNI 


interfaces) 


15.1X53-D60 


15.1X53-D60 


15.1X53-D60 


15.1X53-D60 


15.1X53-D60 
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Table 3: QFX10000 MPLS Features (continued) 


Feature QFX10002 


Traffic engineering (TE) 15.1X53-D10 


Automatic bandwidth allocation and 
RSVP bandwidth 


Dynamic bandwidth management 
using ingress LSP splitting and merging 


Virtual routing and forwarding (VRF) 15.1X53-D10 
label support 


QFX10008 


15.1X53-D30 


15.1X53-D30 
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QFX10016 


15.1X53-D60 


15.1X53-D60 


Table 4: QFX3500, QFX5100, QFX5110, QFX5120, QFX5200, QFX5210 MPLS Features 


Feature QFX3500 QFX5100 

QF®&X Series 12.2X50-D10 13.2X51-D15 15.1X53-D210 
standalone 

switches as VC/VCF 

MPLS (14.1X53-D30) 


provider edge 
(PE) switches 
or provider 
switches 


Label edge 


router (LER) 
VC/VCF 


(14.1X53-D30) 


Label-switching | 12.2X50-D10 | 13.2X51-D15 = 15.1X53-D210 


router (LSR) 
VC/VCF 
(14.1X53-D30) 
Automatic Not supported 13.2X51-D15 = 15.1X53-D210 
bandwidth 
‘ VC/VCF 
allocation on 
LSPs (14.1X53-D30) 
BGP labeled 12.2X50-D10 13.2X51-D15 | 15.1X53-D210 
unicast 


VC/VCF 
(14.1X53-D30) 


QFX5110 


12.2X50-D10  13.2X51-D15 | 15.1X53-D210 


QFX5120 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


QFX5200 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


QFX5210 


18.1R1 


18.1R1 


18.1R1 


18.1R1 


18.1R1 
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Table 4: QFX3500, QFX5100, QFX5110, QFX5120, QFX5200, QFX5210 MPLS Features (continued) 


Feature 


BGP link state 
distribution 


BGP route 
reflector 


Carrier-to-carrier 
and 
interprovider 
BGP Layer 3 
VPNs 


Class of 
service (CoS 
or QoS) for 
MPLS traffic 


Dynamic 
label-switched 
path (LSP) 
count sizing: 
TE++ 


Equal-cost 
multipath 
(ECMP) at 
LSRs: 


e SWAP 

e PHP 

e L38VPN 

e L2 Circuit 


Entropy labels 


Bhanetoves VPLS 
( L2 Circuit) 


QFX3500 


Not supported 


15.1X53-D10 


14.1X53-D15 


12.3X50-D10 


Not supported 


Not supported 


Not supported 


14.1X53-D10 


QFX5100 


17.1R1 


15.1X53-D30 


14.1X53-D15 


VC/VCF 
(14.1X53-D30) 


13.2X51-D15 


VC/VCF 
(14.1X53-D30) 


17.2R1 


VC/VCF 
17.2R1 


14.1X53-D35 
(Supported 
only on label 
stack. Not 
supported on 
flow label, 
entropy label, 
or ECMP 
label) 


Not supported 


14.1X53-D10 


VC/VCF 
(14.1X53-D30) 


QFX5110 


17.1R1 


15.1X53-D210 


15.1X53-D210 


15.1X53-D210 


17.2R1 


VC/VCF 
17.2R1 


15.1X53-D210 
(Supported 
only on label 
stack. Not 
supported on 
flow label, 
entropy label, 
or ECMP 
label) 


Not supported 


15.1X53-D210 


QFX5120 QFX5200 
18.3R1 17.1R1 
18.3R1 15.1X53-D30 
18.3R1 15.1X53-D30 
18.3R1 15.1X53-D30 
18.3R1 17.2R1 
18.3R1 15.1X53-D30 
(Supported 

only on label 

stack. Not 

supported on 

flow label, 

entropy label, 

or ECMP 

label) 

Not supported | Notsupported 
18.3R1 15.1X53-D30 


QFX5210 


18.1R1 


18.1R1 


18.1R1 


18.1R1 


18.1R1 


18.1R1 


Not supported 


18.1R1 
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Table 4: QFX3500, QFX5100, QFX5110, QFX5120, QFX5200, QFX5210 MPLS Features (continued) 


Feature QFX3500 


Fast reroute 14.1X53-D10 
(FRR), 

one-to-one 

local 

protection and 

many-to-one 

local 

protection 


FRR using 
detours and 


Not supported 


secondary LSP 


Firewall filters = 12.3X50-D10 


Flow-aware Not supported 
transport of 
pseudowires 
(FAT) flow 
labels 

RSVP graceful | 12.2X50-D10 
restart for 


OSPF 


Traffic 


engineering 


12.2X50-D10 


extensions 
(OSPF-TE, 
1S-IS-TE) 


IP-over-MPLS 
LSPs, both 
static and 


12.2X50-D10 


dynamic links 


QFX5100 


14.1X53-D10 


Not supported 


13.2X51-D15 


VC/VCF 
(14.1X53-D30) 


Not supported 


13.2X51-D15 


VC/VCF 
(14.1X53-D30) 


13.2X51-D15 


VC/VCF 
(14.1X53-D30) 


13.2X51-D15 


VC/VCF 
(14.1X53-D30) 


QFX5110 


15.1X53-D210 


Not supported 


15.1X53-D210 


Not supported 


15.1X53-D210 


15.1X53-D210 


15.1X53-D210 


QFX5120 


18.3R1 


Not supported 


18.3R1 


Not supported 


18.3R1 


18.3R1 


18.3R1 


QFX5200 


15.1X53-D30 


Not supported 


15.1X53-D30 


Not supported 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


QFX5210 


18.1R1 


Not supported 


18.1R1 


Not supported 


18.1R1 


18.1R1 


18.1R1 


Table 4: QFX3500, QFX5100, QFX5110, QFX5120, QFX5200, QFX5210 MPLS Features (continued) 


Feature 


IPv6 tunneling 
over an MPLS 
IPv4 network 
(6PE) 


IPv6 over an 
MPLS core 
network 


LDP tunneling 
over RSVP 


Layer 3 VPNs 
for both IPv4 
and IPv6é 


Loop-free 
alternate 
(LFA) 


MPLS over 
integrated 
bridging and 
routing (IRB) 
interfaces 


MTU signaling 
in RSVP 


QFX3500 


12.3X50-D10 


Not supported 


12.2X50-D10 


12.3X50-D10 


Not supported 


Not supported 


12.3X50-D10 


QFX5100 


13.2X51-D15 
VC/VCF 
(14.1X53-D30) 


Not supported 


13.2X51-D15 


VC/VCF 
(14.1X53-D30) 


13.2X51-D15 


VC/VCF 
(14.1X53-D30) 


13.2X51-D15 


VC/VCF 
(14.1X53-D30) 


14.1X53-D40 


13.2X51-D15 


VC/VCF 
(14.1X53-D30) 


QFX5110 


15.1X53-D210 


Not supported 


15.1X53-D210 


15.1X53-D210 


15.1X53-D210 


18.1R1 


15.1X53-D210 


QFX5120 


18.3R1 


Not supported 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


QFX5200 


15.1X53-D30 


Not supported 


15.1X53-D30 


15.1X53-D30 


18.1R1 


18.1R1 


15.1X53-D30 


QFX5210 


18.1R1 


Not supported 


18.1R1 


18.1R1 


18.1R1 


18.1R1 


18.1R1 
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Table 4: QFX3500, QFX5100, QFX5110, QFX5120, QFX5200, QFX5210 MPLS Features (continued) 


Feature QFX3500 QFX5100 QFX5110 
Operation, 12.3X50-D10 13.2X51-D15 | 15.1X53-D210 
Administration, 
VC/VCF 
and 
Maintenance (14.1X53-D30) 
(OAM) 
including 
MPLS ping, 
traceroute, 
and BFD 
OSPF TE 12.3X50-D10 13.2X51-D15 | 15.1X53-D210 
OSPFv2 asan 12.2X50-D10 13.2X51-D15 | 15.1X53-D210 
interior 
VC/VCF 
gateway 
(14.1X53-D30) 
protocol 
Path Not supported 17.4R1 17.4R1 
Computation 
Element 
Protocol for 
RSVP-TE 
Pachieoragel §=6914.1X53-D10 14.1X53-D15  15.1X53-D210 
Ethernet 
; VC/VCF 
interfaces 
; (14.1X53-D30) 
(core-facing 
interface) 
RSVP 12.2X50-D10 13.2X51-D15 | 15.1X53-D210 
automatic 
bandwidth Mere 


(14.1X53-D30) 


QFX5120 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


QFX5200 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


17.4R1 


15.1X53-D30 


15.1X53-D30 


QFX5210 


18.1R1 


18.1R1 


18.1R1 


18.1R1 


18.1R1 


18.1R1 
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Table 4: QFX3500, QFX5100, QFX5110, QFX5120, QFX5200, QFX5210 MPLS Features (continued) 


Feature 


RSVP fast 
reroute (FRR), 
including 
link-protection, 
nodetnicprotedion, 
fast reroute 
using detours, 
and secondary 
LSP 


RSVP-TE 
extensions 
(IS-IS and 
OSPF) 


SNMP MIB 
support 


Static and 
dynamic LSPs 


Traffic 
engineering 
(TE) automatic 
bandwidth 
allocation on 
LSPs 


Virtual routing 
and 
forwarding 
(VRF) label 
support 


VRF support 
in IRB 
Interfaces ina 
Layer 3 VPN 


QFX3500 


14.1X53-D15 


12.2X50-D10 


12.2X50-D10 


12.2X50-D10 


13.1X51-D10 


12.2X50-D10 


Not supported 


QFX5100 


14.1X53-D15 


13.2X51-D15 
VC/VCF 

(14.1X53-D30) 
13.2X51-D15 


VC/VCF 
(14.1X53-D30) 


13.2X51-D10 


VC/VCF 
(14.1X53-D30) 


13.1X51-D10 


VC/VCF 
(13.2X51-D10) 


13.2X51-D15 


VC/VCF 
(14.1X53-D30) 


17.3R1 


QFX5110 


15.1X53-D210 


15.1X53-D210 


15.1X53-D210 


15.1X53-D210 


15.1X53-D210 


15.1X53-D210 


17.3R1 


QFX5120 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


QFX5200 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


15.1X53-D30 


17.3R1 


QFX5210 


18.1R1 


18.1R1 


18.1R1 


18.1R1 


18.1R1 


18.1R1 


18.1R1 
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Table 5: EX4600 and EX4650 MPLS Features 


Feature 


EX4600 and EX4650 standalone 
switches as MPLS provider edge (PE) 
switches or provider switches 


Label edge router (LER) 


Label-switching router (LSR) 


Automatic bandwidth allocation on 
LSPs 


BGP labeled unicast 


BGP link state distribution 


BGP route reflector 


Carrier-to-carrier and interprovider 
BGP Layer 3 VPNs 


Class of service (CoS or QoS) for 
MPLS traffic 


Dynamic label-switched path (LSP) 
count sizing: TE++ 


Equal-cost multipath (ECMP) at LSRs: 


e SWAP 

e PHP 

e L38VPN 

e L2 Circuit 


Entropy labels 


Ethernet-over-MPLS 
( L2 Circuit) 


Fast reroute (FRR), one-to-one local 
protection and many-to-one local 
protection 


EX4600 


14.1X53-D15 


14.1X53-D15 


14.1X53-D15 


Not supported 


14.1X53-D15 


Not supported 


14.1X53-D15 


14.1X53-D15 


14.1X53-D15 


Not supported 


Not supported 


Not supported 


14.1X53-D15 


14.1X53-D15 
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EX4650 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 

(Supported only on label stack. Not 
supported on flow label, entropy label, 
or ECMP label) 


Not supported 


18.3R1 


18.3R1 


Table 5: EX4600 and EX4650 MPLS Features (continued) 


Feature 


FRR using detours and secondary LSP 


Firewall filters 


Flow-aware transport of pseudowires 
(FAT) flow labels 


RSVP graceful restart for OSPF 


Traffic engineering extensions 
(OSPF-TE, IS-IS-TE) 


IP-over-MPLS LSPs, both static and 
dynamic links 


IPvé tunneling over an MPLS IPv4 
network (6PE) 


IPvé6 over an MPLS core network 


LDP tunneling over RSVP 


Layer 3 VPNs for both IPv4 and IPv6é 


Loop-free alternate (LFA) 


MPLS over integrated bridging and 
routing (IRB) interfaces 


MTU signaling in RSVP 

Operation, Administration, and 
Maintenance (OAM) including MPLS 
ping, traceroute, and BFD 


OSPF TE 


OSPFv2 as an interior gateway 
protocol 


EX4600 


Not supported 


14.1X53-D15 


Not supported 


13.2X51-D25 


14.1X53-D15 


14.1X53-D15 


14.1X53-D15 


Not supported 


14.1X53-D15 


14.1X53-D15 


Not supported 


Not supported 


14.1X53-D15 


14.1X53-D15 


14.1X53-D15 


13.2X51-D25 
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EX4650 


Not supported 


18.3R1 


Not supported 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


Not supported 


18.3R1 


18.3R1 


Not supported 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


18.3R1 


Table 5: EX4600 and EX4650 MPLS Features (continued) 


Feature EX4600 EX4650 
Path Computation Element Protocol | Not supported 18.3R1 
for RSVP-TE 

Pseudowire-over-aggregated Ethernet 14.1X53-D15 18.3R1 


interfaces (core-facing interface) 


RSVP automatic bandwidth 14.1X53-D15 18.3R1 


RSVP fast reroute (FRR), including 14.1X53-D15 18.3R1 
link-protection, node-link-protection, 

fast reroute using detours, and 

secondary LSP 


RSVP-TE extensions (IS-IS and OSPF) | 14.1X53-D15 18.3R1 
SNMP MIB support 14.1X53-D15 18.3R1 
Static and dynamic LSPs 14.1X53-D15 18.3R1 
Traffic engineering (TE)automatic 14.1X53-D15 18.3R1 


bandwidth allocation on LSPs 


Virtual routing and forwarding (VRF)  14.1X53-D15 18.3R1 
label support 
VRF support in IRB Interfaces ina Not supported 18.3R1 
Layer 3 VPN 


MPLS Limitations on QFX Series and EX4600 Switches 


IN THIS SECTION 


MPLS Limitations on QFX10000 Switches | 23 


MPLS Limitations on EX4600, EX4650, QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 
Switches | 23 


MPLS Limitations on QFX5100 Virtual Chassis and Virtual Chassis Fabric Switches | 26 
MPLS Limitations on QFX3500 Switches | 26 


23 


MPLS is a fully implemented protocol on routers, while switches support a subset of the MPLS features. 
The limitations of each switch are listed in a separate section here, although many of the limitations are 
duplicates that apply to more than one switch. 


MPLS Limitations on QFX10000 Switches 


e Configuring an MPLS firewall filter on a switch that is deployed as an egress provider edge (PE) switch 
has no effect. 


e Configuring the revert-timer statement at the [edit protocols mpls] hierarchy level has no effect. 
e These LDP features are not supported on the QFX10000 switches: 

e LDP multipoint 

e LDP link protection 

e LDP Bidirectional Forwarding Detection (BFD) 

e LDP Operation Administration and Management (OAM) 


e LDP multicast-only fast reroute (MoFRR) 


e Pseudowire-over-aggregated Ethernet interfaces on UNI are not supported. 
e MPLS-over-UDP tunnels are not supported on the following: 
e MPLS TTL propagation 
e IP fragmentation at the tunnel start point 
e CoS rewrite rules and priority propagation for RSVP LSP labels (ingress tunnels only) 
e Plain IPv6é 
e Multicast traffic 
e Firewall filters on tunnel start and endpoints 


e CoS tunnel endpoints 


NOTE: MPLS-over-UDP tunnels are created only if corresponding RSVP-TE, LDP, or BGP-LU 
tunnels are not available for the destination route. 


MPLS Limitations on EX4600, EX4650, QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 Switches 


e MPLS support differs on the various switches. EX4600 switches support only basic MPLS functionality 
while the QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 switches support some of the more 
advanced features. See “MPLS Feature Support on QFX Series and EX4600 Switches” on page 11 for 
details. 


e Ona QFX5100 switch, configuring integrated bridging and routing (IRB) interfaces on the MPLS core is 
implemented on the switch by using TCAM rules. This is the result of a chip limitation on the switch, 
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which only allows for a limited amount of TCAM space. There is 1K TCAM space is allocated for IRB. If 
multiple IRBs exist, make sure that you have enough available TCAM space on the switch. To check the 
TCAM space, see TCAM Filter Space Allocation and Verification in QFX Devices from Junos OS 
12.2x50-D20 Onward. 


(QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, EX4600) When VLAN bridge encapsulation is 
enabled on a CE connected interface, the switch drops packets if both flexible Ethernet services and 


VLAN CCC encapsulations are configured on the same logical interface. Only one can be configured, 
not both. For example: 


set interfaces xe-0/0/18 encapsulation flexible-ethernet-services, or set interfaces xe-0/0/18 
encapsulation vian-ccc. 


e Layer 2 circuits on aggregated Ethernet (AE) interfaces are not supported on QFX5100, QFX5110, 
QFX5120, QFX5200, and QFX5210 switches. 


e Layer 2 circuit local switching is not supported on the EX4600, EX4650, and QFX5100 switches. 


The QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 switches do not depend on the VRF 
match for loopback filters configured at different routing instances. Loopback filters per routing instance 
(such as lo0.100, lo0.103, lo0.105) are not supported and may cause unpredictable behavior. We 
recommend that you only apply the loopback filter (lo0.0) to the master routing instance 


On EX4600 and EX4650 switches, when loopback filters with both accept and deny terms for the same 
IP address are configured and if RSVP packets have that IP address in either source IP or destination IP, 
then those RSVP packets will be dropped even if accept terms have higher priority than deny terms. As 
per design, if the switch receives an RSVP packet with IP OPTION, the packet is copied to the CPU and 
then the original packet is dropped. Because RSVP packets are marked for drop, the accept term will 
not process these packets and the deny term will drop the packets. 


On a link-protected, fast reroute Layer 2 circuit, you might see a traffic convergence delay of 200 to 
300 milliseconds. 


e Layer 2 circuit local switching is not supported on the EX4600, EX4650, and QFX5100 switches. 


If you configure the BGP labeled unicast address family (using the labeled-unicast statement at the [edit 
protocols bgp family inet] hierarchy level) on a QFX Series switch or on an EX4600 switch deployed as 
a route reflector for BGP labeled routes, path selection will occur at the route reflector, and a single best 
path will be advertised. This will result in loss of BGP multipath informaton. 


e Although fast reroute (FRR) on regular interfaces is supported, the include-all and include-any options 
for FRR are not supported. See “Fast Reroute Overview” on page 472. 


e FRRis not supported on MPLS over IRB interfaces. 


e MPLS-based circuit cross-connects (CCC) are not supported—only circuit-based pseudowires are 
supported. 


Configuring link aggregation groups (LAGs) on user-to-network interface (UNI) ports for L2 circuits is 
not supported. 
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MTU signaling in RSVP and discovery is supported in the control plane. However, this cannot be enforced 
in the data plane. 


With L2 circuit-based pseudowires, if multiple equal-cost RSVP LSPs are available to reach an L2 circuit 
neighbor, one LSP is randomly used for forwarding. Use this feature to specify LSPs for specific L2 circuit 
traffic to load-share the traffic in the MPLS core. 


Configuring an MPLS firewall filter on a switch that is deployed as an egress provider edge (PE) switch 
has no effect. 


Firewall filters and policers on family mpls are only supported on QFX5100 switches that act as pure 
label-switching routers (LSRs) in an MPLS network. A pure LSR is a transit router that switches paths 
solely on the incoming label’s instructions. Firewall filters and policers on family mpls are not supported 
on QFX5100 ingress and egress provider edge (PE) switches. This includes switches that perform 
penultimate hop popping (PHP). 


Configuring the revert-timer statement at the [edit protocols mpls] hierarchy level has no effect. 


These are the hardware limitations for EX4600, EX4650, QFX5100, QFX5110, QFX5120, QFX5200, 
and QFX5210 switches: 


e 


Push of a maximum of three labels is supported in the MPLS edge switch if label swap is not done. 


Push of a maximum of two labels is supported in the MPLS edge switch if label swap is done. 


Pop at line rate is supported for a maximum of two labels. 


Global label space is supported but interface-specific label space is not supported. 


MPLS ECMP on PHY node with BOS=1 is not supported for single labels. 


QFX Series switches with Broadcom chips do not support separate next hops for the same label with 
different S bits (S-O and S-1). This includes the QFX3500, QFX3600, EX4600, QFX5100, and QFX5200 
switches. 


On EX4600, EX4650, QFX5100, QFX5110, QFX5120, QFX5200, and QFX5210 switches, the MPLS 
MTU command can cause unexpected behavior—this is due to SDK chipset limitations on this platform. 


These LDP features are not supported on the EX4600, EX4650, QFX5100, QFX5110, QFX5120, 
QFX5200, and QFX5210 switches: 


e LDP multipoint 

e LDP link protection 

e LDP Bidirectional Forwarding Detection (BFD) 

e LDP Operation Administration and Management (OAM) 


e LDP multicast-only fast reroute (MoFRR) 


Configuring unit with family mpls and unit with encapsulation vian-bridge on the same physical interface 
is not supported on EX4600, EX4650, QFX5100, QFX5110, or QFX5120. 


MPLS Limitations on QFX5100 Virtual Chassis and Virtual Chassis Fabric Switches 
The following MPLS features are not supported by the QFX5100 VC and QFX5100 VCF switches: 


Next-hop LSP 

BFD including BFD triggered FRR 

L2 VPN based on BGP (See RFC 6624) 
VPLS 

Extended VLAN CCC 

Pseudowire protection using Ethernet OAM 
Local switching of pseudo-wire 

Pseudowire fault detection based on VCCV 


QFX Series switches with Broadcom chipsets do not support separate next hops for the same label with 
different S bits (S-O and S-1). This includes QFX3500, QFX3600, EX4600, QFX5100, and QFX5200 
switches. 


MPLS Limitations on QFX3500 Switches 


If you configure the BGP labeled unicast address family (using the labeled-unicast statement at the [edit 
protocols bgp family inet] hierarchy level) on a QFX Series switch or on an EX4600 switch deployed as 
aroute reflector for BGP labeled routes, path selection will occur at the route reflector, and a single best 
path will be advertised. This will result in loss of BGP multipath information. 


Although fast reroute is supported, the include-all and include-any options for fast reroute are not 
supported. See “Fast Reroute Overview” on page 472 for details. 


MPLS-based circuit cross-connects (CCC) are not supported—only circuit-based pseudowires are 
supported. 


MTU signaling in RSVP and discovery is supported in the control plane. However, this cannot be enforced 
in the data plane. 


With Layer 2 (L2) circuit-based pseudowires, if multiple equal-cost RSVP label-switched paths (LSPs) 
are available to reach a L2 circuit neighbor, one LSP is randomly used for forwarding. Use this feature 
to specify LSPs for specific L2 circuit traffic to load-share the traffic in the MPLS core. 


Configuring an MPLS firewall filter on a switch that is deployed as an egress provider edge (PE) switch 
has no effect. 


Configuring the revert-timer statement at the [edit protocols mpls] hierarchy level has no effect. 


RELATED DOCUMENTATION 


Understanding MPLS Label Operations | 424 


MPLS Configuration Guidelines | 38 
FAQ: MPLS on EX Series Switches 
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CHAPTER 2 


Supported Standards 


IN THIS CHAPTER 


@ Supported MPLS Standards | 28 


| Supported MPLS Standards 


IN THIS SECTION 


Supported MPLS Standards | 28 

Supported RSVP Standards | 31 

Supported LDP Standards | 32 

DiffServ-Aware Traffic Engineering Standards | 33 
Supported GMPLS Standards | 33 


Supported PCEP Standards | 34 


Supported MPLS Standards 


Junos OS substantially supports the following RFCs and Internet drafts, which define standards for MPLS 
and traffic engineering. 


e RFC 2858, Multiprotocol Extensions for BGP-4 
e RFC 3031, Multiprotocol Label Switching Architecture 
e RFC 3032, MPLS Label Stack Encoding 
e RFC 3140, Per Hop Behavior Identification Codes 
e RFC 3270, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services 
Only E-LSPs are supported. 
e RFC 3443, Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks 
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RFC 3478, Graceful Restart Mechanism for Label Distribution Protocol 

RFC 3906, Calculating Interior Gateway Protocol (IGP) Routes Over Traffic Engineering Tunnels 
RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels 

Node protection in facility backup is not supported. 

RFC 4124, Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering 

RFC 4182, Removing a Restriction on the use of MPLS Explicit NULL 

RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs) 

RFC 4379, Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures 

RFC 4385, Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN. 


Supported on MX Series routers with the Channelized OC3/STM1 (Multi-Rate) Circuit Emulation MIC 
with SFP. 


RFC 4875, Extensions to RSVP-TE for Point-to-Multipoint TE LSPs 

RFC 4950, ICMP Extensions for Multiprotocol Label Switching 

RFC 5317, Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile 
RFC 5586, MPLS Generic Associated Channel 

RFC 5654, Requirements of an MPLS Transport Profile 


The following capabilities are supported in the Junos OS implementation of MPLS Transport Profile 
(MPLS-TP): 


e MPLS-TP OAM can send and receive packets with GAL and G-Ach, without IP encapsulation. 


e Two unidirectional RSVP LSPs between a pair of routers can be associated with each other to create 
an associated bidrectional LSP for binding a path for the GAL and G-Ach OAM messages. A single 
Bidirectional Forwarding Detection (BFD) session is established for the associated bidirectional LSP. 


RFC 5712, MPLS Traffic Engineering Soft Preemption 

RFC 5718, An In-Band Data Communication Network For the MPLS Transport Profile 

RFC 5860, Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks 
RFC 5884, Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs) 

RFC 5921, A Framework for MPLS in Transport Networks 

RFC 5950, Network Management Framework for MPLS-based Transport Networks 

RFC 5951, Network Management Requirements for MPLS-based Transport Networks 

RFC 5960, MPLS Transport Profile Data Plane Architecture 

RFC 6215, MPLS Transport Profile User-to- Network and Network-to-Network Interfaces 

RFC 6291, Guidelines for the Use of the “OAM” Acronym in the IETF. 
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RFC 6370, MPLS Transport Profile (MPLS-TP) Identifiers 


RFC 6371, Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks. 


RFC 6372, MPLS Transport Profile (MPLS-TP) Survivability Framework 


RFC 6373, MPLS-TP Control Plane Framework 


RFC 6388, Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label 
Switched Paths 


Only Point-to-Multipoint LSPs are supported. 
RFC 6424, Mechanism for Performing Label Switched Path Ping (LSP Ping) over MPLS Tunnels 


RFC 6425, Detecting Data-Plane Failures in Point-to-Multipoint MPLS - Extensions to LSP Ping 


RFC 6426, MPLS On-Demand Connectivity Verification and Route Tracing 


RFC 6428, Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS 
Transport Profile 


RFC 6510, Resource Reservation Protocol (RSVP) Message Formats for Label Switched Path (LSP) Attributes 
Objects 


RFC 7746, Label Switched Path (LSP) Self-Ping 


Internet draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Non PHP behavior and Out-of-Band 
Mapping for RSVP-TE LSPs 


The following RFCs and Internet drafts do not define standards, but provide information about MPLS, 
traffic engineering, and related technologies. The IETF classifies them variously as “Experimental,” “Historic,” 
or “Informational.” 


e RFC 2547, BGP/MPLS VPNs 

e RFC 2702, Requirements for Traffic Engineering Over MPLS 
e RFC 2917, A Core MPLS IP VPN Architecture 

RFC 3063, MPLS Loop Prevention Mechanism 


RFC 3208, PGM Reliable Transport Protocol Specification 
Only the network element is supported. 


RFC 3469, Framework for Multi-Protocol Label Switching (MPLS)-based Recovery 


RFC 3564, Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering 


RFC 4125, Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering 


RFC 4127, Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering 


Internet draft draft-martini-l2circuit-encap-mpls-11.txt, Encapsulation Methods for Transport of Layer 2 
Frames Over IP and MPLS Networks 
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Junos OS differs from the Internet draft in the following ways: 


e A packet with a sequence number of O is treated as out of sequence. 
e Any packet that does not have the next incremental sequence number is considered out of sequence. 


e When out-of-sequence packets arrive, the expected sequence number for the neighbor is set to the 
sequence number in the Layer 2 circuit control word. 


Internet draft draft-martini-l2circuit-trans-mpls-19.txt, Transport of Layer 2 Frames Over MPLS 


Internet draft draft-raggarwa-mpls-p2mp-te-02.txt, Establishing Point to Multipoint MPLS TE LSPs 


The features discussed in the indicated sections of the draft are not supported: 


e Nonadjacent signaling for branch LSPs (section 7.1) 
e Make-before-break and fast reroute (section 9) 


e LSP hierarchy using point-to-point LSPs (section 10) 


Supported RSVP Standards 


Junos OS substantially supports the following RFCs and Internet drafts, which define standards for RSVP. 


RFC 2205, Resource ReSerVation Protocol (RSVP)—Version 1 Functional Specification 


RFC 2210, The Use of RSVP with IETF Integrated Services 


RFC 2211, Specification of the Controlled-Load Network Element Service 


RFC 2212, Specification of Guaranteed Quality of Service 


RFC 2215, General Characterization Parameters for Integrated Service Network Elements 


RFC 2745, RSVP Diagnostic Messages 


RFC 2747, RSVP Cryptographic Authentication (updated by RFC 3097) 


RFC 2750, RSVP Extensions for Policy Control (RFC is not supported. Fully compliant with devices that 
support this RFC). 


RFC 2961, RSVP Refresh Overhead Reduction Extensions 


RFC 3097, RSVP Cryptographic Authentication—Updated Message Type Value 


RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels 


The Null Service Object for maximum transmission unit (MTU) signaling in RSVP is not supported. 


RFC 3473, Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 
Engineering (RSVP-TE) Extensions 


Only Section 9, “Fault Handling,” is supported. 


RFC 3477, Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) 
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RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels 


RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS) 


(OSPF extensions can carry traffic engineering information over unnumbered links.) 


RFC 4558, Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement 


RFC 4561, Definition of a Record Route Object (RRO) Node-Id Sub-Object 


The RRO node ID subobject is for use in inter-AS link and node protection configurations. 


RFC 4875, Extensions to RSVP-TE for Point-to-Multipoint TE LSPs 


RFC 5420, Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic 
Engineering (RSVP-TE) 


Only the LSP_ATTRIBUTES object is supported. 
e RFC 7570, Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO) 
e RFC 8370, Techniques to Improve the Scalability of RSVP-TE Deployments 
e draft-ietf-mpls-ri-rsvp-frr-05, Refresh Interval Independent FRR Facility Protection 


e draft-ietf-mpls-rsvp-shared-labels-09, Signaling RSVP-TE tunnels on a shared MPLS forwarding plane 


The following RFCs do not define standards, but provide information about RSVP and related technologies. 
The IETF classifies them variously as “Experimental” or “Informational.” 


e RFC 2209, Resource ReSerVation Protocol (RSVP)—Version 1 Message Processing Rules 

e RFC 2216, Network Element Service Specification Template 

e RFC 4125, Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering 
e RFC 4127, Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering 


Supported LDP Standards 


Junos OS substantially supports the following RFCs and Internet drafts, which define standards for LDP. 
e RFC 3212, Constraint-Based LSP Setup using LDP 


e RFC 3478, Graceful Restart Mechanism for Label Distribution Protocol 


e Internet draft draft-napierala-mpls-targeted-mldp-01.txt, Using LDP Multipoint Extensions on Targeted 
LDP Sessions 


The following RFCs do not define standards, but provide information about LDP. The IETF classifies them 
as “Informational.” 


e RFC 3215, LDP State Machine 
e RFC 5036, LDP Specification 
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For the following features described in the indicated sections of the RFC, Junos OS supports one of the 
possible modes but not the others: 


e Label distribution control (section 2.6.1): Ordered mode is supported, but not Independent mode. 
e Label retention (section 2.6.2): Liberal mode is supported, but not Conservative mode. 


e Label advertisement (section 2.6.3): Both Downstream Unsolicited mode and Downstream on Demand 
mode are supported. 


RFC 5283, LDP Extension for Inter-Area Label Switched Paths (LSPs) 
RFC 5443, LDP IGP Synchronization 
RFC 5561, LDP Capabilities 


RFC 6826, Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label 
Switched Paths 


Junos OS support limited to point-to-multipoint extensions for LDP. 


DiffServ-Aware Traffic Engineering Standards 


The following RFCs provide information on DiffServ-aware traffic engineering and multiclass LSPs: 


RFC 3270, Multi-Protocol Label Switching (MPLS) Support of Differentiated Services 

RFC 3564, Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering 

RFC 4124, Protocol Extensions for Support of Differentiated-Service-Aware MPLS Traffic Engineering 

RFC 4125, Maximum Allocation Bandwidth Constraints Model for Diff-Serv-aware MPLS Traffic Engineering 
RFC 4127, Russian Dolls Bandwidth Constraints Model for Diff-Serv-aware MPLS 


These RFCs are available on the IETF website at http://www.ietf.org/. 


Supported GMPLS Standards 


Junos OS substantially supports the following RFCs and Internet drafts, which define standards for 
Generalized MPLS (GMPLS). 


RFC 3471, Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description 


Only the following features are supported: 


e Bidirectional LSPs (upstream label only) 
e Control channel separation 
e Generalized label (suggested label only) 


e Generalized label request (bandwidth encoding only) 
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RFC 3473, Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic 
Engineering (RSVP-TE) Extensions 


Only Section 9, “Fault Handling,” is supported. 


RFC 4202, Routing Extensions in Support of Generalized Multi-Protocol Label Switching 


Only interface switching is supported. 


RFC 4206, Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) 
Traffic Engineering (TE) 


Internet draft draft-ietf-ccamp-gmpls-rsvp-te-ason-02.txt, Generalized MPLS (GMPLS) RSVP-TE Signalling 
in support of Automatically Switched Optical Network (ASON) (expires January 2005) 


Internet draft draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, Generalized Multi-Protocol Label Switching 
Extensions for SONET and SDH Control 


Only S,U,K,L,M-format labels and SONET traffic parameters are supported. 


Internet draft draft-ietf-ccamp-Imp-10.txt, Link Management Protocol (LMP) 


Internet draft draft-ietf-ccamp-ospf-gmpls-extensions-12.txt, OSPF Extensions in Support of Generalized 
Multi-Protocol Label Switching 


The following sub-TLV types for the Link type, link, value (TLV) are not supported: 


e Link Local/Remote Identifiers (type 11) 
e Link Protection Type (type 14) 
e Shared Risk Link Group (SRLG) (type 16) 


The features described in Section 2 of the draft, “Implications on Graceful Restart,” are also not supported. 


The Interface Switching Capability Descriptor (type 15) sub-TLV type is implemented, but only for packet 
switching. 


e Internet draft draft-ietf-mpls-bundle-04.txt, Link Bundling in MPLS Traffic Engineering 


Supported PCEP Standards 


Junos OS substantially supports the following RFCs and Internet drafts, which define standards for PCEP. 


e RFC 5440, Path Computation Element (PCE) Communication Protocol (PCEP)—Stateful PCE 
e RFC 8231, Path Computation Element Communication Protocol (PCEP)—Extensions for Stateful PCE 


e RFC 8281, Path Computation Element Communication Protocol (PCEP)—Extensions PCE-Initiated LSP Setup 
in a Stateful PCE Model 


e Internet draft-ietf-pce-stateful-pce-07.txt, PCEP Extensions for Stateful PCE 
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Internet draft-crabbe-pce-pce-initiated-Isp-03.txt, PCEP Extensions for PCE-initiated LSP Setup in a Stateful 
PCE Model 


Internet draft-ietf-pce-segment-routing-06.txt, PCEP Extensions for Segment Routing 


Internet draft-ietf-pce-stateful-pce-p2mp-02.txt, Path Computation Element (PCE) Protocol Extensions for 


Stateful PCE usage for Point-to-Multipoint Traffic Engineering Label Switched Paths 


Internet draft draft-cbrt-pce-stateful-local-protection-01, PCEP Extensions for RSVP-TE Local-Protection 
with PCE-Stateful (excluding support for bypass LSP mapping) 


Internet draft draft-ietf-pce-pcep-flowspec-05, PCEP Extension for Flow Specification 


The current implementation of this feature does not implement the following sections of the draft: 


e Section 3.1.2—Advertising PCE capabilties in IGP 
e Section 3.2—PCReq and PCRep message 


e Section 7—Most of the flow specifications, except route distinguisher and IPv4 Multicast Flow 
specifications, are not supported. 
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MPLS Configuration Overview 


When you first install Junos OS on your device, MPLS is disabled by default. You must explicitly configure 
your device to allow MPLS traffic to pass through. Complete the following steps for all devices in your 
MPLS network that are running Junos OS. 


To enable MPLS: 


1. Delete all configured security services from the device. If you do not complete this step, you will get 


a commit failure. See Example: Deleting Security Services. 
2. Enable MPLS on the device. See “Example: Enabling MPLS” on page 39. 


3. Commit the configuration. 
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4. Reboot the device. 


5. Configure MPLS features such as traffic engineering, VPNs, and VPLS. See: 


e MPLS Traffic Engineering and Signaling Protocols Overview on page 1063 
e MPLS VPN Overview 

e CLNS Overview 

e VPLS Overview 


CAUTION: When packet forwarding mode is changed to MPLS, all flow-based security 

A features are deactivated, and the device performs packet-based processing only. 
Flow-based services such as security policies, zones, NAT, ALGs, chassis clustering, 
screens, firewall authentication, and IPsec VPNs are unavailable on the device. However, 
MPLS can be enabled in flow-based packet forwarding mode for selected traffic using 
firewall filters. 


MPLS Configuration Guidelines 


When configuring MPLS on QFX Series devices or on EX4600, note that the number of IP prefixes supported 
depends on the specific platform being used. See the scale specifications in the data sheet of your device 
for additional information. 


e We recommend the following: 


e If your ingress provider edge (PE) switch needs to support more than 8000 external IP prefixes, use 
a larger capacity device as an ingress PE switch. 


e If you use a switch as a route reflector for BGP labeled routes, use it as a dedicated route reflector 
(that is, the switch must not participate in managing data traffic). 


e If you use a switch as a PE switch or as a route reflector for BGP labeled routes, configure routing 
policies on the PE switch and the route reflector to filter external IP routes from the routing table. 


The configuration example for a routing policy named fib_policy (at the [edit policy-options and [edit 
routing-options hierarchy levels) to filter BGP labeled routes from the inet.O routing table is given 
below: 


user@switch# show policy-options 
policy-statement fib_policy { 
from { 
protocol bgp; 
rib inet.O; 
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} 


then reject; 


user@switch# show routing-options 
forwarding-table { 
export fib_policy; 


Packet fragmentation using the allow-fragmentation statement at the [edit protocols mpls path-mtu] 
hierarchy level is not supported on QFX Series devices or on the EX4600 switch. Therefore, you must 
ensure that the maximum transmission unit (MTU) values configured on every MPLS interface is sufficient 
to handle MPLS packets. The packets whose size exceeds the MTU value of an interface will be dropped. 


Configuring MPLS 


You must also configure MPLS for a Layer 2 cross-connect to work. The following is a minimal MPLS 


configuration: 


[edit] 
interfaces { 
interface-name { 
unit logical-unit-number; 


} 
protocols { 
mpls { 
interface all; 


Example: Enabling MPLS 


This example shows how to enable MPLS for packet-based processing. It also shows how to enable the 
MPLS family and MPLS process on all of the transit interfaces in the network. 
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NOTE: When MPLS is enabled, all flow-based security features are deactivated and the device 
performs packet-based processing. Flow-based services such as security policies, zones, NAT, 
ALGs, chassis clustering, screens, firewall authentication, IP packets, and IPsec VPNs are 
unavailable on the device. 


Before changing from flow mode to packet mode, you must remove all security policies remaining 
under flow mode. To prevent management connection loss, you must bind the management 
interface to zones and enable host-inbound traffic to prevent the device from losing connectivity. 


For information about configuring zones, see Security Policies User Guide for Security Devices. 


Requirements 


Before you begin, delete all configured security services. See Example: Deleting Security Services. 


Overview 


The instructions in this topic describe how to enable MPLS on the device. You must enable MPLS on the 
device before including a device running Junos OS in an MPLS network. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


set security forwarding-options family mpls mode packet-based 
set interfaces ge-1/0/0 unit O family mpls 
set protocols mpls ge-1/0/0 unit 0 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For instructions 
on how to do that, see Using the CLI Editor in Configuration Mode. 


To enable MPLS: 


1. Enable MPLS for packet-based processing. 


[edit security forwarding-options] 
user@host# set family mpls mode packet-based 


2. Enable the MPLS family on each transit interface that you want to include in the MPLS network. 
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[edit interfaces] 
user@host# set interfaces ge-1/0/0 unit O family mpls 


3. Enable the MPLS process on all of the transit interfaces in the MPLS network. 


[edit protocols mpls] 
user@host# set interface ge-1/0/0 unit 0 


Results 
From configuration mode, confirm your configuration by entering the show security forwarding-options 
command. If the output does not display the intended configuration, repeat the configuration instructions 


in this example to correct it. 


NOTE: If you enable MPLS for packet-based processing by using the command set security 
forward-option family mpls mode packet, the mode will not change immediately and the system 
will display the following messages: 


warning: Reboot may required when try reset flow inet mode 


warning: Reboot may required when try reset mpls flow mode please check security flow status for 
detail. 


You need to reboot your device for the configuration to take effect. 


CAUTION: If you disable MPLS and switch back to using the security services 

A (flow-based processing), the mode will not change immediately and the system will 
display warning messages instructing you to restart your device. You must reboot your 
device for the configuration to take effect. This will also result in management sessions 
being reset and transit traffic getting interrupted. 


[edit] 
user@host# show security forwarding-options 
family { 
mpls { 
mode packet-based; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


@ ~~ Verifying MPLS Is Enabled at the Protocols Level | 42 
@ Verifying MPLS Is Enabled at the Interfaces Level | 42 


Confirm that the configuration is working properly. 
Verifying MPLS Is Enabled at the Protocols Level 


Purpose 
Verify that MPLS is enabled at the protocols level. 


Action 
From operational mode, enter the show protocols command. 
Verifying MPLS Is Enabled at the Interfaces Level 


Purpose 
Verify that MPLS is enabled at the interfaces level. 


Action 


From operational mode, enter the show interfaces command. 


Example: Configuring MPLS on EX8200 and EX4500 Switches 
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You can configure MPLS on switches to increase transport efficiency in your network. MPLS services can 
be used to connect various sites to a backbone network and to ensure better performance for low-latency 
applications such as voice over IP (VoIP) and other business-critical functions. 


To implement MPLS on the switches, you must configure two provider edge (PE) switches—an ingress PE 
switch and an egress PE switch— and at least one provider (transit) switch. You can configure the customer 
edge (CE) interfaces on the PE switches of the MPLS network as either circuit cross-connect (CCC) or IP 
(family inet) interfaces. 


This example shows how to configure an MPLS tunnel using a simple interface as a CCC: 


NOTE: This example shows how to configure MPLS using a simple interface as a CCC. For 
information on configuring a tagged VLAN interface as a CCC, see “Configuring an MPLS-Based 
VLAN CCC Using a Layer 2 VPN (CLI Procedure)” on page 1347 or “Configuring an MPLS-Based 
VLAN CCC Using a Layer 2 Circuit” on page 1314. 


Requirements 


This example uses the following hardware and software components: 


e Junos OS Release 10.1 or later for switches 


e Three EX Series switches 


Before you begin configuring MPLS, ensure that you have configured the routing protocol (OSPF or IS-IS) 
on the core interface and the loopback interface on all the switches. This example includes the configuration 
of OSPF on all the switches. For information on configuring IS-IS as the routing protocol, see the Junos 
OS Routing Protocols Configuration Guide. 


Overview and Topology 


This example includes an ingress or local PE switch, an egress or remote PE switch, and one provider 
switch. It includes CCCs that tie the customer edge interface of the local PE switch (PE-1) to the customer 
edge interface of the remote PE switch (PE-2). It also describes how to configure the core interfaces of 
the PE switches and the provider switch to support the transmission of the MPLS packets. In this example, 
the core interfaces that connect the local PE switch and the provider switch are individual interfaces, while 
the core interfaces that connect the remote PE switch and the provider switch are aggregated Ethernet 
interfaces. 
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NOTE: 
e Core interfaces cannot be tagged VLAN interfaces. 


e Core interfaces can be aggregated Ethernet interfaces. This example includes a LAG between 
the provider switch and the remote PE switch because this type of configuration is another 
option you can implement. For information on configuring LAGs, see Configuring Aggregated 
Ethernet Links (CLI Procedure). 


Figure 2 on page 44 shows the topology used in this example. 


Figure 2: Configuring MPLS on EX Series Switches 
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Table 6 on page 44 shows the MPLS configuration components used for the ingress PE switch in this 
example. 


Table 6: Components of the Ingress PE Switch in the Topology for MPLS with Interface-Based CCC 


Property Settings Description 
Local PE switch hardware EX Series switch PE-1 
Loopback address loO 127.1.1.1/32 Identifies PE-1 for interswitch 


communications. 


Routing protocol ospf traffic-engineering Indicates that this switch is using 
OSPF as the routing protocol and that 
traffic engineering is enabled. 


Table 6: Components of the Ingress PE Switch in the Topology for MPLS with Interface-Based CCC (continued) 


Property 


MPLS protocol and definition of 
label-switched path 


RSVP 


Interface family 


Customer edge interface 


Core interfaces 


CCC definition 


Settings 


mpls 
label-switched-path Isp_to_pe2_ge1 


to 127.1.13 


rsvp 


family inet 
family mpls 


family ccc 


ge-0/0/1 


ge-0/0/5.0 and ge-0/0/6.0 with IP 
addresses 10.1.5.1/24 and 
10.1.6.1/24 


connections 
remote-interface-switch ge-1-to-pe2 


interface ge-0/0/1.0 


transmit-Isp Isp_to_pe2_ge1 
receive-lsp Isp_to_pe1_ge1 


Description 


Indicates that this PE switch is using 
the MPLS protocol with the specified 
LSP to reach the other PE switch 

(specified by the loopback address). 


The statement must also specify the 
core interfaces to be used for MPLS 
traffic. 


Indicates that this switch is using 
RSVP. The statement must specify 
the loopback address and the core 
interfaces that will be used for the 
RSVP session. 


The logical units of the core 
interfaces are configured to belong 
to both family inet and family mpls. 


The logical unit of the customer edge 
interface is configured to belong to 
family ccc. 


Interface that connects this network 
to devices outside the network. 


Interfaces that connect to other 
switches within the MPLS network. 


Associates the circuit cross-connect 
(CCC), ge-0/0/1, with the LSPs that 
have been defined on the local and 
remote PE switches. 


Table 7 on page 46 shows the MPLS configuration components used for the egress PE switch in this 


example. 


Table 7: Components of the Egress PE Switch in the Topology for MPLS with Interface-Based CCC 


Property 


Remote PE switch hardware 


Loopback address 


Routing protocol 


MPLS protocol and definition of 
label-switched path 


RSVP 


Interface family 


Customer edge interface 


Core interface 


Settings 


EX Series switch 


lo0 127.1.1.3/32 


ospf traffic-engineering 


mpls 
label-switched-path Isp_to_pe1_ge1 


to 127.1.1.1 


rsvp 


family inet 


family mpls 


family ccc 


ge-0/0/1 


aeO with IP address 10.1.9.2/24 


Description 


PE-2 


Identifies PE-2 for interswitch 
communications. 


Indicates that this switch is using 
OSPF as the routing protocol and that 
traffic engineering is enabled. 


Indicates that this PE switch is using 
the MPLS protocol with the specified 
label-switched path (LSP) to reach the 
other PE switch. 


The statement must also specify the 
core interfaces to be used for MPLS 
traffic. 


Indicates that this switch is using 
RSVP. The statement must specify 
the loopback address and the core 
interfaces that will be used for the 
RSVP session. 


The logical unit of the core interface 
is configured to belong to both family 
inet and family mpls. 


The logical unit of the customer edge 
interface is configured to belong to 
family ccc. 


Interface that connects this network 
to devices outside the network. 


Aggregated Ethernet interface on 
PE-2 that connects to aggregated 
Ethernet interface aeO of the provider 
switch and belongs to family mpls. 
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Table 7: Components of the Egress PE Switch in the Topology for MPLS with Interface-Based CCC (continued) 


Property 


CCC definition 


Settings 


connections remote-interface-switch 
ge-1-to-pe1 


interface ge-0/0/1.0 


transmit-Isp Isp_to_pe1_ge1; 
receive-Isp Isp_to_pe2_ge1; 


Description 


Associates the CCC, ge-0/0/1, with 
the LSPs that have been defined on 
the local and remote PE switches. 


Table 8 on page 47 shows the MPLS configuration components used for the provider switch in this example. 


Table 8: Components of the Provider Switch in the Topology for MPLS with Interface-Based CCC 


Property 


Provider switch hardware 


Loopback address 


Routing protocol 


MPLS protocol 


RSVP 


Settings 


EX Series switch 


lo0 127.1.1.2/32 


ospf traffic-engineering 


mpls 


rsvp 


Description 


Transit switch within the MPLS 


network configuration. 


Identifies provider switch for 
interswitch communications. 


Indicates that this switch is using 
OSPF as the routing protocol and that 
traffic engineering is enabled. 


Indicates that this switch is using the 
MPLS protocol. 


The statement must specify the core 
interfaces that will be used for MPLS 
traffic. 


Indicates that this switch is using 
RSVP. The statement must specify 
the loopback and the core interfaces 
that will be used for the RSVP 


session. 
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Table 8: Components of the Provider Switch in the Topology for MPLS with Interface-Based CCC (continued) 


Property Settings Description 
Interface family family inet The logical units for the loopback 
. interface and the core interfaces 
family mpls belong to family inet. 
The logical units of the core 
interfaces are also configured to 
belong to family mpls. 
Core interfaces ge-0/0/5.0 and ge-0/0/6.0 with IP Interfaces that connect the provider 
addresses 10.1.5.1/24 and switch (P) to PE-1. 
10.1.6.1/24 


and ae0 with IP address 10.1.9.1/24 | A8gregated Ethernet interface on P 


that connects to aggregated Ethernet 
interface aeO of PE-2. 


Configuring the Local PE Switch 


CLI Quick Configuration 


To quickly configure the local ingress PE switch, copy the following commands and paste them into the 
switch terminal window of PE-1: 


[edit] 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/6.0 

set protocols mpls label-switched-path Isp_to_pe2_ge1 to 127.1.1.3 
set protocols mpls interface ge-0/0/5.0 

set protocols mpls interface ge-0/0/6.0 

set protocols rsvp interface lo0.0 

set protocols rsvp interface ge-0/0/5.0 

set protocols rsvp interface ge-0/0/6.0 

set interfaces loO unit O family inet address 127.1.1.1/32 

set interfaces ge-0/0/5 unit O family inet address 10.1.5.1/24 
set interfaces ge-0/0/6 unit 0 family inet address 10.1.6.1/24 
set interfaces ge-0/0/5 unit O family mpls 

set interfaces ge-0/0/6 unit O family mpls 

set interfaces ge-0/0/1 unit O family ccc 


set protocols connections remote-interface-switch ge-1-to-pe2 interface ge-0/0/1.0 
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set protocols connections remote-interface-switch ge-1-to-pe2 transmit-lIsp Isp_to_pe2_ge1 


set protocols connections remote-interface-switch ge-1-to-pe2 receive-Isp Isp_to_pe1_ge1 


Step-by-Step Procedure 


To configure the local ingress PE switch: 


1. 


Configure OSPF with traffic engineering enabled: 


[edit protocols] 





user@switchPE-1# set ospf traffic-engineering 


. Configure OSPF on the loopback address and the core interfaces: 


[edit protocols 


user@switchPE-1# set ospf area 0.0.0.0 interface lo0.0 





user@switchPE-1# set ospf area 0.0.0.0 interface ge-0/0/5.0 














user@switchPE-1# set ospf area 0.0.0.0 interface ge-0/0/6.0 


. Configure MPLS on this PE switch (PE-1) with a label-switched path (LSP) to the other PE switch (PE-2): 


[edit protocols] 





user@switchPE-1# set mpls label-switched-path Isp_to_pe2_ge1 to 127.1.1.3 


. Configure MPLS on the core interfaces: 


[edit protocols] 
user@switchPE-1# set mpls interface ge-0/0/5.0 





user@switchPE-1# set mpls interface ge-0/0/6.0 


. Configure RSVP on the loopback interface and the core interfaces: 


[edit protocols] 
user@switchPE-1# set rsvp interface lo0.0 


user@switchPE-1# set rsvp interface ge-0/0/5.0 





user@switchPE-1# set rsvp interface ge-0/0/6.0 


. Configure IP addresses for the loopback interface and the core interfaces: 


[edit] 


= 


user@switchPE- 





bh 


set interfaces loO unit O family inet address 127.1.1.1/32 
set interfaces ge-0/0/5 unit O family inet address 10.1.5.1/24 
user@switchPE-1# set interfaces ge-0/0/6 unit O family inet address 10.1.6.1/24 





a 


user@switchPE- 





bh 








. Configure family mpls on the logical unit of the core interface addresses: 


[edit] 
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user@switchPE-1# set interfaces ge-0/0/5 unit 0 family mpls 





user@switchPE-1# set interfaces ge-0/0/6 unit 0 family mpls 


8. Configure the logical unit of the customer edge interface as a CCC: 


[edit interfaces ge-0/0/1 unit 0] 





—user@PE-1# set family ccc 


9. Configure the interface-based CCC from PE-1 to PE-2: 


NOTE: You can also configure a tagged VLAN interface as a CCC. See “Configuring an 
MPLS-Based VLAN CCC Using a Layer 2 VPN (CLI Procedure)” on page 1347 or “Configuring 


an 


MPLS-Based VLAN CCC Using a Layer 2 Circuit” on page 1314. 


[edit protocols] 


user@P! 


user@P! 


E-1# set connections remote-interface-switch ge-1-to-pe2 interface ge-0/0/1.0 


E-—1# set connections remote-interface-switch ge-1-to-pe2 transmit-Isp Isp_to_pe2_ge1 





user@P! 


Results 


Display the 


E-1# set connections remote-interface-switch ge-1-to-pe2 receive-Isp Isp_to_pe1_ge1 


results of the configuration: 





user@switchPE-1> show configuration 


interfaces { 
ge-0/0/1 { 
unit O { 
family ccc; 


} 


ge-0/0/5 { 
unit O { 
family inet { 


} 


address 10.1.5.1/24, 


family mpls; 


} 


ge-0/0/6 { 
unit O { 
family inet { 
address 10.1.6.1/24; 
} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 127.1.1.1/32; 


} 
protocols { 
rsvp { 
interface 100.0; 
interface ge-0/0/5.0; 
interface ge-0/0/6.0; 
} 
mpls { 
label-switched-path Isp_to_pe2_ge1 { 
to 127.1.1.3; 
} 
interface ge-0/0/5.0; 
interface ge-0/0/6.0; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface 100.0; 
interface ge-0/0/5.0; 
interface ge-0/0/6.0; 


} 
connections { 
remote-interface-switch ge-1-to-pe2 { 
interface ge-0/0/1.0; 
transmit-Isp Isp_to_pe2_ge1; 
receive-lsp Isp_to_pe1_ge1; 
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Configuring the Remote PE Switch 


CLI Quick Configuration 
To quickly configure the remote PE switch, copy the following commands and paste them into the switch 
terminal window of PE-2: 


[edit] 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface aeO 

set protocols mpls label-switched-path Isp_to_pe1_ge1 to 127.1.1.1 

set protocols mpls interface aeO 

set protocols rsvp interface lo0.0 

set protocols rsvp interface aeO 

set interfaces loO unit 0 family inet address 127.1.1.3/32 

set interfaces aeO unit O family inet address 10.1.9.2/24 

set interfaces aeO unit O family mpls 

set interfaces ge-0/0/1 unit O family ccc 

set protocols connections remote-interface-switch ge-1-to-pe1 interface ge-0/0/1.0 
set protocols connections remote-interface-switch ge-1-to-pe1 transmit-Isp Isp_to_pe1_ge1 


set protocols connections remote-interface-switch ge-1-to-pe1 receive-Isp Isp_to_pe2_ge1 


Step-by-Step Procedure 
To configure the remote PE switch (PE-2): 


1. Configure OSPF with traffic engineering enabled: 


[edit protocols] 
user@switchPE-2# set ospf traffic-engineering 





2. Configure OSPF on the loopback interface and the core interface: 


[edit protocols] 
user@switchPE-2# set ospf area 0.0.0.0 interface lo0.0 





user@switchPE-2# set ospf area 0.0.0.0 interface aeO 
3. Configure MPLS on this switch (PE-2) with a label-switched path (LSP) to the other PE switch (PE-1): 


[edit protocols] 
user@switchPE-2# set mpls label-switched-path Isp_to_pe1_ge1 to 127.1.1.1 





4. Configure MPLS on the core interface: 
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[edit protocols] 





user@switchPE-2# set mpls interface aeO 


5. Configure RSVP on the loopback interface and the core interface: 


[edit protocols] 


ser@switchPE-2# set rsvp interface lo0.0 








user@switchPE-2# set rsvp interface aeO 


6. Configure IP addresses for the loopback interface and the core interface: 


[edit] 
user@switchPE-2# set interfaces loO unit O family inet address 127.1.1.3/32 





user@switchPE-2# set interfaces aeO unit O family inet address 10.1.9.2/24 
7. Configure family mpls on the logical unit of the core interface: 


[edit] 





user@switchPE-2# set interfaces aeO unit O family mpls 
8. Configure the logical unit of the customer edge interface as a CCC: 


[edit interfaces ge-0/0/1 unit 0] 





user@PE-2# set family ccc 
9. Configure the interface-based CCC from PE-2 to PE-1: 


[edit protocols] 





user@PE-2# set connections remote-interface-switch ge-1-to-pe1 interface ge-0/0/1.0 





user@PE-2# set connections remote-interface-switch ge-1-to-pe1 transmit-Isp Isp_to_pe1_ge1 














user@PE-2# set connections remote-interface-switch ge-1-to-pe1 receive-Isp Isp_to_pe2_ge1 


Results 


Display the results of the configuration: 


user@switchPE-2> show configuration 





interfaces { 
ge-0/0/1 { 
unit O { 
family ccc; 


} 
aeO { 
unit O { 
family inet { 
address 10.1.9.2/24- 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 127.1.1.3/32; 


} 
protocols { 
rsvp { 
interface 100.0; 
interface aeO.0; 
} 
mpls { 
label-switched-path Isp_to_pe1_ge1 { 
to 127.1.1.1; 
} 
interface ae0.0; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface ae0.0; 


} 
connections { 
remote-interface-switch ge-1-to-pe1 { 
interface ge-0/0/1.0; 
transmit-lIsp Isp_to_pe1_ge1; 
receive-lsp Isp_to_pe2_ge1; 
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Configuring the Provider Switch 


CLI Quick Configuration 


To quickly configure the provider switch, copy the following commands and paste them into the switch 
terminal window: 


[edit] 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/6.0 

set protocols ospf area 0.0.0.0 interface aeO 

set protocols mpls interface ge-0/0/5.0 

set protocols mpls interface ge-0/0/6.0 

set protocols mpls interface aeO 

set protocols rsvp interface lo0.0 

set protocols rsvp interface ge-0/0/5.0 

set protocols rsvp interface ge-0/0/6.0 

set protocols rsvp interface aeO 

set interfaces loO unit O family inet address 127.1.1.2/32 

set interfaces ge-0/0/5 unit O family inet address 10.1.5.1/24 
set interfaces ge-0/0/6 unit 0 family inet address 10.1.6.1/24 
set interfaces aeO unit O family inet address 10.1.9.1/24 

set interfaces ge-0/0/5 unit O family mpls 

set interfaces ge-0/0/6 unit 0 family mpls 


set interfaces aeO unit O family mpls 


Step-by-Step Procedure 


To configure the provider switch: 
1. Configure OSPF with traffic engineering enabled: 


[edit protocols] 


user@switchP# set ospf traffic-engineering 


2. Configure OSPF on the loopback interface and the core interfaces: 


[edit protocols] 





user@switchP# set ospf area 0.0.0.0 interface lo0.0 





user@switchP# set ospf area 0.0.0.0 interface ge-0/0/5 











user@switchP# set ospf area 0.0.0.0 interface ge-0/0/6 
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user@switchP# set ospf area 0.0.0.0 interface aeO 


3. Configure MPLS on the core interfaces on the switch: 


[edit protocols] 





user@switchP# set mpls interface ge-0/0/5 





user@switchP# set mpls interface ge-0/0/6 











user@switchP# set mpls interface aeO 


4. Configure RSVP on the loopback interface and the core interfaces: 


[edit protocols] 





user@switchP# set rsvp interface lo0.0 





user@switchP# set rsvp interface ge-0/0/5 





user@switchP# set rsvp interface ge-0/0/6 











user@switchP# set rsvp interface aeO 


5. Configure IP addresses for the loopback interface and the core interfaces: 


[edit] 





user@switchP# set interfaces loO unit 0 family inet address 127.1.1.2/32 





user@switchP# set interfaces ge-0/0/5 unit O family inet address 10.1.5.1/24 





user@switchP# set interfaces ge-0/0/6 unit O family inet address 10.1.6.1/24 











user@switchP# set interfaces aeO unit O family inet address 10.1.9.1/24 
6. Configure family mpls on the logical unit of the core interface addresses: 


[edit] 





user@switchP# set interfaces ge-0/0/5 unit 0 family mpls 





user@switchP# set interfaces ge-0/0/6 unit 0 family mpls 











user@switchP# set interfaces aeO unit 0 family mpls 


Results 


Display the results of the configuration: 


user@switchP> show configuration 


interfaces { 
ge-0/0/5 { 
unit O { 
family inet { 


address 10.1.5.1/24, 
} 
family mpls; 
} 
} 
ge-0/0/6 { 
unit O { 
family inet { 
address 10.1.6.1/24; 
} 
family mpls; 


} 


} 
aeO { 
unit O { 
family inet { 
address 10.1.9.1/24- 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 127.1.1.2/32; 


} 
protocols { 

rsvp { 
interface 100.0; 
interface ge-0/0/5.0; 
interface ge-0/0/6.0; 
interface aeO.0; 

} 

mpls { 
interface ge-0/0/5.0; 
interface ge-0/0/6.0; 
interface aeO.0; 

} 

ospf { 
traffic-engineering; 
area 0.0.0.0 { 


57 


interface 100.0; 
interface ge-0/0/5.0; 
interface ge-0/0/6.0; 
interface ae0.0; 


Verification 


IN THIS SECTION 


Verifying the Physical Layer on the Switches | 58 


Verifying the Routing Protocol | 59 


Verifying the Status of the RSVP Sessions | 60 


Verifying the Assignment of Interfaces for MPLS Label Operations | 60 


@ 
e 
@ Verifying the Core Interfaces Being Used for MPLS Traffic | 59 
e 
® 
e 


Verifying the Status of the CCC | 61 


To confirm that the configuration is working properly, perform these tasks: 


Verifying the Physical Layer on the Switches 


Purpose 


Verify that the interfaces are up. Perform this verification task on each of the switches. 


Action 





user@switchP! 


Interface 
ge-0/0/0 
ge-0/0/0.0 
ge-0/0/1 
ge-0/0/1.0 
ge-0/0/2 
ge-0/0/2.0 
ge-0/0/3 
ge-0/0/3.0 
ge-0/0/4 


E-1> show interfaces terse 


Admin Link Proto Local Remote 
up up 

up up eth-switch 

up up 

up UDC Ce 

up up 

up up eth-switch 

up up 

up up eth-switch 

up up 
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ge-0/0/4.0 up up eth-switch 

ge-0/0/5 up up 

ge-0/0/5.0 up up inet 10,1,5,1/24 
mpls 

ge-0/0/6 up up 

ge-0/0/6.0 up up inet 10,1.6,1/24 
mpls 

Meaning 


The show interfaces terse command displays status information about the Gigabit Ethernet interfaces on 
the switch. This output verifies that the interfaces are up. The output for the protocol family (Proto column) 
shows that interface ge-0/0/1.0 is configured as a circuit cross-connect. The output for the protocol family 
of the core interfaces (ge-0/0/5.0 and ge-0/0/6.0) shows that these interfaces are configured as both inet 
and mpls. The Local column for the core interfaces shows the IP address configured for these interfaces. 


Verifying the Routing Protocol 


Purpose 


Verify the state of the configured routing protocol. Perform this verification task on each of the switches. 
The state must be Full. 


Action 





user@switchPE-1> show ospf neighbor 


Address Interface State 110) Pri Dead 
MAY oils ilo 2 ge—0/0/5 Full LO 10.10 210 128 39) 
Meaning 


The show ospf neighbor command displays the status of the routing protocol. This output shows that the 
state is Full, meaning that the routing protocol is operating correctly—that is, hello packets are being 
exchanged between directly connected neighbors. 


Verifying the Core Interfaces Being Used for MPLS Traffic 


Purpose 


Verify that the state of the MPLS interface is Up. Perform this verification task on each of the switches. 
Action 


user@switchPE-1> show mpls interface 
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Interface State Administrative groups 
ge—0/0/5 Up <none> 
ge—0/0/6 Up <none> 

Meaning 


The show mpls interface command displays the status of the core interfaces that have been configured 
to belong to family mpls. This output shows that the interface configured to belong to family mpls is Up. 


Verifying the Status of the RSVP Sessions 


Purpose 
Verify the status of the RSVP sessions. Perform this verification task on each of the switches. 


Action 





user@switchPE-1> show rsvp session 


Ingress RSVP: 1 sessions 
To From State Rt Style Labelin Labelout LSPname 


2g Aly ALS} Ga eels dec lb Up Oil ine = 300064 lsp_to_pe2_gel 





Total 1 displayed, Up 1, Down 0 





Egress RSVP: 1 sessions 

To From State Rt Style Labelin Labelout LSPname 

IEP a ils eal WA sdk thed Up @ i ine 299968 lsp_to_pel_gel 
Total 1 displayed, Up 1, Down 0 


Transit RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 
This output confirms that the RSVP sessions are Up. 


Verifying the Assignment of Interfaces for MPLS Label Operations 


Purpose 
Verify which interface is being used as the beginning of the CCC and which interface is being used to push 
the MPLS packet to the next hop. Perform this task only on the PE switches. 


Action 
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user@switchPE-1> show route forwarding-table family mpls 


MP ES? 

Destination Type RtRef Next hop 
default perm 0 

0 wiser 0 

1 wusiere 0 

2 user 0 

BYDT UG wusiere 0 
ge-0/0/1.0 (CCC) user Ome OR Orel 


Meaning 


Type Index NhRef Netif 





dscd 50 iL 

recv 49 5 

recv 49 3 

recv 49 iS) 
Pop 541 2 ge-0/0/1.0 
Push 299792 Ome ge-0/0/5.0 


This output shows that the CCC has been set up on interface ge-0/0/1.0. The switch receives ingress 
traffic on ge-0/0/1.0 and pushes label 299792 onto the packet, which goes out through interface 
ge-0/0/5.0. The output also shows when the switch receives an MPLS packet with label 29976, it pops 
the label and sends the packet out through interface ge-0/0/1.0 


After you have checked the local PE switch, run the same command on the remote PE switch. 


Verifying the Status of the CCC 


Purpose 


Verify the status of the CCC. Perform this task only on the PE switches. 


Action 





user@switchPE-1> show connections 


CCC and TCC connections [Link Monitoring On] 


Legend for status (St) 





UN -- uninitialized 
NE —— Aor presenc 
WE -- wrong encapsulation 


DS -—- disabled 





Dn -—-— down 

Sa OlLyRoOnuLboundmconne smtp 
<> Onlhyaelno OU Cm mC Onn Sa US 

Up -- operational 

RmtDn --— remote CCC down 


Restart -—- restarting 


Legend for connection types 





sw: transmit P2MP switching 





if-sw: interface switching 
rmt-if: remote interface switching 
lsp-sw: LSP switching 

tx-p2mp- 

rx-p2mp-sw: receive P2MP switching 
Legend for circuit types 

intf -- interface 

Els —— ERAMSIMIE ISI 

rlsp -- receive LSP 


Connection/Circuit 

gel-to-pe2 
ge-0/0/1.0 
lsp_to_pel_gel 
lsp_to_pe2_gel 


Meaning 


Type 
igihe aie 
aLiohe i€ 
tlsp 
ILS 


st 
Up 
Up 
Up 
Up 
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Time last up # Up trans 
Feb 17 05:00:09 1 


The show connections command displays the status of the CCC connections. This output verifies that the 
CCC interface and its associated transmit and receive LSPs are Up. After you have checked the local PE 


switch, run the same command on the remote PE switch. 
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Configuring MPLS on Provider Switches 


To implement MPLS, you must configure at least one provider switch as a transit switch for the MPLS 
packets. 


MPLS requires the configuration of an interior gateway protocol (OSPF) and a signaling protocol (RSVP) 
on the core interfaces and the loopback interface of all the switches. This procedure includes the 
configuration of OSPF on the provider switch. 


To configure the provider switch, complete the following tasks: 


1. Configure OSPF on the loopback and core interfaces: 


NOTE: You can use the switch address as an alternative to the loopback interface. 


[edit protocols ospf] 





user@switch# set area 0.0.0.0 interface lo0.0 





user@switch# set area 0.0.0.0 interface xe-0/0/5.0 








user@switch# set area 0.0.0.0 interface xe-0/0/6.0 





user@switch# set area 0.0.0.0 interface aeO 


2. Configure MPLS on the core interfaces: 


[edit protocols mpls] 
user@switch# set interface xe-0/0/5.0 
user@switch# set interface xe-0/0/6.0 


user@switch# set interface aeO 


3. Configure RSVP on the loopback interface and the core interfaces: 


[edit protocols rsvp] 





user@switch# set interface lo0.0 





user@switch# set interface xe-0/0/5.0 


user@switch# set interface xe-0/0/6.0 











user@switch# set interface aeO 


4. Configure an IP address for the loopback interface and the core interfaces: 


[edit interfaces] 
user@switch# set loO unit O family inet address 127.1.1.1/32 
user@switch# set xe-0/0/5 unit O family inet address 10.1.5.1/24 
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user@switch# set xe-0/0/6 unit O family inet address 10.1.6.1/24 
user@switch# set aeO unit O family inet address 10.1.9.2/24 


5. Configure family mpls on the logical units of the core interfaces, thereby identifying the interfaces that 
will be used for forwarding MPLS packets: 


[edit interfaces] 


user@switch# set xe-0/0/5 unit 0 family mpls 





user@switch# set xe-0/0/6 unit O family mpls 











user@switch# set aeO unit O family mpls 


Configuring MPLS on Provider Edge Switches 


To implement MPLS, you must configure two provider edge (PE) switches—an ingress PE switch and an 
egress PE switch—and at least one provider switch. You can configure the customer edge (CE) interfaces 
on the PE switches of the MPLS network using IP over MPLS. 


This topic describes how to configure an ingress PE switch and an egress PE switch using IP over MPLS: 


1. Configuring the Ingress PE Switch | 64 
2. Configuring the Egress PE Switch | 66 


Configuring the Ingress PE Switch 


To configure the ingress PE switch: 


1. Configure an IP address for the loopback interface and the core interfaces: 


[edit interfaces] 

user@switch# set loO unit 0 family inet address 192.168.10.1/32 
user@switch# set xe-0/0/5 unit O family inet address 10.1.5.1/24 
user@switch# set xe-0/0/6 unit O family inet address 10.1.6.1/24 


NOTE: You cannot use routed VLAN interfaces (RVIs) or Layer 3 subinterfaces as core 
interfaces. 


2. Configure OSPF on the loopback interface and the core interfaces: 


NOTE: You can use the switch address as an alternative to the loopback interface. 


[edit protocols ospf] 

user@switch# set area 0.0.0.0 interface lo0.0 
user@switch# set area 0.0.0.0 interface xe-0/0/5.0 
user@switch# set area 0.0.0.0 interface xe-0/0/6.0 


. Configure OSPF traffic engineering: 


[edit protocols ospf] 


user@switcht# set traffic-engineering 


. Configure RSVP on the loopback interface and the core interfaces: 


[edit protocols rsvp] 





user@switch# set interface lo0.0 








user@switch# set interface xe-0/0/5.0 





user@switch# set interface xe-0/0/6.0 


. Configure MPLS traffic engineering. 


[edit protocols mpls] 


user@switch# set traffic-engineering 


. Configure MPLS on the core interfaces: 


[edit protocols mpls] 
user@switch# set interface xe-0/0/5.0 


user@switch# set interface xe-0/0/6.0 


. Configure family mpls on the logical units of the core interfaces, thereby identifying the interfaces that 
will be used for forwarding MPLS packets: 


[edit interfaces] 
user@switch# set xe-0/0/5 unit 0 family mpls 
user@switch# set xe-0/0/6 unit 0 family mpls 


. Configure a customer edge interface as a Layer 3 routed interface, specifying an IP address: 


[edit interfaces] 


user@switch# set xe-0/0/3 unit O family inet address 121.100.10.1/16 


. Configure this Layer 3 customer edge interface for the routing protocol: 


[edit] 


user@switch# set protocols ospf area 0.0.0 interface xe-0/0/3.0 
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10. Configure an LSP on the ingress PE switch (192.168.10.1) to send IP packets over MPLS to the egress 
PE switch (192.168.12.1): 


[edit protocols mpls] 
user@switch# set label-switched-path Isp_1 to 192.168.12.1 


11. Disable constrained-path LSP computation for this LSP: 


[edit protocols mpls] 
user@switch# set label-switched-path Isp_1 no-cspf 


12. Configure a static route from the ingress PE switch to the egress PE switch, thereby indicating to the 


routing protocol that the packets will be forwarded over the MPLS LSP that has been set up to that 
destination: 


[edit routing-options] 
user@switch# set static route 2.2.2.0/24 next-hop 192.168.10.1 


user@switch# set static route 2.2.2.0/24 resolve 
Configuring the Egress PE Switch 
To configure the egress PE switch: 
1. Configure an IP address for the loopback interface and the core interfaces: 


[edit interfaces] 





user@switch# set loO unit O family inet address 192.168.12.1/32 
user@switch# set xe-0/0/5 unit O family inet address 10.1.20.1/24 














user@switch# set xe-0/0/6 unit O family inet address 10.1.21.1/24 


NOTE: You cannot use routed VLAN interfaces (RVIs) or Layer 3 subinterfaces as core 


interfaces. 


2. Configure OSPF on the loopback interface and the core interfaces: 


NOTE: You can use the switch address as an alternative to the loopback interface. 


[edit protocols ospf] 


user@switch# set area 0.0.0.0 interface lo0.0 


user@switch# set area 0.0.0.0 interface xe-0/0/5.0 
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user@switch# set area 0.0.0.0 interface xe-0/0/6.0 


. Configure RSVP on the loopback interface and the core interfaces: 


[edit protocols rsvp] 


user@switch# set rsvp interface lo0.0 





user@switch# set rsvp interface xe-0/0/5.0 











user@switch# set rsvp interface xe-0/0/6.0 


. Configure MPLS on the core interfaces: 


[edit protocols mpls] 
user@switch# set interface xe-0/0/5.0 


user@switch# set interface xe-0/0/6.0 


. Configure family mpls on the logical units of the core interfaces, thereby identifying the interfaces that 
will be used for forwarding MPLS packets: 


[edit interfaces] 
user@switch# set xe-0/0/5 unit 0 family mpls 
user@switch# set xe-0/0/6 unit O family mpls 


. Configure a customer edge interface as a Layer 3 routed interface, specifying an IP address: 


[edit interfaces] 


user@switch# set xe-0/0/3 unit 0 family inet address 2.2.2.1/16 
. Configure this Layer 3 customer edge interface for the routing protocol: 


[edit] 


user@switch# set protocols ospf area 0.0.0 interface xe-0/0/3 


. Configure an LSP on the egress PE switch (192.168.12.1) to send IP packets over MPLS to the ingress 
PE switch (192.168.10.1): 


[edit protocols mpls] 
user@switch# set label-switched-path Isp_2 to 192.168.10.1 


. Disable constrained-path LSP computation for this LSP: 


[edit protocols mpls] 
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user@switch# set label-switched-path Isp_2 no-cspf 


10. Configure a static route from the ingress PE switch to the egress PE switch, thereby indicating to the 
routing protocol that the packets will be forwarded over the MPLS LSP that has been set up to that 
destination: 


[edit routing-options] 
user@switch# set static route 121.121.121.0/24 next-hop 192.168.12.1 
user@switch# set static route 121.121.121.0/24 resolve 


Configuring MPLS on Provider Edge Switches Using IP-Over-MPLS 


You can configure MPLS on EX Series switches to increase transport efficiency in your network. MPLS 
services can be used to connect various sites to a backbone network or to ensure better performance for 
low-latency applications such as VoIP and other business-critical functions. 


To implement MPLS on switches, you must configure two provider edge (PE) switches—an ingress PE 
switch and an egress PE switch—and at least one provider switch. You can configure customer edge (CE) 
interfaces on the PE switches of the MPLS network by using either IP over MPLS or MPLS over circuit 
cross-connect (CCC). 


The main differences between configuring IP over MPLS and configuring MPLS over CCC are that for IP 
over MLPS you configure the customer edge interfaces to belong to family inet (rather than family ccc) 
and you configure a static route for the label-switched path (LSP). The configuration of the provider switch 
is the same regardless of whether you have used IP over MPLS or MPLS over CCC. See “Configuring MPLS 
on EX8200 and EX4500 Provider Switches” on page 78. 


This topic describes how to configure an ingress PE switch and an egress PE switch using IP over MPLS: 


1. Configuring the Ingress PE Switch | 68 
2. Configuring the Egress PE Switch | 71 


Configuring the Ingress PE Switch 


To configure the ingress PE switch: 


1. Configure an IP address for the loopback interface and for the core interfaces: 


[edit] 

user@switch# set interfaces loO unit 0 family inet address 100.100.100.100/32 
user@switch# set interfaces ge-0/0/5 unit O family inet address 10.1.5.1/24 
user@switch# set interfaces ge-0/0/6 unit O family inet address 10.1.6.1/24 


2. Configure OSPF on the loopback and core interfaces: 
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[edit protocols] 

user@switch# set ospf area 0.0.0.0 interface lo0.0 
user@switch# set ospf area 0.0.0.0 interface ge-0/0/5.0 
user@switch# set ospf area 0.0.0.0 interface ge-0/0/6.0 


NOTE: If you want to use routed VLAN interfaces (RVIs) or Layer 3 subinterfaces as the core 
interfaces, replace ge-O/0/5.0 and ge-0/0/6 each with an RVI name (for example, 
vlan.logical-interface-number) or a subinterface name (for example, 
interface-name.logical-unit-number). 


RVIs function as logical routers, eliminating the need to have both a switch and a router. 
Layer 3 subinterfaces allow you to route traffic among multiple VLANs along a single trunk 
line that connects an EX Series switch to a Layer 2 switch. 


. Enable traffic engineering for the routing protocol: 


[edit protocols] 


user@switch# set ospf traffic-engineering 
. Configure RSVP on the loopback interface and the core interfaces: 


[edit protocols] 

user@switch# set rsvp interface lo0.0 
user@switch# set rsvp interface ge-0/0/5.0 
user@switch# set rsvp interface ge-0/0/6.0 


. Configure MPLS traffic engineering: 


[edit protocols] 


user@switch# set protocols mpls traffic-engineering bgp-igp 
. Configure MPLS on the core interfaces: 


[edit protocols] 
user@switch# set mpls interface ge-0/0/5.0 
user@switch# set mpls interface ge-0/0/6.0 


. Configure family mpls on the logical units of the core interfaces, thereby identifying the interfaces that 
will be used for forwarding MPLS packets: 


[edit] 
user@switch# set interfaces ge-0/0/5 unit O family mpls 
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user@switch# set interfaces ge-0/0/6 unit O family mpls 


8. Configure a customer edge interface as a Layer 3 routed interface, specifying an IP address: 


[edit] 
user@switch# set interfaces ge-2/0/3 unit 0 family inet 121.121.121.1/16 


9. Configure this Layer 3 customer edge interface for the routing protocol: 


[edit ] 


user@switch# set protocols ospf area 0.0.0 interface ge-2/0/3.0 


10. Configure an LSP on the ingress PE switch (100.100.100.100) to send IP packets over MPLS to the 
egress PE switch (208.208.208.208): 


[edit protocols mpls] 
user@switch# set label-switched-path ip_Ispjavae_29 from 100.100.100.100 
user@switch# set label-switched-path ip_Ispjavae_29 to 208.208.208.208 


11. Disable constrained-path LSP computation for this LSP: 


[edit protocols mpls] 


user@switch# set label-switched-path ip_Ispjavae_29 no-cspf 


12. Configure a static route from the ingress PE switch to the egress PE switch, thereby indicating to the 


routing protocol that the packets will be forwarded over the MPLS LSP that has been set up to that 
destination: 


NOTE: Do not configure a static route if you are using this procedure to configure an 
MPLS-based Layer 3 VPN. 


[edit] 
user@switch# set routing-options static route 2.2.2.0/24 next-hop 100.100.100.100 


user@switch# set routing-options static route 2.2.2.0/24 resolve 
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Configuring the Egress PE Switch 


To configure the egress PE switch: 


1. Configure an IP address for the loopback interface and for the core interfaces: 


5. 


[edit] 

user@switch# set interfaces loO unit 0 family inet address 208.208.208.208/32 
user@switch# set interfaces ge-0/0/5 unit O family inet address 10.1.20.1/24 
user@switch# set interfaces ge-0/0/6 unit O family inet address 10.1.21.1/24 


. Configure OSPF on the loopback interface (or switch address) and core interfaces: 


[edit protocols] 

user@switch# set ospf area 0.0.0.0 interface lo0.0 
user@switch# set ospf area 0.0.0.0 interface ge-0/0/5.0 
user@switch# set ospf area 0.0.0.0 interface ge-0/0/6.0 


NOTE: If you want to use routed VLAN interfaces (RVIs) or Layer 3 subinterfaces as the core 
interfaces, replace ge-O/0/5.0 and ge-0/0/6 each with an RVI name (for example, 
vian.logical-interface-number) or a subinterface name (for example, 
interface-name.logical-unit-number). 


RVIs function as logical routers, eliminating the need to have both a switch and a router. 
Layer 3 subinterfaces allow you to route traffic among multiple VLANs along a single trunk 
line that connects an EX Series switch to a Layer 2 switch. 


. Enable traffic engineering for the routing protocol: 


[edit protocols] 


user@switch# set ospf traffic-engineering 


. Configure RSVP on the loopback interface and the core interfaces: 


[edit protocols] 





user@switch# set rsvp interface lo0.0 








user@switch# set rsvp interface ge-0/0/5.0 





user@switch# set rsvp interface ge-0/0/6.0 


Configure MPLS traffic engineering on both BGP and IGP destinations: 


[edit protocols] 


user@switch# set protocols mpls traffic-engineering bgp-igp 
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6. Configure MPLS on the core interfaces: 


[edit protocols] 
user@switch# set mpls interface ge-0/0/5.0 
user@switch# set mpls interface ge-0/0/6.0 


7. Configure family mpls on the logical units of the core interfaces, thereby identifying the interfaces that 
will be used for forwarding MPLS packets: 


[edit] 





user@switch# set interfaces ge-0/0/5 unit O family mpls 











user@switch# set interfaces ge-0/0/6 unit O family mpls 


8. Configure a customer edge interface as a Layer 3 routed interface, specifying an IP address: 


[edit] 
user@switch# set interfaces ge-2/0/3 unit 0 family inet address 2.2.2.1/16 


9. Configure this Layer 3 customer edge interface for the routing protocol: 


[edit] 
user@switch# set protocols ospf area 0.0.0 interface ge-2/0/3 


10. Configure an LSP on the egress PE switch (208.208.208.208) to send IP packets over MPLS to the 
ingress PE switch (100.100.100.100): 


[edit protocols mpls] 
user@switch# set label-switched-path ip_Isp29_javae from 208.208.208.208 
user@switch# set label-switched-path ip_Isp29_javae to 100.100.100.100 


11. Disable constrained-path LSP computation for this LSP: 


[edit protocols mpls] 


user@switch# set label-switched-path ip_Isp29_javae no-cspf 


12. Configure a static route from the ingress PE switch to the egress PE switch, thereby indicating to the 
routing protocol that the packets will be forwarded over the MPLS LSP that has been set up to that 
destination: 


NOTE: Do not configure a static route if you are using this procedure to configure an 
MPLS-based Layer 3 VPN. 


[edit] 


user@switch 


user@switch 














set routing-options static route 121.121.121.0/24 next-hop 208.208.208.208 
set routing-options static route 121.121.121.0/24 resolve 
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Configuring MPLS on Provider Edge EX8200 and EX4500 Switches Using Circuit Cross-Connect 


Junos OS MPLS for EX8200 and EX4500 switches supports Layer 2 protocols and Layer 2 virtual private 
networks (VPNs). You can configure MPLS on switches to increase transport efficiency in your network. 
MPLS services can be used to connect various sites to a backbone network and to ensure better performance 
for low-latency applications such as VoIP and other business-critical functions. 


This topic describes configuring provider edge (PE) switches in an MPLS network using a circuit 
cross-connect (CCC). The customer edge interface can be either a simple interface or a tagged VLAN 
interface. 


NOTE: If you are configuring a CCC on a tagged VLAN interface, you do not specify family ccc. 
See Configuring an MPLS-Based VLAN CCC Using a Layer 2 VPN and Configuring an MPLS-Based 
VLAN CCC Using a Layer 2 Circuit. 


NOTE: If you are going through this procedure in preparation for configuring an MPLS-based 
Layer 2 VPN, you do not need to configure the association of the label-switched path (LSP) with 
the customer edge interface. The BGP signaling automates the connections, so manual 
configuration of the connections is not required. 


The following guidelines apply to CCC configurations: 


e When an interface is configured to belong to family ccc, it cannot belong to any other family. 


e You can send any kind of traffic over a CCC, including nonstandard bridge protocol data units (BPDUs) 
generated by other vendors’ equipment. 


e If you are configuring a CCC on a tagged VLAN interface, you must explicitly enable VLAN tagging and 
specify a VLAN ID. The VLAN ID cannot be configured on logical interface unit 0. The logical unit number 
must be 1 or higher. See Configuring an MPLS-Based VLAN CCC Using a Layer 2 VPN and Configuring 
an MPLS-Based VLAN CCC Using a Layer 2 Circuit. 


This procedure shows how to set up two CCCs: 


e If you are configuring a CCC on a simple interface (ge-0/0/1), you do not need to enable VLAN tagging 
or specify a VLAN ID, so you skip those steps. 


e If you are configuring a CCC ona tagged VLAN interface (ge-0/0/2), include all the steps in this procedure. 


To configure a PE switch with a CCC: 


75 


. Configure OSPF (or IS-IS) on the loopback (or switch address) and core interfaces: 


[edit protocols] 

user@switch# set ospf area 0.0.0.0 interface lo0.0 
user@switch# set ospf area 0.0.0.0 interface ge-0/0/5.0 
user@switch# set ospf area 0.0.0.0 interface ge-0/0/6.0 





user@switch# set ospf area 0.0.0.0 interface aeO 


. Enable traffic engineering for the routing protocol: 


[edit protocols] 


user@switch# set ospf traffic-engineering 


. Configure an IP address for the loopback interface and for the core interfaces: 


[edit] 





user@switch# set interfaces loO unit O family inet address 127.1.1.1/32 








user@switch# set interfaces ge-0/0/5 unit O family inet address 10.1.5.1/24 
user@switch# set interfaces ge-0/0/6 unit O family inet address 10.1.6.1/24 





user@switch# set interfaces aeO unit O family inet address 10.1.9.1/24 
. Enable MPLS and define the LSP: 


[edit protocols] 
user@switch# set mpls label-switched-path Isp_to_pe2_ge1 to 127.1.1.3 


TIP: Isp_to_pe2_ge1 is the LSP name. You will need to use the specified name again when 
configuring the CCC. 


. Configure MPLS on the core interfaces: 


[edit protocols] 
user@switch# set mpls interface ge-0/0/5.0 
user@switch# set mpls interface ge-0/0/6.0 


user@switch# set mpls interface aeO 


. Configure RSVP on the loopback interface and the core interfaces: 


[edit protocols] 
user@switch# set rsvp interface lo0.0 


user@switch# set rsvp interface ge-0/0/5.0 
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user@switch# set rsvp interface ge-0/0/6.0 


user@switch# set rsvp interface aeO 
7. Configure family mpls on the logical units of the core interfaces: 


[edit] 





user@switch# set interfaces ge-0/0/5 unit O family mpls 








user@switch# set interfaces ge-0/0/6 unit O family mpls 





user@switch# set interfaces aeO unit O family mpls 


NOTE: You can enable family mpls on either individual interfaces or aggregated Ethernet 
interfaces. You cannot enable it on tagged VLAN interfaces. 


8. If you are configuring a CCC on a tagged VLAN interface, enable VLAN tagging on the customer edge 
interface ge-0/0/2 of the local PE switch: 


[edit interfaces ge-0/0/2] 


user@switch# set vlan-tagging 


If you are configuring a CCC on a simple interface (ge-0/0/1), omit this step. 


9. If you are configuring a CCC on a tagged VLAN interface, configure the logical unit of the customer 
edge interface with a VLAN ID: 


[edit interfaces ge-0/0/2 unit 1] 
user@switch# set vlan-id 100 


If you are configuring a CCC on a simple interface (ge-0/0/1), omit this step. 
10. Configure the logical unit of the customer edge interface to belong to family ccc: 
e Ona simple interface: 


[edit interfaces ge-0/0/1 unit 0] 


user@switch# set family ccc 


e Ona tagged VLAN interface: 


[edit interfaces ge-0/0/2 unit 1] 


user@switch# set family ccc 


11. Associate the CCC interface with two LSPs, one for transmitting MPLS packets and the other for 
receiving MPLS packets: 


NOTE: If you are configuring a Layer 2 VPN, omit this step. The BGP signaling automates 
the connections, so manual configuration of the connections is not required. 


e Ona simple interface: 


[edit protocols] 


user@switch 
user@switch 


user@switch 














set connections remote-interface-switch ge-1-to-pe2 interface ge-0/0/1.0 
set connections remote-interface-switch ge-1-to-pe2 transmit-Isp Isp_to_pe2_ge1 


set connections remote-interface-switch ge-1-to-pe2 receive-Isp Isp_to_pe1_ge1 


On a tagged VLAN interface: 


[edit protocols] 


user@switch 
user@switch 


user@switch 














set connections remote-interface-switch ge-1-to-pe2 interface ge-0/0/2.1 
set connections remote-interface-switch ge-1-to-pe2 transmit-Isp Isp_to_pe2_ge1 


set connections remote-interface-switch ge-1-to-pe2 receive-Isp Isp_to_pe1_ge1 


TIP: The transmit-Isp option specifies the LSP name that was configured on PE-1 (the local 
PE switch) by the label-switched-path statement within the [edit protocols mpls] hierarchy. 
The receive-Isp option specifies the LSP name that was configured on PE-2 (the remote PE 
switch) by the label-switched-path statement within the [edit protocols mpls] hierarchy. 


When you have completed configuring one PE switch, follow the same procedures to configure the other 


PE switch. 
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Configuring MPLS on EX8200 and EX4500 Provider Switches 


You can configure MPLS on EX8200 and EX4500 switches to increase transport efficiency in your network. 


MPLS services can b 
for low-latency app 


e used to connect various sites to a backbone network and to ensure better performance 
lications such as VoIP and other business-critical functions. 


To implement MPLS on EX Series switches, you must configure at least one provider switch as a transit 

switch for the MPLS packets. The configuration of all the provider switches remains the same regardless 
of whether the provider edge (PE) switches are using circuit cross-connect (CCC) or using MPLS over IP 
for the customer edge interfaces. Likewise, you do not need to change the configuration of the provider 
switches if you implement an MPLS-based Layer 2 VPN, Layer 3 VPN, or a Layer 2 circuit configuration. 


MPLS requires the configuration of a routing protocol (OSPF or IS-IS) on the core interfaces and the 
loopback interface of all the switches. This procedure includes the configuration of OSPF on the provider 
switch. For information on configuring IS-IS as the routing protocol, see Junos OS Routing Protocols 


Configuration Guide. 


To configure the provider switch, complete the following tasks: 


1. Enable the routing protocol (OSPF or IS-IS) on the loopback interface and on the core interfaces: 


NOTE: You can use the switch address as an alternative to the loopback interface. 


[edit protocols] 


user@switch# set ospf area 0.0.0.0 interface lo0.0 


user@switch# 


user@switch# 





set ospf area 0.0.0.0 interface ge-0/0/5.0 
set ospf area 0.0.0.0 interface ge-0/0/6.0 


user@switch# set ospf area 0.0.0.0 interface aeO 


2. Enable traffic engineering for the routing protocol (traffic engineering must be explicitly enabled for 


OSPF): 


[edit protocols] 


user@switch# set ospf traffic-engineering 


3. Enable MPLS within the protocols stanza and apply it to the core interfaces: 


[edit protocols] 


user@switch# set mpls interface ge-0/0/5.0 


user@switch# set mpls interface ge-0/0/6.0 


user@switch# set mpls interface aeO 
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4. Configure RSVP on the loopback interface and the core interfaces: 


5. 


6. 


[edit protocols] 


user@switch# 
user@switch# 


user@switch# 


t set rsvp interface lo0.0 
set rsvp interface ge-0/0/5.0 
set rsvp interface ge-0/0/6.0 





user@switch# 
Configure an IP 


[edit] 


t set rsvp interface aeO 


address for the loopback interface and for the core interfaces: 





user@switch 


set interfaces loO unit O family inet address 127.1.1.1/32 





user@switch 


user@switch# 


set interfaces ge-0/0/5 unit O family inet address 10.1.5.1/24 
set interfaces ge-0/0/6 unit O family inet address 10.1.6.1/24 











user@switch 


set interfaces aeO unit O family inet address 10.1.9.2/24 


Configure family mpls on the logical units of the core interfaces: 


[edit] 





user@switch 





set interfaces ge-0/0/5 unit O family mpls 





user@switch 


set interfaces ge-0/0/6 unit O family mpls 





user@switch# 


set interfaces aeO unit O family mpls 


NOTE: You can enable family mpls on either individual interfaces or aggregated Ethernet 


interfaces 


. You cannot enable it on tagged VLAN interfaces. 
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Configuring IPv6 Tunneling for MPLS 


You can configure the IPv6 tunneling for MPLS to tunnel IPvé6 traffic over an MPLS-based IPv4 network. 
This configuration allows you to interconnect a number of smaller IPv6 networks over an IPv4-based 
network core, giving you the ability to provide IPv6 service without having to upgrade the switches in 
your core network. BGP is configured to exchange routes between the IPv6 networks, and data is tunneled 
between these IPv6é networks by means of IPv4-based MPLS. 


To configure IPv6é tunneling for MPLS on your EX Series switch: 


1. Configure IPv4 and IPvé6 IP addresses for all the core interfaces: 


[edit] 
user@switch# set interfaces interface-name unit logical-unit-number family inet address address 


2. Configure the number assigned to you by the Network Information Center (NIC) as the autonomous 
system (AS) number 


[edit routing-options] 
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user@switch# set autonomous-system number 


. Advertise label O to the egress router of the LSP: 


[edit protocols] 


user@switch# set mpls explicit-null 


. Configure the LSP to allow IPv6 routes to be resolved over an MPLS network by converting all routes 
stored in the inet3 routing table to IPv4-mapped IPv6 addresses and then copying them into the inet6.3 
routing table: 


[edit protocols] 


user@switch# set mpls ipv6é-tunneling 


. Set the local AS number: 


[edit protocols bgp] 


user@switch# set local-as local-autonomous-system-number 


. Configure the default import and export policies: 


[edit protocols bgp] 





user@switch# set local-address address 








user@switch# set import default-import 


user@switch# set family inet6 labeled-unicast explicit-null 





user@switch# set export default-export 


. Configure a BGP group that recognizes only the specified BGP systems as peers. Define a group name, 
group type, local end of a BGP session, and a neighbor (peer). To configure multiple BGP peers, include 
multiple neighbor statements: 


[edit protocols bgp] 

user@switch# set group group-name type internal 

user@switch# set group group-name local-address address-of-the-local-end-of-a-bgp-session 
user@switch# set group group-name family inet6 labeled-unicast explicit-null 


user@switch# set group group-name peer-as peer-autonomous-system-number 








user@switch# set group group-name neighbor address family inet6 labeled-unicast explicit-null 
. Configure routing options to accept the default import and export policies: 


[edit policy-options] 
user@switch# set policy-statement default-import then accept 


user@switch# set policy-statement default-export then accept 
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Example: Tunneling IPv6 Traffic over MPLS IPv4 Networks 
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This example shows how to configure the Junos OS to tunnel IPv6é over an MPLS-based IPv4 network. 
External BGP (EBGP) is used between the customer edge (CE) and provider edge (PE) devices. The remote 
CE devices have different AS numbers for loop detection. 


Requirements 


No special configuration beyond device initialization is required before you configure this example. 


Overview 


Detailed information about the Juniper Networks implementation of IPv6 over MPLS is described in the 
following Internet drafts: 


e Internet draft draft-ietf-I3vpn-bgp-ipv6-07.txt, BGP-MPLS IP VPN extension for IPvé VPN (expires January 
2006) 


e Internet draft draft-ooms-véops-bgp-tunnel-06.txt, Connecting IPvé Islands over IPv4 MPLS using IPvé 
Provider Edge Routers (expires July 2006) 


These Internet drafts are available on the IETF website at http://www.ietf.org/. 


This example shows you how to interconnect a two IPv6 networks over an IPv4-based network core, 
giving you the ability to provide IPv6 service without having to upgrade the routers in your core network. 
Multiprotocol Border Gateway Protocol (MP-BGP) is configured to exchange routes between the IPvé 
networks, and data is tunneled between these IPv6 networks by means of IPv4-based MPLS. 


In Figure 3 on page 83, Routers PE1 and PE2 are dual-stack BGP routers, meaning they have both IPv4 
and IPvé6 stacks. The PE routers link the IPv6 networks through the customer edge (CE) routers to the 
IPv4 core network. The CE routers and the PE routers connect through a link layer that can carry IPv6 
traffic. The PE routers use IPv6 on the CE router-facing interfaces and use IPv4 and MPLS on the core-facing 
interfaces. Note that one of the connected IPv6é networks could be the global IPvé6 Internet. 


Figure 3: IPv6 Networks Linked by MPLS IPv4 Tunnels 
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The two PE routers are linked through an MP-BGP session using IPv4 addresses. They use the session to 
exchange IPvé6 routes with an IPv6 (value 2) address family indicator (AFI) and a subsequent AFI (SAFI) 
(value 4). Each PE router sets the next hop for the IPv6 routes advertised on this session to its own IPv4 
address. Because MP-BGP requires the BGP next hop to correspond to the same address family as the 
network layer reachability information (NLRI), this IPv4 address needs to be embedded within an IPv6é 
format. 


The PE routers can learn the IPv6 routes from the CE routers connected to them using routing protocols 
Routing Information Protocol next generation (RIPng) or MP-BGP, or through static configuration. Note 
that if BGP is used as the PE-router-to-CE-router protocol, the MP-BGP session between the PE router 
and CE router could occur over an IPv4 or IPv6 Transmission Control Protocol (TCP) session. Also, the 
BGP routes exchanged on that session would have SAFI unicast. You must configure an export policy to 
pass routes between IBGP and EBGP, and between BGP and any other protocol. 


The PE routers have MPLS LSPs routed to each others’ IPv4 addresses. IPv4 provides signaling for the 
LSPs by means of either LDP or RSVP. These LSPs are used to resolve the next-hop addresses of the IPv6 
routes learned from MP-BGP. The next hops use IPv4-mapped IPvé addresses, while the LSPs use IPv4 
addresses. 


The PE routers always advertise IPv6 routes to each other using a label value of 2, the explicit null label 
for IPv6 as defined in RFC 3032, MPLS Label Stack Encoding. As a consequence, each of the forwarding 
next hops for the IPv6 routes learned from remote PE routers normally push two labels. The inner label 
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is 2 (this label could be different if the advertising PE router is not a Juniper Networks routing platform), 
and the outer label is the LSP label. If the LSP is a single-hop LSP, then only Label 2 is pushed. 


It is also possible for the PE routers to exchange plain IPv6 routes using SAFI unicast. However, there is 
one major advantage in exchanging labeled IPv6 routes. The penultimate-hop router for an MPLS LSP can 
pop the outer label and then send the packet with the inner label as an MPLS packet. Without the inner 
label, the penultimate-hop router would need to discover whether the packet is an IPv4 or IPv6é packet to 
set the protocol field in the Layer 2 header correctly. 


When the PE1 router in Figure 3 on page 83 receives an IPv6 packet from the CE1 router, it performs a 

lookup in the IPvé6 forwarding table. If the destination matches a prefix learned from the CE2 router, then 
no labels need to be pushed and the packet is simply sent to the CE2 router. If the destination matches a 
prefix that was learned from the PE2 router, then the PE1 router pushes two labels onto the packet and 
sends it to the provider router. The inner label is 2 and the outer label is the LSP label for the PE2 router. 


Each provider router in the service provider's network handles the packet as it would any MPLS packet, 
swapping labels as it passes from provider router to provider router. The penultimate-hop provider router 
for the LSP pops the outer label and sends the packet to the PE2 router. When the PE2 router receives 
the packet, it recognizes the IPvé6 explicit null label on the packet (Label 2). It pops this label and treats it 
as an IPv6 packet, performing a lookup in the IPv6 forwarding table and forwarding the packet to the CE3 
router. 


This example includes the following settings: 


In addition to configuring the family inet6 statement on all the CE router-facing interfaces, you must 
also configure the statement on all the core-facing interfaces running MPLS. Both configurations are 
necessary because the router must be able to process any IPvé6 packets it receives on these interfaces. 
You should not see any regular IPvé6 traffic arrive on these interfaces, but you will receive MPLS packets 
tagged with Label 2. Even though Label 2 MPLS packets are sent in IPv4, these packets are treated as 
native IPv6 packets. 


You enable IPvé6 tunneling by including the ipv6-tunneling statement in the configuration for the PE 


routers. This statement allows IPvé6 routes to be resolved over an MPLS network by converting all routes 
stored in the inet.3 routing table to |Pv4-mapped IPvé6 addresses and then copying them into the inet6.3 
routing table. This routing table can be used to resolve next hops for both inet6 and inet6-vpn routes. 


NOTE: BGP automatically runs its import policy even when copying routes from a primary 
routing table group to a secondary routing table group. If IPv4 labeled routes arrive froma 
BGP session (for example, when you have configured the labeled-unicast statement at the 
[edit protocols bgp family inet] hierarchy level on the PE router), the BGP neighbor's import 
policy also accepts IPvé6 routes, since the neighbor's import policy is run while doing the copy 
operation to the inet6.3 routing table. 
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e When you configure MP-BGP to carry IPv6 traffic, the IPv4 MPLS label is removed at the destination 
PE router. The remaining IPvé packet without a label can then be forwarded to the IPv6é network. To 
enable this, include the explicit-null statement in the BGP configuration. 


Configuration 


IN THIS SECTION 


@ Configuring Device PE1 | 88 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


Device PE1 


set interfaces fe-1/2/0 unit 2 family inet6 address ::10.1.1.2/126 
set interfaces fe-1/2/0 unit 2 family mpls 

set interfaces fe-1/2/1 unit 5 family inet address 10.1.1.5/30 
set interfaces fe-1/2/1 unit 5 family inet6 

set interfaces fe-1/2/1 unit 5 family mpls 

set interfaces loO unit 2 family inet address 1.1.1.2/32 

set protocols mpls ipv6-tunneling 

set protocols mpls interface fe-1/2/0.2 

set protocols mpls interface fe-1/2/1.5 

set protocols bgp group toCE1 type external 

set protocols bgp group toCE1 local-address ::10.1.1.2 

set protocols bgp group toCE1 family inet6 unicast 

set protocols bgp group toCE1 export send-bgp6 

set protocols bgp group toCE1 peer-as 1 

set protocols bgp group toCE1 neighbor ::10.1.1.1 

set protocols bgp group toPE2 type internal 

set protocols bgp group toPE2 local-address 1.1.1.2 

set protocols bgp group toPE2 family inet6 labeled-unicast explicit-null 
set protocols bgp group toPE2 export next-hop-self 

set protocols bgp group toPE2 export send-v6 

set protocols bgp group toPE2 neighbor 1.1.1.4 

set protocols ospf area 0.0.0.0 interface fe-1/2/1.5 

set protocols ospf area 0.0.0.0 interface lo0.2 passive 

set protocols Idp interface fe-1/2/1.5 


set policy-options policy-statement next-hop-self then next-hop self 
set policy-options policy-statement send-bgpé6 from family inet6 

set policy-options policy-statement send-bgpé6 from protocol bgp 
set policy-options policy-statement send-bgpé6 then accept 

set policy-options policy-statement send-vé6 from family inet6 

set policy-options policy-statement send-vé6 from protocol bgp 

set policy-options policy-statement send-vé6 from protocol direct 
set policy-options policy-statement send-vé6 then accept 

set routing-options router-id 1.1.1.2 

set routing-options autonomous-system 2 


Device PE2 


set interfaces fe-1/2/0 unit 10 family inet address 10.1.1.10/30 

set interfaces fe-1/2/0 unit 10 family inet6 

set interfaces fe-1/2/0 unit 10 family mpls 

set interfaces fe-1/2/1 unit 13 family inet6 address ::10.1.1.13/126 
set interfaces fe-1/2/1 unit 13 family mpls 

set interfaces loO unit 4 family inet address 1.1.1.4/32 

set protocols mpls ipv6-tunneling 

set protocols mpls interface fe-1/2/0.10 

set protocols mpls interface fe-1/2/1.13 

set protocols bgp group toPE1 type internal 

set protocols bgp group toPE1 local-address 1.1.1.4 

set protocols bgp group toPE1 family inet6 labeled-unicast explicit-null 
set protocols bgp group toPE1 export next-hop-self 

set protocols bgp group toPE1 export send-v6 

set protocols bgp group toPE1 neighbor 1.1.1.2 

set protocols bgp group toCE3 type external 

set protocols bgp group toCE3 local-address ::10.1.1.13 

set protocols bgp group toCE3 family inet6 unicast 

set protocols bgp group toCE3 export send-bgp6 

set protocols bgp group toCE3 peer-as 3 

set protocols bgp group toCE3 neighbor ::10.1.1.14 

set protocols ospf area 0.0.0.0 interface fe-1/2/0.10 

set protocols ospf area 0.0.0.0 interface lo0.4 passive 

set protocols Idp interface fe-1/2/0.10 

set policy-options policy-statement next-hop-self then next-hop self 
set policy-options policy-statement send-bgpé6 from family inet6 
set policy-options policy-statement send-bgpé6 from protocol bgp 
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set policy-options policy-statement send-bgpé6 then accept 

set policy-options policy-statement send-vé6 from family inet6 
set policy-options policy-statement send-vé from protocol bgp 
set policy-options policy-statement send-vé6 from protocol direct 
set policy-options policy-statement send-v6 then accept 

set routing-options router-id 1.1.1.4 

set routing-options autonomous-system 2 


Device P 


set interfaces fe-1/2/0 unit 6 family inet address 10.1.1.6/30 
set interfaces fe-1/2/0 unit 6 family inet6 

set interfaces fe-1/2/0 unit 6 family mpls 

set interfaces fe-1/2/1 unit 9 family inet address 10.1.1.9/30 
set interfaces fe-1/2/1 unit 9 family inet6 

set interfaces fe-1/2/1 unit 9 family mpls 

set interfaces loO unit 3 family inet address 1.1.1.3/32 

set protocols mpls interface fe-1/2/0.6 

set protocols mpls interface fe-1/2/1.9 

set protocols ospf area 0.0.0.0 interface fe-1/2/0.6 

set protocols ospf area 0.0.0.0 interface fe-1/2/1.9 

set protocols ospf area 0.0.0.0 interface lo0.3 passive 

set protocols Idp interface fe-1/2/0.6 

set protocols Idp interface fe-1/2/1.9 

set routing-options router-id 1.1.1.3 

set routing-options autonomous-system 2 


Device CE1 


set interfaces fe-1/2/0 unit 1 family inet6 address ::10.1.1.1/126 
set interfaces loO unit 1 family inet6 address ::1.1.1.1/128 

set protocols bgp group toPE1 type external 

set protocols bgp group toPE1 local-address ::10.1.1.1 

set protocols bgp group toPE1 family inet6 unicast 

set protocols bgp group toPE1 export send-v6 

set protocols bgp group toPE1 peer-as 2 

set protocols bgp group toPE1 neighbor ::10.1.1.2 


set policy-options policy-statement send-vé6 from family inet6 
set policy-options policy-statement send-vé6 from protocol direct 
set policy-options policy-statement send-vé6 then accept 

set routing-options router-id 1.1.1.1 

set routing-options autonomous-system 1 


Device CE3 


set interfaces fe-1/2/0 unit 14 family inet6 address ::10.1.1.14/126 
set interfaces loO unit 5 family inet6 address ::1.1.1.5/128 

set protocols bgp group toPE2 type external 

set protocols bgp group toPE2 local-address ::10.1.1.14 

set protocols bgp group toPE2 family inet6 unicast 

set protocols bgp group toPE2 export send-v6 

set protocols bgp group toPE2 peer-as 2 

set protocols bgp group toPE2 neighbor ::10.1.1.13 

set policy-options policy-statement send-vé6 from family inet6 
set policy-options policy-statement send-vé6 from protocol direct 
set policy-options policy-statement send-v6 then accept 

set routing-options router-id 1.1.1.5 

set routing-options autonomous-system 3 


Configuring Device PE1 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device PE1: 


1. Configure the interfaces. 


[edit interfaces] 

user@PE1# set fe-1/2/0 unit 2 family inet6 address ::10.1.1.2/126 
user@PE1# set fe-1/2/0 unit 2 family mpls 

user@PE1# set fe-1/2/1 unit 5 family inet address 10.1.1.5/30 
user@PE1# set fe-1/2/1 unit 5 family inet6 

user@PE1# set fe-1/2/1 unit 5 family mpls 

user@PE1# set loO unit 2 family inet address 1.1.1.2/32 
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2. Configure MPLS on the interfaces. 


[edit protocols mpls] 

user@PE1# set ipv6-tunneling 
user@PE11# set interface fe-1/2/0.2 
user@PE1# set interface fe-1/2/1.5 


3. Configure BGP. 


[edit protocols bgp] 

user@PE1# set group toCE1 type external 
user@PE1# set group toCE1 local-address ::10.1.1.2 
user@PE1# set group toCE1 family inet6 unicast 
user@PE1# set group toCE1 export send-bgp6 
user@PE1# set group toCE1 peer-as 1 

user@PE1# set group toCE1 neighbor ::10.1.1.1 
user@PE1# set group toPE2 type internal 
user@PE1# set group toPE2 local-address 1.1.1.2 
user@PE1# set group toPE2 family inet6 labeled-unicast explicit-null 
user@PE1# set group toPE2 export next-hop-self 
user@PE1# set group toPE2 export send-v6 
user@PE1# set group toPE2 neighbor 1.1.1.4 


4. Configure OSPF 


[edit protocols ospf area 0.0.0.0] 
user@PE1# set interface fe-1/2/1.5 
user@PE1# set interface lo0.2 passive 


5. Configure a signaling protocol. 


[edit protocols] 
user@PE1# set Idp interface fe-1/2/1.5 


6. Configure the routing policies. 


[edit policy-options] 

user@PE1# set policy-statement next-hop-self then next-hop self 
user@PE1# set policy-statement send-bgpé from family inet6 
user@PE1# set policy-statement send-bgpé6 from protocol bgp 
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user@PE1# set policy-statement send-bgpé then accept 
user@PE1# set policy-statement send-v6 from family inet6 
user@PE1# set policy-statement send-vé6 from protocol bgp 
user@PE1# set policy-statement send-vé6 from protocol direct 
user@PE1# set policy-statement send-vé6 then accept 


7. Configure the router ID and the autonomous system (AS) number. 


[edit routing-options] 
user@PE1# set router-id 1.1.1.2 
user@PE1# set autonomous-system 2 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, 
show protocols, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


user@R1# show interfaces 
fe-1/2/0 { 
unit 2 { 
family ineté { 
address ::10.1.1.2/126; 
} 


family mpls; 


} 
fe-1/2/1 { 
unit 5 { 
family inet { 
address 10.1.1.5/30; 
} 
family inet6; 
family mpls; 


} 
loO { 
unit 2 { 
family inet { 
address 1.1.1.2/32; 


user@R1# show policy-options 
policy-statement next-hop-self { 
then { 
next-hop self; 


} 
policy-statement send-bgpé { 
from { 
family inet6; 
protocol bgp; 
} 
then accept; 
} 
policy-statement send-vé6 { 
from { 
family ineté; 
protocol [ bgp direct ]; 
} 


then accept; 


user@R1# show protocols 
mpls { 
ipv6-tunneling; 
interface fe-1/2/0.2; 
interface fe-1/2/1.5; 
} 
bgp { 
group toCE1 { 
type external; 
local-address ::10.1.1.2; 
family ineté { 
unicast; 
} 
export send-bgp6; 
peer-as 1; 
neighbor ::10.1.1.1; 
} 
group toPE2 { 
type internal; 
local-address 1.1.1.2; 
family ineté { 
labeled-unicast { 
explicit-null; 
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} 


export [ next-hop-self send-vé ]; 
neighbor 1.1.1.4; 


} 
ospf { 
area 0.0.0.0 { 
interface fe-1/2/1.5; 
interface lo0.2 { 


passive; 


} 
Idp { 
interface fe-1/2/1.5; 


user@R1# show routing-options 
router-id 1.1.1.2; 
autonomous-system 2; 


If you are done configuring the device, enter commit from configuration mode. 
Configure the other devices in the topology, as shown in “CLI Quick Configuration” on page 85. 


Verification 


IN THIS SECTION 


@ Verifying That the CE Devices Have Connectivity | 92 


Confirm that the configuration is working properly. 
Verifying That the CE Devices Have Connectivity 


Purpose 


Make sure that the tunnel is operating. 


Action 


From operational mode, enter the ping command. 


user@CE1> ping ::10.1.1.14 
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PINES (SG=L40srereS loyices)) 32 iLO. 1.il == gsil@,i1.,1,14 





16 bytes from ::10.1.1.14, icmp_seq=0 hlim=61 time=10.687 ms 
16 bytes from ::10.1.1.14, icmp_seq=1 hlim=61 time=9.239 ms 





16 bytes from ::10.1.1.14, icmp_seq=2 hlim=61 time=1.842 ms 





user@CE3> ping ::10.1.1.1 





PINES (SG=AOsreHeS lonyices)) ge ilO oi, —=S gell@oi,ieil 
16 bytes from ::10.1.1.1, icmp_seq=0 hlim=61 time=1.484 ms 








16 bytes from ::10.1.1.1, icmp_seq=1 hlim=61 time=1.338 ms 
16 bytes from ::10.1.1.1, icmp_seq=2 hlim=61 time=1.351 ms 





Meaning 


The IPv6 CE devices can communicate over the core IPv4 network. 
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Example: Configuring Next-Hop-Based MPLS-Over-UDP Dynamic Tunnels 


IN THIS SECTION 


Requirements | 94 
Overview | 94 

Configuration | 98 
Verification | 106 


Troubleshooting | 111 


This example shows how to configure a dynamic MPLS-over-UDP tunnel that includes a tunnel composite 
next hop. The MPLS-over-UDP feature provides a scaling advantage on the number of IP tunnels supported 
on a device. 


Starting in Junos OS Release 18.3R1, MPLS-over-UDP tunnels are supported on PTX Series routers and 
QF&X Series switches. For every dynamic tunnel configured on a PTX router or a QFX switch, a tunnel 
composite next hop, an indirect next hop, and a forwarding next hop is created to resolve the tunnel 
destination route. You can also use policy control to resolve the dynamic tunnel over select prefixes by 
including the forwarding-rib configuration statement at the [edit routing-options dynamic-tunnels] 
hierarchy level. 


Requirements 


This example uses the following hardware and software components: 


e Five MX Series routers with MPCs and MICs. 


e Junos OS Release 16.2 or later running on the PE routers. 
Before you begin: 


1. Configure the device interfaces, including the loopback interface. 

2. Configure the router ID and autonmous system number for the device. 
3. Establish an internal BGP (IBGP) session with the remote PE device. 
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. Establish OSPF peering among the devices. 


Overview 


Starting with Junos OS Release 16.2, a dynamic UDP tunnel supports the creation of a tunnel composite 
next hop for every UDP tunnel configured. These next-hop-based dynamic UDP tunnels are referred to 
as MPLS-over-UDP tunnels. The tunnel composite next hop are enabled by default for the MPLS-over-UDP 
tunnels. 


MPLS-over-UDP tunnels can be bidirectional or unidirectional in nature. When the PE devices are connected 
over MPLS-over-UDP tunnels in both directions, it is called a bidirectional MPLS-over-UDP tunnel. When 
two PE devices are connected over MPLS-over-UDP tunnel in one direction, and over MPLS/IGP in the 
other direction, it is called an unidirectional MPLS-over-UDP tunnel. 


Unidirectional MPLS-over-UDP tunnels are used in migration scenarios, or in cases where two PE devices 
provide connectivity to each other over two disjoint networks. Because reverse direction tunnel does not 
exist for unidirectional MPLS-over-UDP tunnels, you must configure a filter-based MPLS-over-UDP 
decapsulation on the remote PE device for forwarding the traffic. 


Starting in Junos OS Release 18.2R1, on PTX series routers and QFX10000 with unidirectional 
MPLS-over-UDP tunnels, you must configure the remote PE device with an input filter for MPLS-over-UDP 
packets, and an action for decapsulating the IP and UDP headers for forwarding the packets in the reverse 
tunnel direction. 


For example, on the remote PE device, Device PE2, the following configuration is required for unidirectional 
MPLS-over-UDP tunnels: 


PE2 


[edit firewall filter] 

user@host# set Decap_Filter term udp_decap from protocol udp 
user@host# set Decap_Filter term udp_decap from destination-port 6635 
user@host# set Decap_Filter term udp_decap then count UDP_PKTS 
user@host# set Decap_Filter term udp_decap then decapsulate mpls-in-udp 
user@host# set Decap_Filter term def then count def_pkt 

user@host# set Decap_Filter term def then accept 


In the above sample configuration, Decap_Filter is the name of the firewall filter used for MPLS-over-UDP 
decapsulation. The term udp_decap is the input filter for accepting UDP packets on the core-facing interface 
of Device PE2, and then decapsulate the MPLS-over-UDP packets to MPLS-over-IP packets for forwarding. 


You can use the existing firewall operational mode commands, such as show firewall filter to view the 
filter-based MPLS-over-UDP decapsulation. 


For example: 


user@host >show firewall filter Decap_Filter 


Filter: Decap_Filter 
Counters: 


Name Bytes Packets 
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UDP_PKTS 16744 149 
def_pkt 13049 136 
NOTE: 


For unidirectional MPLS-over-UDP tunnels: 


e Only IPv4 address is supported as the outer header. Filter-based MPLS-over-UDP decapsulation 
does not support IPvé6 address in the outer header. 


e Only the default routing instance is supported after decapsulation. 


Starting in Junos OS Release 17.1, on MX Series routers with MPCs and MICs, the scaling limit of 
MPLS-over-UDP tunnels is increased. 


Starting in Junos Release 19.2R1, on MX Series routers with MPCs and MICs, carrier supporting carrier 
(CSC) architecture can be deployed with MPLS-over-UDP tunnels carrying MPLS traffic over dynamic IPv4 
UDP tunnels that are established between supporting carrier's PE devices. With this enhancement, the 
scaling advantage that the MPLS-over-UDP tunnels provided is further increased. The CSC support with 
MPLS-over-UDP tunnel is not supported for IPv6 UDP tunnel. 


The existing dynamic tunnel feature requires complete static configuration. Currently, the tunnel information 
received from peer devices in advertised routes is ignored. Starting in Junos OS Release 17.4R1, on MX 
Series routers, the next-hop-based dynamic MPLS-over-UDP tunnels are signaled using BGP encapsulation 
extended community. BGP export policy is used to specify the tunnel types, advertise the sender side 
tunnel information, and parse and convey the receiver side tunnel information. A tunnel is created according 
to the received type tunnel community. 


Multiple tunnel encapsulations are supported by BGP. On receiving multiple capability, the next-hop-based 
dynamic tunnel is created based on the configured BGP policy and tunnel preference. The tunnel preference 
should be consistent across both the tunnel ends for the tunnel to be set up. By default, MPLS-over-UDP 
tunnel is preferred over GRE tunnels. If dynamic tunnel configuration exists, it takes precedence over 
received tunnel community. 


When configuring a next-hop-based dynamic MPLS-over-UDP tunnel, be aware of the following 
considerations: 


e An IBGP session must be configured between the PE devices. 


e Aswitchover between the next-hop-based dynamic tunnel encapsulations (UDP and GRE) is allowed, 
and this can impact network performance in terms of the supported IP tunnel scaling values in each 
mode. 


e Having both GRE and UDP next-hop-based dynamic tunnel encapsulation types for the same tunnel 
destination leads to a commit failure. 
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For unidirectional MPLS-over-UDP tunnels, you must explicitly configure filter-based MPLS-over-UDP 
decapsulation on the remote PE device for the packets to be forwarded. 


Graceful Routing Engine switchover (GRES) is supported with MPLS-over-UDP, and the MPLS-over-UDP 
tunnel type flags are unified ISSU and NSR compliant. 


MPLS-over-UDP tunnels are supported on virtual MX (vMX). 


MPLS-over-UDP tunnels support dynamic GRE tunnel creation based upon new IPv4-mapped-IPvé6 next 


hops. 


MPLS-over-UDP tunnel are supported in interoperability with contrail, wherein the MPLS-over-UDP 
tunnels are created from the contrail vRouter to an MX gateway. To enable this, the following community 


is required to be advertised in the route from the MX Series router to the contrail vRouter: 


[edit policy-options community] 
udp members 0x030c:64512:13; 


At a given point in time, only one tunnel type is supported on the contrail vRouter—next-hop-based 
dynamic GRE tunnels, MPLS-over-UDP tunnels, or VXLAN. 


The following features are not supported with the next-hop-based dynamic MPLS-over-UDP tunnel 


configuration: 


e RSVP automatic mesh 
e Plain IPV6 GRE and UDP tunnel configuration 


e Logical systems 


Topology 


Figure 4 on page 98 illustrates a Layer 3 VPN scenario over dynamic MPLS-over-UDP tunnels. The customer 
edge (CE) devices, CE1 and CE2, connect to provider edge (PE) devices, PE1 and PE2, respectively. The 
PE devices are connected to a provider device (Device P11), and an internal BGP (IBGP) session interconnects 
the two PE devices. A dynamic next-hop-based bidirectional MPL-over-UDP tunnel is configured between 
the PE devices. 
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Figure 4: Dynamic MPLS-over-UDP Tunnels 
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MPLS-over-UDP Tunnel 


The MPLS-over-UDP tunnel is handled as follows: 


1. After a MPLS-over-UDP tunnel is configured, a tunnel destination mask route with a tunnel composite 
next hop is created for the tunnel in the inet.3 routing table. This IP tunnel route is withdrawn only 
when the dynamic tunnel configuration is deleted. 


The tunnel composite next-hop attributes include the following: 


e When Layer 3 VPN composite next hop is disabled—Source and destination address, encapsulation 
string, and VPN label. 


e When Layer 3 VPN composite next hop and per-prefix VPN label allocation are enabled—Source 
address, destination address, and encapsulation string. 


e When Layer 3 VPN composite next hop is enabled and per-prefix VPN label allocation is 
disabled—Source address, destination address, and encapsulation string. The route in this case is 
added to the other virtual routing and forwarding instance table with a secondary route. 


2. The PE devices are interconnected using an IBGP session. The IBGP route next hop to a remote BGP 
neighbor is the protocol next hop, which is resolved using the tunnel mask route with the tunnel next 
hop. 


3. After the protocol next hop is resolved over the tunnel composite next hop, indirect next hops with 
forwarding next hops are created. 


4. The tunnel composite next hop is used to forward the next hops of the indirect next hops. 


Configuration 


CLI Quick Configuration 
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To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


CE1 


set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.1/8 

set interfaces loO unit O family inet address 127.0.0.1/8 

set routing-options router-id 127.0.0.1 

set routing-options autonomous-system 200 

set protocols bgp group ce1-pe1 export export-loopback-direct 

set protocols bgp group ce1-pe1 peer-as 100 

set protocols bgp group ce1-pe1 neighbor 10.0.0.2 

set policy-options policy-statement export-loopback-direct term term-1 from interface lo0.0 

set policy-options policy-statement export-loopback-direct term term-1 from route-filter 127.0.0.1/8 
exact 

set policy-options policy-statement export-loopback-direct term term-1 then accept 


CE2 


set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.2/24 

set interfaces loO unit O family inet address 127.0.0.5/8 

set routing-options router-id 127.0.0.5 

set routing-options autonomous-system 200 

set protocols bgp group ce1-pe1 export export-loopback-direct 

set protocols bgp group ce1-pe1 peer-as 100 

set protocols bgp group ce1-pe1 neighbor 203.0.113.1 

set policy-options policy-statement export-loopback-direct term term-1 from interface lo0.0 

set policy-options policy-statement export-loopback-direct term term-1 from route-filter 127.0.0.5/8 
exact 

set policy-options policy-statement export-loopback-direct term term-1 then accept 


PE1 


set interfaces ge-0/0/0 unit 0 family inet address 10.0.0.2/8 
set interfaces ge-0/0/1 unit 0 family inet address 192.0.2.1/24 
set interfaces ge-0/0/1 unit 0 family mpls 


P1 


PE2 
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set interfaces loO unit O family inet address 127.0.0.2/8 

set routing-options static route 33.0.0.0/8 next-hop 192.0.2.2 

set routing-options router-id 127.0.0.2 

set routing-options autonomous-system 100 

set routing-options forwarding-table export pplb 

set routing-options dynamic-tunnels gre next-hop-based-tunnel 

set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe2 source-address 127.0.0.2 
set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe2 udp 

set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe2 destination-networks 127.0.0.0/8 
set protocols bgp group IBGP type internal 

set protocols bgp group IBGP local-address 127.0.0.2 

set protocols bgp group IBGP family inet-vpn unicast 

set protocols bgp group IBGP neighbor 127.0.0.4 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set routing-instances MPLS-over-UDP-PE1 instance-type vrf 

set routing-instances MPLS-over-UDP-PE1 interface ge-0/0/0.0 

set routing-instances MPLS-over-UDP-PE1 route-distinguisher 127.0.0.2:1 

set routing-instances MPLS-over-UDP-PE1 vrf-target target:600:1 

set routing-instances MPLS-over-UDP-PE1 protocols bgp group pe1-ce1 peer-as 200 
set routing-instances MPLS-over-UDP-PE1 protocols bgp group pe1-ce1 neighbor 10.0.0.1 as-override 


set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.2/24 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.1/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 127.0.0.3/8 

set routing-options router-id 127.0.0.3 

set routing-options autonomous-system 100 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 
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set interfaces ge-0/0/0 unit 0 family inet address 203.0.113.1/24 

set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.2/24 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 127.0.0.4/8 

set routing-options nonstop-routing 

set routing-options router-id 127.0.0.4 

set routing-options autonomous-system 100 

set routing-options forwarding-table export pplb 

set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe1 source-address 127.0.0.4 
set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe1 udp 

set routing-options dynamic-tunnels udp-dyn-tunnel-to-pe1 destination-networks 127.0.0.0/8 
set protocols bgp group IBGP type internal 

set protocols bgp group IBGP local-address 127.0.0.4 

set protocols bgp group IBGP family inet-vpn unicast 

set protocols bgp group IBGP neighbor 127.0.0.2 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set routing-instances MPLS-over-UDP-PE2 instance-type vrf 

set routing-instances MPLS-over-UDP-PE2 interface ge-0/0/0.0 

set routing-instances MPLS-over-UDP-PE2 route-distinguisher 127.0.0.4:1 

set routing-instances MPLS-over-UDP-PE2 vrf-target target:600:1 

set routing-instances MPLS-over-UDP-PE2 protocols bgp group ebgp peer-as 200 

set routing-instances MPLS-over-UDP-PE2 protocols bgp group ebgp neighbor 203.0.113.2 as-override 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device PE1: 


1. Configure the device interfaces including the loopback interface of the device. 


[edit interfaces] 

user@PE1# set ge-0/0/0 unit O family inet address 10.0.0.2/8 
user@PE1# set ge-0/0/1 unit 0 family inet address 192.0.2.1/24 
user@PE1# set ge-0/0/1 unit 0 family mpls 

user@PE1# set loO unit O family inet address 127.0.0.2/8 


2. Configure a static route for routes from Device PE1 with Device P1 as the next-hop destination. 
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[edit routing-options] 
user@PE1# set static route 33.0.0.0/8 next-hop 192.0.2.2 


3. Configure the router-ID and autonomous system number for Device PE1. 


[edit routing-options] 
user@PE1# set router-id 127.0.0.2 
user@PE1# set autonomous-system 100 


4. (PTX Series only) Configure policy control to resolve the MPLS-over-UDP dynamic tunnel route over 
select prefixes. 


[edit routing-options dynamic-tunnels] 
user@PTX-PE1# set forwarding-rib inet.0 inet-import dynamic-tunnel-fwd-route-import 


5. (PTX Series only) Configure the inet-import policy for resolving dynamic tunnel destination routes over 


[edit policy-options] 

user@PTX-PE1# set policy-statement dynamic-tunnel-fwd-route-import term 1 from route-filter 127.0.0.0/8 
exact 

user@PTX-PE1# set policy-statement dynamic-tunnel-fwd-route-import term 1 then accept 

user@PTX-PE1# set policy-options policy-statement dynamic-tunnel-fwd-route-import then reject 


6. Configure IBGP peering between the PE devices. 


[edit protocols] 

user@PE1# set bgp group IBGP type internal 
user@PE1# set bgp group IBGP local-address 127.0.0.2 
user@PE1# set bgp group IBGP family inet-vpn unicast 
user@PE1# set bgp group IBGP neighbor 127.0.0.4 


7. Configure OSPF on all the interfaces of Device PE1, excluding the management interface. 


[edit protocols] 
user@PE1# set ospf area 0.0.0.0 interface ge-0/0/1.0 
user@PE1# set ospf area 0.0.0.0 interface lo0.0 passive 
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8. Enable next-hop-based dynamic GRE tunnel configuration on Device PE1. 


NOTE: This step is required only for illustrating the implementation difference between 
next-hop-based dynamic GRE tunnels and MPLS-over-UDP tunnels. 


[edit routing-options] 
user@PE1# set dynamic-tunnels gre next-hop-based-tunnel 


9. Configure the MPLS-over-UDP tunnel parameters from Device PE1 to Device PE2. 


[edit routing-options] 

user@PE1# set dynamic-tunnels udp-dyn-tunnel-to-pe2 source-address 127.0.0.2 
user@PE1# set dynamic-tunnels udp-dyn-tunnel-to-pe2 udp 

user@PE1# set dynamic-tunnels udp-dyn-tunnel-to-pe2 destination-networks 127.0.0.0/8 


10. Configure a VRF routing instance on Device PE1 and other routing instance parameters. 


[edit routing-instances] 

user@PE1# set MPLS-over-UDP-PE1 instance-type vrf 

user@PE1# set MPLS-over-UDP-PE1 interface ge-0/0/0.0 
user@PE1# set MPLS-over-UDP-PE1 route-distinguisher 127.0.0.2:1 
user@PE1# set MPLS-over-UDP-PE1 vrf-target target:600:1 


11. Enable BGP in the routing instance configuration for peering with Device CE1. 


[edit routing-instances] 
user@PE1# set MPLS-over-UDP-PE1 protocols bgp group pe1-ce1 peer-as 200 
user@PE1# set MPLS-over-UDP-PE1 protocols bgp group pe1-ce1 neighbor 10.0.0.1 as-override 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 
show protocols, and show routing-instances commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


user@PE1# show interfaces 
ge-0/0/0 { 
unit O { 


family inet { 
address 10.0.0.2/8; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 192.0.2.1/24, 
} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 127.0.0.2/8; 


user@PE1# show routing-options 
static { 
route 33.0.0.0/8 next-hop 192.0.2.2; 
} 
router-id 127.0.0.2; 
autonomous-system 100; 
forwarding-table { 
export pplb; 
} 
dynamic-tunnels { 
gre next-hop-based-tunnel; 
udp-dyn-tunnel-to-pe2 { 
source-address 127.0.0.2; 
udp; 
destination-networks { 
127.0.0.0/8; 


user@PE1# show protocols 
bgp { 
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group IBGP { 
type internal; 
local-address 127.0.0.2; 
family inet-vpn { 
unicast; 
} 
neighbor 127.0.0.4; 


} 
ospf { 
area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface 100.0 { 
passive; 


user@PE1# show routing-instances 
MPLS-over-UDP-PE1 { 
instance-type vrf; 
interface ge-0/0/0.0; 
route-distinguisher 127.0.0.2:1; 
vrf-target target:600:1; 
protocols { 
bgp { 
group pe1-ce1 { 
peer-as 200; 
neighbor 10.0.0.1 { 
as-override; 


If you are done configuring the device, enter commit from configuration mode. 
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Verification 


IN THIS SECTION 


Verifying the Connection Between PE Devices | 106 
Verify the Dynamic Tunnel Routes on Device PE1 | 107 
Verify the Dynamic Tunnel Routes on Device PE2 | 109 


Verifying That the Routes Have the Expected Indirect-Next-Hop Flag | 109 


Confirm that the configuration is working properly. 


Verifying the Connection Between PE Devices 


Purpose 


Verify the BGP peering status between Device PE1 and Device PE2, and the BGP routes received from 
Device PE2. 


Action 


From operational mode, run the show bgp summary and show route receive-protocol bgp ip-address table 
bgp.I3vpn.0 commands. 





user@PE1> show bgp summary 


Groups: 2 Peers: 2 Down peers: 0 





Table Tot Paths Act Paths Suppressed History Damp State Pending 
bgp.13vpn.0 

2 a 0 0 0 0 
Peer AS Hiai2 hee OutPkt OutQ Flaps Last Up/Dwn 
State|#Active/Received/Accepted/Damped... 
127.0.0.4 100 1S) 136 0 0 HIGAs) mMSteeilol 





INGO, L3wiom.03 2/2/2/0 
MPLS-over-UDP-PE1l.inet.0: 2/2/2/0 
I) 0) Og ab 200 ILS) SS) 0 0 SeeaS) licic lol 








MPLS-over-UDP-PE1l.inet.0: 1/1/1/0 











user@PE1> show route receive-protocol bgp 127.0.0.4 table bgp.I3vpn.0 
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bgp.13vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, O hidden) 





Prefix Nexthop MED Lclpref AS path 
127 ,0.0,4913127.0.0,5/8 
ws IZ7 O50 .4 100 AO@ i 
127 Oo. .4313200.1,1.0/24 
Be sd ee Oa OE 100 iL 
Meaning 


e Inthe first output, the BGP session state is Establ, which means that the session is up and the PE devices 
are peered. 


e Inthe second output, Device PE1 has learned two BGP routes from Device PE2. 
Verify the Dynamic Tunnel Routes on Device PE1 


Purpose 


Verify the routes in the inet.3 routing table and the dynamic tunnel database information on Device PE1. 


Action 


From operational mode, run the show route table inet.3, show dynamic-tunnels database terse, show 
dynamic-tunnels database, and show dynamic-tunnels database summary commands. 





user@PE1> show route table inet.3 


inet.3: 2 destinations, 2 routes (2 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 

Ae OM OR OVES (Tunnel S00] VOO72 F313 
Tunnel 

127 0.0.4 /8 = [ieunaiareil/ SOO) |) ONO) e241, 3 alts} 


Tunnel Composite 





user@PE1> show dynamic-tunnels database terse 


Table: inet.3 


Destination-network: 127.0.0.0/8 


Destination Source Next—hop Type 


127.0.0.4/8 127 0.0.2 0xb395b10 nhid613 udp Up 





user@PE1> show dynamic-tunnels database 


Table: inet.3 


Destination-network: 55.0.0.0/8 


Destination-network: 55.66.0.0/16 


Destination-network: 55.66.77.0/24 
Tome «OS 127 .0.0.4/6 





Reference count: 2 
Next-hop type: UDP 

SOuUmec wad cisels Sigel Ain Oly One eee ulin leelEClisaueZ, 

Next hop: tunnel-composite, 0xb395b10, nhid 613 
VPN Label: Push 299776 Reference count: 3 
Traffic Statistics: Packets 0, Bytes 0 
State: Up 





user@PE1> show dynamic-tunnels database summary 


Dynamic Tunnels, Total 1 displayed 
GRE Tunnel: 





Active Tunnel Mode, Next Hop Base 
IFL Based, Total 0 displayed, Up 0, Down 0 





Nexthop Based, Total 0 displayed, Up 0, Down 0 
RSVP Tunnel: 

Total 0 displayed 
UDP Tunnel: 


Total 1 displayed, Up 1, Down 0 


Meaning 


e Inthe first output, because Device PE11 is configured with the MPLS-over-UDP tunnel, a tunnel composite 


route is created for the inet.3 routing table route entry. 


e Inthe remaining outputs, the MPLS-over-UDP tunnel is displayed with the tunnel encapsulation type, 


tunnel next hop parameters, and tunnel status. 


Status 
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Verify the Dynamic Tunnel Routes on Device PE2 


Purpose 


Verify the routes in the inet.3 routing table and the dynamic tunnel database information on Device PE2. 


Action 


From operational mode, run the show route table inet.3, and the show dynamic-tunnels database terse 
commands. 





user@PE2> show route table inet.3 


inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 

Aa OR OROy aS) es [IHS // SHON) || ONOhs Sis)e Shi 
Tunnel 

127 0.0 .2783 Janne ia, SOOO Oi 2455533 


Tunnel Composite 


user@PE1> show dynamic-tunnels database terse 





Table: inet.3 


Destination-network: 127.0.0.0/8 


Destination Source Next—hop Type Status 
Oe OMOM 2/18 127 0.0.4 0xb395450 nhid615 udp Up 
Meaning 


The outputs show the MPLS-over-UDP tunnel creation and the next-hop ID assigned as the next-hop 
interface, similar to Device PE1. 


Verifying That the Routes Have the Expected Indirect-Next-Hop Flag 


Purpose 


Verify that Device PE1 and Device PE2 are configured to maintain the indirect next hop to forwarding 
next-hop binding on the Packet Forwarding Engine forwarding table. 


Action 


From operational mode, run the show krt indirect-next-hop command on Device PE1 and Device PE2. 





user@PE1> show krt indirect-next-hop 


Indirect Nexthop: 


Index: 1048574 Protocol next-hop address: 127.0.0.4 


RIB Table: bgp.13vpn.0 
Label: Push 299776 


Policy Version: 1 





LOGS 3 

Flags: 0x0 

INH Session ID: 0x0 
INH Version ID: 0 

Ref RIB Table: unknown 


References: 1 
Oxb2ab630 


Tunnel type: UDP, Reference count: 3, nhid: 613 


Destinatvon address 127.0504, 


Source address: 127.0.0.2 


iia, acle 2, WN welosily Pugin 299776, Wilh Aeicaems joro~p—icicll 


IGP FRR Interesting proto count 
Chain IGP FRR Node Num 
IGP Resolver node (hex) 





IGP Route handle (hex) 
Tunnel 
IGP Actual Route handle (hex) 
Any 


user@PE2> show krt indirect-next-hop 





Indirect Nexthop: 


il 

iL 

OxbeicniVide 

Oxblae688 IGP rt_entry protocol 

0x0 IGP Actual rt_entry protocol 


Index: 1048575 Protocol next-hop address: 127.0.0.2 


RIB Table: bgp.13vpn.0 
Label: Push 299776 


Policy Version: 1 





LOGIES 3 3) 

Flags: 0x0 

INH Session ID: 0x0 
INH Version ID: 0 

Ref RIB Table: unknown 


References: 2 
Oxb2ab740 


Tunnel type: UDP, Reference count: 3, nhid: 615 


Destinatton, addwelsis 27.0. 0r 2), 


Source address: 127.0.0.4 


umm acl 1, Wen welosily Pugin 299776, Lith acctiems jorop—itiel 


IGP FRR Interesting proto count 
Chain IGP FRR Node Num 
IGP Resolver node (hex) 





IGP Route handle (hex) 
Tunnel 
IGP Actual Route handle (hex) 
Any 


2 

1 

Oxb3d3a28 

Oxblae634 IGP rt_entry protocol 
0x0 IGP Actual rt_entry protocol 
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Meaning 


The outputs show that a next-hop-based dynamic MPLS-over-UDP tunnel is created between the PE 
devices. 


Troubleshooting 


IN THIS SECTION 


@ = Troubleshooting Commands | 111 


To troubleshoot the next-hop-based dynamic tunnels, see: 
Troubleshooting Commands 


Problem 


The next-hop-based dynamic MPLS-over-UDP tunnel configuration is not taking effect. 


Solution 


To troubleshoot the next-hop-based MPLS-over-UDP tunnel configuration, use the following traceroute 
commands at the [edit routing-options dynamic-tunnels] statement hierarchy: 


e traceoptions file file-name 
e traceoptions file size file-size 


e traceoptions flag all 


For example: 


[edit routing-options dynamic-tunnels] 
traceoptions { 
file udp_dyn_pe1.wri size 4294967295; 
flag all; 
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Anti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels Overview 


With the rise in deployment of high-scale IP tunnels in data centers, there is a need to add security measures 
that allow users to limit malicious traffic from compromised virtual machines (VMs). One possible attack 
is the injecting of traffic into an arbitrary customer VPN from a compromised server through the gateway 
router. In such cases, anti-spoofing checks on IP tunnels ensure that only legitimate sources are injecting 
traffic into data centers from their designated IP tunnels. 


Next-hop-based dynamic IP tunnels create a tunnel composite next hop for every dynamic tunnel created 
on the device. Because next-hop-based dynamic tunnels remove the dependency on physical interfaces 
for every new dynamic tunnel configured, configuring next-hop-based dynamic tunnels provides a scaling 
advantage over the number of dynamic tunnels that can be created on a device. Starting in Junos OS 
Release 17.1, anti-spoofing capabilities for next-hop-based dynamic IP tunnels is provided for 
next-hop-based dynamic tunnels. With this enhancement, a security measure is implemented to prevent 
injecting of traffic into an arbitrary customer VPN from a compromised server through the gateway router. 


Anti-spoofing is implemented using reverse path forwarding checks in the Packet Forwarding Engine. The 
checks are implemented for the traffic coming through the tunnel to the routing instance. Currently, when 
the gateway router receives traffic from a tunnel, only the destination lookup us done and the packet is 
forwarded accordingly. When anti-spoofing protection is enabled, the gateway router also does a source 
address lookup of the encapsulation packet IP header in the VPN, in addition to the tunnel destination 
lookup. This ensures that legitimate sources are injecting traffic through their designated IP tunnels. As a 
result, anti-spoofing protection ensures that the tunnel traffic is received from a legitimate source on the 
designated tunnels. 


Figure 5 on page 113 illustrates a sample topology with the requirements for anti-spoofing protection. 
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Figure 5: Anti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels 
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In this example, the gateway router is Router G. Router G has two VPNs—Green and Blue. The two servers, 
Server A and Server B, can reach the Green and Blue VPNs on Router G through the next-hop-based 
dynamic tunnels T1 and T2, respectively. Several hosts and virtual machines (P, Q, R, S, and T) connected 
to the servers can reach the VPNs through the gateway router, Router G. Router G has the virtual routing 
and forwarding (VRF) tables for Green and Blue VPNs, each populated with the reachability information 
for the virtual machines in those VPNs. 


For example, in VPN Green, Router G uses tunnel T1 to reach host P, tunnel T2 to reach hosts R and S, 
and load balancing is done between tunnels T1 and T2 to reach the multihomed host Q. In VPN Blue, 
Router G uses tunnel T1 to reach hosts P and R, and tunnel T2 to reach hosts Q and T. 


The check passes for reverse path forwarding when: 


e A packet comes from a legitimate source on its designated tunnel. 


Host P in VPN Green sends a packet to host X using tunnel T1. Because Router G can reach host P 
through tunnel T1, it allows the packet to pass and forwards the packet to host X. 


e A packet comes from a multihomed source on its designated tunnels. 


Host Q in VPN Green is multihomed on servers A and B, and can reach Router G through tunnels T1 
and T2. Host Q sends a packet to host Y using tunnel T1, and a packet to host X using tunnel T2. Because 
Router G can reach host Q through tunnels T1 and T2, it allows the packets to pass and forwards them 
to hosts Y and X, respectively. 


Layer 3 VPNs do not have anti-spoofing protection enabled by default. To enable anti-spoofing for 


next-hop-based dynamic tunnels, include the ip-tunnel-rpf-check statement at the [edit routing-instances 


routing-instance-name routing-options forwarding-table] hierarchy level. The reverse path forwarding 


check is applied to the VRF routing instance only. The default mode is set to strict, where the packet that 


comes from a source on a nondesignated tunnel does not pass the check. The ip-tunnel-rpf-check mode 


can be set as loose, where the reverse path forwarding check fails when the packet comes froma 


nonexistent source. An optional firewall filter can be configured under the ip-tunnel-rpf-check statement 


to count and log the packets that failed the reverse path forwarding check. 


The following sample output shows an anti-spoofing configuration: 


[edit routing-instances routing-instance-name routing-options forwarding-table] 
ip-tunnel-rpf-check { 

mode loose; 

fail-filter filter-name; 


Take the following guidelines under consideration when configuring anti-spoofing protection for 


next-hop-based dynamic tunnels: 


Anti-spoofing protection can be enabled for IPv4 tunnels and IPv4 data traffic only. The anti-spoofing 
capabilities are not supported on IPvé tunnels and IPvé6 data traffic. 


Anti-spoofing for next-hop-based dynamic tunnels can detect and prevent a compromised virtual machine 
(inner source reverse path forwarding check) but not a compromised server that is label-spoofing. 


The next-hop-based IP tunnels can originate and terminate on an inet.O routing table. 


Anti-spoofing protection is effective when the VRF routing instance has label-switched interfaces (LSIs) 
(using the vrf-table-label), or virtual tunnel (VT) interfaces. With per-next-hop label on the VRF routing 
instance, anti-spoofing protection is not supported. 


The rpf fail-filter is applicable only to the inner IP packet. 


Enabling anti-spoofing checks does not affect the scaling limit of the next-hop-based dynamic tunnels 
on a device. 


The system resource utilization with anti-spoofing protection enabled for the VRF routing instance is 
slightly higher than the utilization of next-hop-based dynamic tunnels without the anti-spoofing protection 
enabled. 


Anti-spoofing protection requires additional source IP address checks, which has minimal impact on 
network performance. 


Graceful Routing Engine switchover (GRES) and in-service software upgrade (ISSU) are supported with 
anti-spoofing protection. 
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Example: Configuring Anti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels 


IN THIS SECTION 


Requirements | 115 
Overview | 115 
Configuration | 117 


Verification | 124 


This example shows how to configure reverse path forwarding checks for the virtual routing and forwarding 
(VRF) routing instance to enable anti-spoofing protection for next-hop-based dynamic tunnels. The checks 
ensure that legitimate sources are injecting traffic through their designated IP tunnels. 


Requirements 
This example uses the following hardware and software components: 
e Three MX Series Routers with MICs, each connected to a host device. 


e Junos OS Release 17.1 or later running on one or all the routers. 
Before you begin: 


e Enable tunnel services configuration on the Flexible PIC Concentrator. 

e Configure the router interfaces. 

e Configure the router-ID and assign an autonomous system number for the router. 
e Establish an internal BGP (IBGP) session with the tunnel endpoints. 

e Configure RSVP on all the routers. 

e Configure OSPF or any other interior gateway protocol on all the routers. 

e Configure two dynamic next-hop-based IP tunnels between the two routers. 


e Configure a VRF routing instance for every router-to-host connection. 


Overview 


Starting in Junos OS Release 17.1, anti-spoofing capabilities are added to next-hop-based dynamic IP 
tunnels, where checks are implemented for the traffic coming through the tunnel to the routing instance 
using reverse path forwarding in the Packet Forwarding Engine. 


Currently, when the gateway router receives traffic from a tunnel, only the destination address lookup is 
done before forwarding. With anti-spoofing protection, the gateway router does a source address lookup 
of the encapsulation packet IP header in the VPN to ensure that legitimate sources are injecting traffic 


through their designated IP tunnels. This is called the strict mode and is the default behavior of anti-spoofing 
protection. To pass traffic from nondesignated tunnels, the reverse path forwarding check is enabled in 
the lose mode. For traffic received from nonexistent sources, the reverse path forwarding check fails for 
both the strict and loose modes. 


Anti-spoofing is supported on VRF routing instances. To enable anti-spoofing for dynamic tunnels, include 
the ip-tunnel-rpf-check statement at the [edit routing-instances routing-instance-name routing-options 
forwarding-table] hierarchy level. 


Topology 


Figure 6 on page 116 illustrates a sample network topology enabled with anti-spoofing protection. Routers 
RO, R1 and R2 are each connected to hosts HostO, Host1, and Host2, respectively. Two generic routing 
encapsulation (GRE) next-hop-based dynamic tunnels, Tunnel 1 and Tunnel 2 - connect Router RO with 
Routers R1 and R2, respectively. The VRF routing instance is running between each router and its connected 
host devices. 


Figure 6: Anti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels 
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Taking as an example, three packets (Packets A, B, and C) are received on Router O from Router R2 through 
the next-hop-based dynamic GRE tunnel (Tunnel 2). The source IP address of these packets are 172.17.0.2 
(Packet A), 172.18.0.2 (Packet B), and 172.20.0.2 (Packet C). 


The source IP address of Packets A and B belong to Host 2 and Host 1, respectively. Packet C is a 
nonexistent source tunnel. The designated tunnel in this example is Tunnel 2, and the nondesignated 
tunnel is Tunnel 1. Therefore, the packets are processed as follows: 


e Packet A—Because the source is coming from a designated tunnel (Tunnel 2), Packet A passes the reverse 
path forwarding check and is processed for forwarding through Tunnel 2. 


e Packet B—Because the source is coming from Tunnel 1, which is a nondesinated tunnel, by default, 
Packet B fails the reverse path forwarding check in the strict mode. If loose mode is enabled, Packet B 
is allowed for forwarding. 


e Packet C—Because the source is anonexistent tunnel source, Packet C fails the reverse path forwarding 
check, and the packet is not forwarded. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


Router RO 


set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.1/24 

set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.1/24 

set interfaces ge-0/0/2 vlan-tagging 

set interfaces ge-0/0/2 unit 0 vian-id 1 

set interfaces ge-0/0/2 unit 0 family inet address 172.16.0.1/16 

set interfaces loO unit O family inet address 10.1.1.1/32 

set routing-options router-id 10.1.1.1 

set routing-options autonomous-system 100 

set routing-options dynamic-tunnels gre next-hop-based-tunnel 

set routing-options dynamic-tunnels T1 source-address 192.0.2.1 

set routing-options dynamic-tunnels T1 gre 

set routing-options dynamic-tunnels T1 destination-networks 192.0.2.0/24 
set routing-options dynamic-tunnels T2 source-address 198.51.100.1 

set routing-options dynamic-tunnels T2 gre 

set routing-options dynamic-tunnels T2 destination-networks 198.51.100.0/24 
set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 
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set protocols bgp group IBGP type internal 

set protocols bgp group IBGP local-address 10.1.1.1 

set protocols bgp group IBGP family inet-vpn unicast 

set protocols bgp group IBGP neighbor 20.1.1.1 

set protocols bgp group IBGP neighbor 30.1.1.1 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface all 

set routing-instances VPN1 instance-type vrf 

set routing-instances VPN11 interface ge-0/0/2.0 

set routing-instances VPN1 route-distinguisher 100:100 

set routing-instances VPN1 vrf-target target:100:1 

set routing-instances VPN1 vrf-table-label 

set routing-instances VPN1 routing-options forwarding-table ip-tunnel-rpf-check mode strict 
set routing-instances VPN1 protocols bgp group External type external 

set routing-instances VPN1 protocols bgp group External family inet unicast 
set routing-instances VPN1 protocols bgp group External peer-as 200 

set routing-instances VPN1 protocols bgp group External neighbor 172.16.0.1 


Router R1 


set interfaces ge-0/0/0 unit 0 family inet address 192.0.2.2/24 
set interfaces ge-0/0/1 vlan-tagging 

set interfaces ge-0/0/1 unit 0 vian-id 2 

set interfaces ge-0/0/1 unit 0 family inet address 172.18.0.1/16 
set interfaces loO unit O family inet address 20.1.1.1/32 

set routing-options router-id 20.1.1.1 

set routing-options autonomous-system 100 

set routing-options dynamic-tunnels gre next-hop-based-tunnel 
set routing-options dynamic-tunnels T1 source-address 192.0.2.2 
set routing-options dynamic-tunnels T1 gre 

set routing-options dynamic-tunnels T1 destination-networks 192.0.2.0/24 
set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols bgp group IBGP type internal 

set protocols bgp group IBGP local-address 20.1.1.1 

set protocols bgp group IBGP family inet-vpn unicast 

set protocols bgp group IBGP neighbor 30.1.1.1 

set protocols bgp group IBGP neighbor 10.1.1.1 

set protocols ospf traffic-engineering 
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set protocols ospf area 0.0.0.0 interface lo0.0 passive 
set protocols ospf area 0.0.0.0 interface all 

set routing-instances VPN2 instance-type vrf 

set routing-instances VPN2 interface ge-0/0/1.0 

set routing-instances VPN2 route-distinguisher 100:200 
set routing-instances VPN2 vrf-target target:200:1 

set routing-instances VPN2 vrf-table-label 


R2 


set interfaces ge-0/0/1 unit 0 family inet address 198.51.100.2/24 
set interfaces ge-0/0/2 vlan-tagging 

set interfaces ge-0/0/2 unit 0 vian-id 3 

set interfaces ge-0/0/2 unit 0 family inet address 172.17.0.1/16 
set interfaces loO unit O family inet address 30.1.1.1/32 

set routing-options router-id 30.1.1.1 

set routing-options autonomous-system 100 

set routing-options dynamic-tunnels gre next-hop-based-tunnel 
set routing-options dynamic-tunnels T2 source-address 198.51.100.2 
set routing-options dynamic-tunnels T2 gre 

set routing-options dynamic-tunnels T2 destination-networks 198.51.100.0/24 
set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols bgp group IBGP type internal 

set protocols bgp group IBGP local-address 30.1.1.1 

set protocols bgp group IBGP family inet-vpn unicast 

set protocols bgp group IBGP neighbor 20.1.1.1 

set protocols bgp group IBGP neighbor 10.1.1.1 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface all 

set routing-instances VPN3 instance-type vrf 

set routing-instances VPN3 interface ge-0/0/2.0 

set routing-instances VPN3 route-distinguisher 100:300 

set routing-instances VPN3 vrf-target target:300:1 

set routing-instances VPN3 vrf-table-label 


Step-by-Step Procedure 
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The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Router RO: 


1. Configure Router RO’s interfaces, including the loopback interface. 


[edit interfaces] 

user@RO# set ge-0/0/0 unit 0 family inet address 192.0.2.1/24 
user@RO# set ge-0/0/1 unit O family inet address 198.51.100.1/24 
user@RO# set ge-0/0/2 vlan-tagging 

user@RO# set ge-0/0/2 unit 0 vlan-id 1 

user@RO# set ge-0/0/2 unit 0 family inet address 172.16.0.1/16 
user@RO# set loO unit O family inet address 10.1.1.1/32 


2. Assign the router ID and autonomous system number for Router RO. 


[edit routing-options] 
user@RO# set router-id 10.1.1.1 
user@RO# set autonomous-system 100 


3. Configure IBGP peering between the routers. 


[edit protocols] 

user@RO# set bgp group IBGP type internal 
user@RO# set bgp group IBGP local-address 10.1.1.1 
user@RO# set bgp group IBGP family inet-vpn unicast 
user@RO# set bgp group IBGP neighbor 20.1.1.1 
user@RO# set bgp group IBGP neighbor 30.1.1.1 


4. Configure OSPF on all the interfaces of Router RO, excluding the management interface. 


[edit protocols] 

user@RO# set ospf traffic-engineering 

user@RO# set ospf area 0.0.0.0 interface 100.0 passive 
user@RO# set ospf area 0.0.0.0 interface all 


5. Configure RSVP on all the interfaces of Router RO, excluding the management interface. 


[edit protocols] 
user@RO# set rsvp interface all 
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user@RO# set rsvp interface fxp0.0 disable 


6. Enable next-hop-based dynamic GRE tunnel configuration on Router RO. 


[edit routing-options] 
user@RO# set dynamic-tunnels gre next-hop-based-tunnel 


7. Configure the dynamic GRE tunnel parameters from Router RO to Router R1. 


[edit routing-options] 

user@RO# set dynamic-tunnels T1 source-address 192.0.2.1 
user@RO# set dynamic-tunnels T1 gre 

user@RO# set dynamic-tunnels T1 destination-networks 192.0.2.0/24 


8. Configure the dynamic GRE tunnel parameters from Router RO to Router R2. 


[edit routing-options] 

user@RO# set dynamic-tunnels T2 source-address 198.51.100.1 
user@RO# set dynamic-tunnels T2 gre 

user@RO# set dynamic-tunnels T2 destination-networks 198.51.100.0/24 


9. Configure a virtual routing and forwarding (VRF) routing instance on Router RO, and assign the interface 


connecting to Host 1 to the VRF instance. 


[edit routing-instances] 

user@RO# set VPN1 instance-type vrf 

user@RO# set VPN1 route-distinguisher 100:100 
user@RO# set VPN1 vrf-target target:100:1 
user@RO# set VPN1 vrf-table-label 

user@RO# set VPN1 interface ge-0/0/2.0 


10. Configure an external BGP session with Host 1 for the VRF routing instance. 


[edit routing-instances] 

user@RO# set VPN1 protocols bgp group External type external 
user@RO# set VPN1 protocols bgp group External family inet unicast 
user@RO# set VPN1 protocols bgp group External peer-as 200 
user@RO# set VPN1 protocols bgp group External neighbor 172.16.0.1 
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11. Configure anti-spoofing protection for the VRF routing instance on Router RO. This enables reverse 
path forwarding check for the next-hop-based dynamic tunnels, T1 and T2, on Router O. 


[edit routing-instances] 
user@RO# set VPN1 routing-options forwarding-table ip-tunnel-rpf-check mode strict 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 
show protocols, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


user@RO# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 192.0.2.1/24, 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 198.51.100.1/24; 


} 
ge-0/0/2 { 
vian-tagging; 
unit O { 
vilan-id 1; 
family inet { 
address 172.16.0.1/16; 


} 
loO { 
unit O { 
family inet { 
address 10.1.1.1/32; 


user@RO# show routing-options 
router-id 10.1.1.1; 
autonomous-system 100; 
dynamic-tunnels { 
gre next-hop-based-tunnel; 
Walt 
source-address 192.0.2.1; 
gre; 
destination-networks { 
192.0.2.0/24; 


} 
At 
source-address 198.51.100.1; 
gre; 
destination-networks { 
198.51.100.0/24; 


user@RO# show protocols 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 


} 
bgp { 
group IBGP { 
type internal; 
local-address 10.1.1.1; 
family inet-vpn { 
unicast; 
} 
neighbor 20.1.1.1; 
neighbor 30.1.1.1; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface 100.0 { 
passive; 
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} 


interface all; 


user@RO# show routing-instances 
VPN1 { 
instance-type vrf; 
interface ge-0/0/2.0; 
route-distinguisher 100:100; 
vrf-target target:100:1; 
vrf-table-label; 
routing-options { 
forwarding-table { 
ip-tunnel-rpf-check { 
mode strict; 


} 


protocols { 
bgp { 
group External { 
type external; 
family inet { 
unicast; 


} 
peer-as 200; 


neighbor 172.16.0.1; 


Verification 


IN THIS SECTION 


@ Verifying Basic Configuration | 125 
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Confirm that the configuration is working properly. 
Verifying Basic Configuration 


Purpose 


Verify the OSPF and BGP peering status between the Router RO and Routers R1 and R2. 


Action 


From operational mode, run the show ospf neighbor and show bgp summarycommands. 


user@RO> show ospf neighbor 


Address Interface State ID Pri Dead 
192 05202 ge-0/0/0.0 Full 2051.1, LAS Be 
IMG. 51 LOO. 2 ge-0/0/1.0 Full SHO) giles deg al 128 32 


user@RO> show bgp summary 


Groups: 2 Peers: 3 Down peers: 1 


Table Tot Paths Act Paths Suppressed History Damp State Pending 
[NGS AL Soin , (0) 

0 0 0 0 0 0 
Peer AS Lidl ee OutPkt OutO Flaps Last Up/Dwn 


State|#Active/Received/Accepted/Damped... 





20 obodot 100 182 178 0 0 1:20:27 Establ 


bgp.13vpn.0: 0/0/0/0 
SHO eH pile I 100 ASO) 229 0 0 1:41:51 Establ 


bgp.13vpn.0: 0/0/0/0 


LWA 5 1G 60) 5 i 200 0 0 0 0 1:42:08 Establ 


Meaning 


The OSPF and BGP sessions are up and running between the Routers RO, R1, and R2. 
Verifying Dynamic Tunnel Configuration 


Purpose 


Verify the status of the next-hop-based dynamic GRE tunnels between the Router RO and Routers R1 and 
R2. 


Action 


From operational mode, run the show route table inet.3, and the show dynamic-tunnels database terse 


commands. 


user@RO> show route table inet.3 


inet.3: 2 destinations, 2 routes (2 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 

OZ Oe 20/24 “(renal / SOO] OileAvesy 
Tunnel 

192 0 2,20 24 2 rwimiaSil/ 300) Mils4ye 57 








Tunnel Composite 





198,51, 100,0/24 = [wns / SOO] OileAdesy 
Tunnel 
198,51, 100,2/24 = [eons / SOO] OileAde sy 





Tunnel Composite 


user@RO> show dynamic-tunnels database terse 


Table: inet.3 


Destination-network: 192.0.2.0/24 
Destination Source Next—hop Type Status 


192.0 ,2,8/24 192.0.2.1 0xb395e70 nhid 612 gue Up 


Destination-network: 198.51.100.0/24 
Destination Source Next—hop Type Status 


196} 4 91 5 LOO 42 198.51.100.1 0xb395e70 nhid 612 gre Up 


Meaning 


The two next-hop-based dynamic GRE tunnels, Tunnel 1 and Tunnel 2, are up. 
Verifying Anti-Spoofing Protection Configuration 


Purpose 


Verify that the reverse path forwarding check has been enabled on the VRF routing instance on Router 


RO. 
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Action 
From the operational mode, run the show krt table VPN1.inet.0 detail. 


user@RO> show krt table VPN1.inet.0 detail 


KRT tables: 

VPN1.inet.0 : GF: 1 krt-index: 8 ID: 0 kernel-id: 8 
Flags: (null) 

tunnel rpf config data: enable, strict, filter [0], 0x2 

tunnel rpf tlv data : enable, strict, filter [0], 0x4 


unicast reverse path: disabled 





fast-reroute-priority: 0 


Permanent NextHops 


Multicast OM Baoade@atsicumanO 
Receive 0 Discard 2 0 
MUITEILOGASE IDals@euccls 0 Reject 3 0 
Local 0 Deny 5 0 
Table 0 


Meaning 
The configured reverse path forwarding check is enabled on the VRF routing instance in the strict mode. 


Next-Hop-Based Dynamic Tunnel Localization Overview 


IN THIS SECTION 


Benefits of Next-Hop-Based Dynamic Tunnel Localization | 128 

Use Cases for Next-Hop-Based Dynamic Tunnel Localization | 128 

Traffic Handling with Localization of Next-Hop-Based Dynamic Tunnels | 128 
Configuring Next-Hop-Based Dynamic Tunnels Localization | 129 
Troubleshooting Localized Next-Hop-Based Dynamic Tunnels | 132 


Unsupported Features for Next-Hop-Based Dynamic Tunnels Localization | 133 


Next-hop-based dynamic tunnels include generic routing encapsulation (GRE) tunnels and MPLS-over-UDP 
tunnels. These tunnels provide a scaling advantage over the interface-based tunnels. However, unlike the 
interface-based tunnels, the next-hop-based dynamic tunnels are anchorless in nature, where the forwarding 
information of the tunnels is distributed to the Packet Forwarding Engines (PFEs) on every line card on 


128 


the device. This limits the maximum number of tunnels supported on the device to the tunnel capacity of 
a single line card. With the support for localization, you can configure next-hop-based dynamic tunnel 
localization to create the forwarding information only on the PFE of a line card that is designated as the 
anchor PFE. The PFEs on the other line cards on the device have state forwarding information to steer 
the packets to the anchor PFE. This provides a scaling advantage by increasing the maximum number of 
tunnels supported on a device. 


Benefits of Next-Hop-Based Dynamic Tunnel Localization 


Provides a scaling advantage by increasing the maximum number of tunnels supported on a device. 


Use Cases for Next-Hop-Based Dynamic Tunnel Localization 


e The IPsec gateway devices that host anumber of MS-MPC are used to terminate IPSec tunnels and are 
required to support moderate load. This support is affected with the use of next-hop-based dynamic 
tunnels when the scaling limit of the device is reached. With the localization of next-hop-based dynamic 
tunnels, the maximum number of the tunnels supported is increased, allowing the device to accommodate 
more tunnels at the cost of an extra fabric hop. 


For Internet or VPN gateway devices, such as a virtual public cloud data center, there is a need for the 
gateway devices to communicate with a large number of servers. The data center servers are reachable 
through next-hop-based dynamic tunnels. The anchorless property of the dynamic tunnels limits the 
overall scaling numbers of the device. The gateway devices host multiple MPCs, with increased traffic 
demands. With the localization of the next-hop-based dynamic tunnels, the tunnels can be spread across 
the MPCs, thereby facilitating an increase in the tunnel scaling numbers. 


Traffic Handling with Localization of Next-Hop-Based Dynamic Tunnels 


With support for localization, the next-hop-based dynamic tunnel state is localized to an anchor Packet 
Forwarding Engine, and the other Packet Forwarding Engine has the tunnel state for steering traffic to 
the tunnel anchor. 


Figure 7 on page 128 illustrates the forwarding path of next-hop-based dynamic tunnels without localization. 


Figure 7: Forwarding Path of Next-Hop-Based Dynamic Tunnels Without Localization 
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Figure 8 on page 129 illustrates the forwarding path of next-hop-based dynamic tunnels with localization. 
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Figure 8: Forwarding Path of Next-Hop-Based Dynamic Tunnels With Localization 
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Configuring Next-Hop-Based Dynamic Tunnels Localization 


IN THIS SECTION 


@® = Configuring Localization for New Next-Hop-Based Dynamic Tunnels | 129 


® ~~ Configuring Localization for Existing Next-Hop-Based Dynamic Tunnels | 131 


Localization support can be configured for newly created next-hop-based dynamic tunnels, or for existing 
non-local dynamic tunnels. 


Configuring Localization for New Next-Hop-Based Dynamic Tunnels 


The localization of next-hop-based dynamic tunnels uses a policy-based approach to specify prefix groups. 
In other words, route policies are used to apply the localization properties to the next-hop-based dynamic 
tunnels. Dynamic tunnel attribute profiles are created and configured under routing options for association 
with the prefix group using the policy. 


1. Creating dynamic tunnel profiles. 


The dynamic tunnel profile specifies the tunnel type and the anchor Packet Forwarding Engine 
information. Multiple dynamic tunnel profiles can be created for localization of the dynamic tunnels. 


The values for the dynamic tunnel type can be GRE, UDP, or BGP-SIGNAL. 


Although BGP-SIGNAL is not a valid tunnel type, on assigning BGP-SIGNAL as the tunnel type, the 
tunnels created from the BGP-signalled attributes are localized. When using BGP-SIGNAL, the tunnel 
type is decided based on the type advertised by BGP in its TLV. BGP-SIGNAL tunnels are always 
next-hop-based tunnels. The GRE tunnels created dynamically by BGP-SIGNAL are always 
next-hop-based, even if the user has manually configured tunnels created by GRE to use IFLs. 


The anchor Packet Forwarding Engine value is the line card of the anchor Packet Forwarding Engine, 
for example, pfe-x/y/O. This information can be viewed from the show interfaces terse pfe* command 
output. 


2: 


3. 


Sample Configuration: 


[edit routing-options] 
dynamic-tunnels { 
dynamic-tunnel-attributes attribute-1 { 
dynamic-tunnel-type <GRE | UDP | BGP-SIGNAL>; 
dynamic-tunnel-anchor-pfe pfe-1/0/0; 


Associating dynamic tunnel profile to prefix list. 


Configuring a policy with dynamic-tunnel-attributes as the action associates the dynamic tunnel to 
the prefix list. The policy from action allows the creation of tunnel with specified attributes for any 
matching condition, such as a prefix range, community, or source address of BGP routes, and so on. 


Sample configuration: 


[edit policy-options] 
policy-statement policy-name { 
term term { 
from { 
<route-filter | next-hop | community>>; 


} 
then { 
dynamic-tunnel-attributes <attribute-name>; 


Including the tunnel policy under the forwarding table export policy. 


After the policy is configured, it is included in the forwarding table export policy for the parsing of the 
policy. 


Using the export-policy, the tunnel attributes get associated with the route. Whenever a route from 
BGP is queued for resolution, the forwarding table export policy is evaluated, and the tunnel attributes 
are obtained from the policy module based on the applied filters. The obtained tunnel attributes are 
then attached to the next hop in form of a tunnel composite next hop. The corresponding anchor 
forwarding structures, based on the Packet Forwarding Engine name and tunnel type, are created and 
sent to the forwarding table before a tunnel composite next hop is sent. However, if none of the 
attributes map to the tunnel composite next hop, then the forwarding structure is created on every 
Packet Forwarding Engine, similar to the non-localized dynamic tunnels. 


Sample configuration: 
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[edit routing-options] 
forwarding-table { 
export dynamic-tunnel; 


Configuring Localization for Existing Next-Hop-Based Dynamic Tunnels 
CAUTION: Making on the fly changes to dynamic tunnel attributes can result in an 
A FPC crash due to high memory utilization. Hence, we recommend deactivating the 
dynamic-tunnels configuration before configuring localization. 


To update tunnel attributes for existing next-hop-based dynamic tunnels, the following should be performed: 


1. Deactivate dynamic-tunnels configuration under the [edit routing-options] hierarchy level. 
Sample configuration: 
[edit routing-options] 


user@host# deactivate dynamic-tunnels 
user@host# commit 


2. Change tunnel attributes as required. 


3. Activate dynamic-tunnels configuration under the [edit routing-options] hierarchy level. 


Sample configuration: 


[edit routing-options] 
user@host# activate dynamic-tunnels 
user@host# commit 


To configure localization for existing non-local next-hop-based dynamic tunnels: 


F CAUTION: Making on the fly changes to configure localization for existing non-local 


A next-hop-based dynamic tunnels can result in an FPC crash due to high memory 
utilization. Hence, we recommend deactivating the dynamic-tunnels configuration 
before configuring localization. 


1. Deactivate the dynamic-tunnels configuration at the [edit routing-options] hierarchy level. 
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2. Create tunnel-attributes profile and add policy for localizing the dynamic tunnels, similar to new 


next-hop-based dynamic tunnels. 


3. Activate the dynamic-tunnels configuration. 


Troubleshooting Localized Next-Hop-Based Dynamic Tunnels 


With localization of next-hop-based dynamic tunnels, the tunnel composite next hops are associated with 


anchor Packet Forwarding Engine IDs. The following traceroute configuration statements at the [edit 


routing-options] hierarchy level help in troubleshooting the localized dynamic tunnels: 


e dynamic-tunnels traceoptions flag all—Tracking creation and deletion of tunnel in DTM. 


e resolution traceoptions flag tunnel—Tracking resolver operations on BGP route. 


e forwarding-table traceoptions flag all—Tracking tunnels sent to the kernel. 


e traceoptions flag all—Tracking of route learning process. 


The following commands can be used to check if a route is using a localized next-hop-based dynamic 


tunnel: 


1. 


show route prefix extensive—To obtain the indirect next hop. 


For example: 


user@host> show route 1.2.3.4 extensive 





MPLS-over-UDP-PE1l.inet.0: 24 destinations, 26 routes (24 active, 0 holddown, 0 
hidden) 

Le2s Sn A/32 (A Sioleiey, i aiaiovoywuavereyel)) 

WSiL8 





KRT in-kernel 1.2.3.4/32 -> {indirect (1048577) } 








Page 0 idx 1, (group pel-cel type External) Type 1 val 0xb209a78 (adv_entry) 
Advertised metrics: 
Nexthop: Self 
INS) joenclag |LLOO@] x 


Communities: target:600:1 encapsulation:mpls-—in-udp (0xd) 


. show krt indirect-next-hop index indirect-next-hop detail—To check for anchor Packet Forwarding 


Engine field in the detailed output of the indirect next hop. 


For example: 


user@host> show krt indirect-next-hop index 1048577 detail 


Indirect Nexthop detail: 
Index: 1048577 Protocol next-hop address: 1.1.1.6 


RIB Table: bgp.1l3vpn.0 Label: Push 299808 
Rolbicv aie Shon mee References: 11 
OCIS 2 $ 0xb227980 

Flags: 0x0 


INH Session ID: 0x0 
Ref RIB Table: unknown 





Export policy detail: 
(Dynamic tunnel hash : 309985522) 
Tunnel type: UDP, Reference count: 4, nhid: 1016 
DASE ALinNecwLom sielchessisg Io i.,1,6, Sewece arckcleaass : i. .2 
Anchored-PFE: pfe-1/0/0 
WEIN meloeile IWuisin 20, Iie, Acietemy jomeje—icicll 
IGP FRR Interesting proto count : 11 





Chain IGP FRR Node Num pal 
IGP Resolver node (hex) > Uxcsseo04 
IGP Route handle (hex) : Oxb1d7674 IGP rt_entry protocol : Tunnel 
IGP Actual Route handle(hex) : 0x0 IGP Actual rt_entry protocol 
; Any 


Unsupported Features for Next-Hop-Based Dynamic Tunnels Localization 


Junos OS does not support the following functionality with localization for next-hop-based dynamic tunnels: 


e Chained composite next hops at the [edit routing-options forwarding-table chained-composite-next-hop 
ingress I3vpn] hierarchy level. 


e Anchor Packet Forwarding Engine resiliency. 


There is no resiliency support for next-hop-based dynamic tunnels with localization. After localization 
of the next-hop-based dynamic tunnels, the anchor Packer Forwarding Engine becomes the single entity 
for processing any given tunnel on the device. Although anchor Packer Forwarding Engine resiliency is 
not supported, for gateway devices, redundancy at the gateway device ensures that when the Packer 
Forwarding Engine to which the tunnel composite next hop is delegated goes down, the traffic must be 
rerouted to the redundant gateway device. The routing protocol process monitors the state of the Packer 
Forwarding Engine, and withdraws BGP advertisement of all the routes pointing to the tunnel composite 
next hops anchored on that Packer Forwarding Engine. 


Only the anchored Packet Forwarding Engine has the full-fledged tunnel composite next hop and all the 
other Packet Forwarding Engines have only steering entries to forward traffic to the anchor Packet 
Forwarding Engine. These steering entries are not withdrawn, when an anchor FPC goes down. 


e Localization of next-hop-based dynamic tunnels is not supported on logical systems. 
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e IPvé6 is not supported with localization of next-hop-based dynamic tunnels. 


e With localization, the show dynamic-tunnels database summary command does not display accurate 


tunnels summary when the state of the anchor Packet Forwarding Engine line card is not up. As a 
workaround, use the show dynamic-tunnels database and show dynamic-tunnels database terse 


command output. 


Release History Table 


Release 


T9-2R1 


18.3R1 


18.2R1 


17.4R1 


17.1R1 


Description 


Starting in Junos Release 19.2R1, on MX Series routers with MPCs and MICs, carrier supporting 
carrier (CSC) architecture can be deployed with MPLS-over-UDP tunnels carrying MPLS traffic 
over dynamic IPv4 UDP tunnels that are established between supporting carrier's PE devices. 


Starting in Junos OS Release 18.3R1, MPLS-over-UDP tunnels are supported on PTX Series 
routers and QFX Series switches. 


Starting in Junos OS Release 18.2R1, on PTX series routers and QFX10000 with unidirectional 
MPLS-over-UDP tunnels, you must configure the remote PE device with an input filter for 
MPLS-over-UDP packets, and an action for decapsulating the IP and UDP headers for forwarding 
the packets in the reverse tunnel direction. 


Starting in Junos OS Release 17.4R1, on MX Series routers, the next-hop-based dynamic 
MPLS-over-UDP tunnels are signaled using BGP encapsulation extended community. 


Starting in Junos OS Release 17.1, on MX Series routers with MPCs and MICs, the scaling limit 
of MPLS-over-UDP tunnels is increased. 
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CHAPTER 5 


Managing MPLS Traffic 
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| Bidirectional Forwarding Detection (BFD) for MPLS 
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Configuring Bidirectional Forwarding Detection for MPLS (CLI Procedure) 
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@ = Configuring BFD on Provider Edge and Provider Switches for an LDP-Based LSP | 137 
@ Configuring BFD on Provider Edge and Provider Switches for an RSVP-Based LSP | 140 


You can configure the Bidirectional Forwarding Detection (BFD) protocol on EX8200 standalone switches 
and EX8200 Virtual Chassis to detect failures in the MPLS label-switch path (LSP). The BFD protocol is a 
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simple hello mechanism that detects failures in a network. Hello packets are sent at a specified, regular 
interval. A neighbor failure is detected when the routing device stops receiving a reply from the neighbor 
after a specified interval. BFD works with a wide variety of network environments and topologies. The 
failure detection timers for BFD have shorter time limits than those of the failure detection mechanisms 
for static routes, and thus provide faster detection. These timers are also adaptive. For example, a timer 
can adapt to a higher value if an adjacency fails, or a neighbor can negotiate a higher value than the one 
configured. 


This topic describes configuring the provider edge (PE) switches and the provider switches to support for 
LDP-based LSPs and RSVP-based LSPs. 


This topic includes: 


Configuring BFD on Provider Edge and Provider Switches for an LDP-Based LSP 


You can enable BFD for the LDP-based LSPs or RSVP-based LSPs associated with a specific forwarding 
equivalence class (FEC). Alternatively, you can configure an Operation Administration and Maintenance 
(OAM) ingress policy to enable BFD ona range of FEC addresses. 


Before you configure BFD for an LDP-based based LSP, you must configure the basic components for an 
MPLS network: 


e Configure two PE switches. See “Configuring MPLS on Provider Edge Switches Using IP-Over-MPLS” 
on page 68. 


e Configure one or more provider switches. See “Configuring MPLS on EX8200 and EX4500 Provider 
Switches” on page 78. 


To configure BFD on PE and provider switches: 
1. Define an OAM policy: 


[edit] 


user@switch# set protocols ldp oam ingress-policy policy-name 


2. Specify the FEC on which you want to enable OAM: 


[edit] 


user@switch# set protocols Idp oam fec address 


3. Specify the minimum transmit and receive interval for the BFD configuration: 


NOTE: If you configure the minimum-interval statement, you do not need to configure the 
minimum-receive-interval statement or the minimum-transmit-interval statement. 
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[edit] 
user@switch# set protocols Idp oam bfd-liveness-detection minimum-interval time 


or 


[edit] 
user@switch# set protocols Idp oam bfd-liveness-detection minimum-receive-interval time 


user@switch# set protocols ldp oam bfd-liveness-detection minimum-transmit-interval time 


4. Specify the detection time multiplier. The negotiated transmit interval multiplied by this value gives 
the detection time for the receiving system in Asynchronous mode: 


[edit] 


user@switch# set protocols ldp oam bfd-liveness-detection multiplier multiplier 
5. Specify the minimum transmit interval (or the minimum receive interval). 


[edit] 
user@switch# set protocols Idp oam bfd-liveness-detection transmit-interval minimum-interval 


time 
6. Specify a threshold for detecting the adaptation of the detection time: 


[edit] 


user@switch# set protocols ldp oam bfd-liveness-detection detection-time threshold time 


7. Configure route and next-hop action in the event of a BFD session failure event on the LDP-based 
LSP: 


[edit] 


user@switch# set protocols ldp oam bfd-liveness-detection failure-action action 


NOTE: When a BFD session goes down, you can configure the Junos OS to resignal the LSP 
path or to simply disable the LSP path. You can configure a standby LSP path to handle traffic 
while the primary LSP path is unavailable. The switch can automatically recover from LSP 
failures that can be detected by BFD. By default, if a BFD session fails, the event is simply 
logged. 


8. Specify how long the BFD session must be up before adding the route or next hop. Specifying a time 
of O seconds causes the route or next hop to be added as soon as the BFD session comes back up. 


[edit] 
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user@switch# set protocols ldp oam bfd-liveness-detection holddown-interval time 


9. Enable tracing of FECs for LDP-based LSPs and specify a source address for sending probes. Then, 
specify a wait interval, after which to send the probe packet. 


[edit] 
user@switch# set protocols Idp oam periodic-traceroute source address 


user@switch# set protocols Idp oam periodic-traceroute wait time 


10. Specify the duration of the LSP ping interval in seconds: 


[edit] 


user@switch# set protocols Idp oam Isp-ping-interval time 


11. Specify the action to be taken for the OAM policy: 


[edit] 


user@switch# set policy-options policy-statement policy-name then accept 


12. Apply the BFD configurations at the MPLS hierarchy level for the configuration to inherit the statements 
in the configuration group: 


[edit] 
user@switch# set apply-groups MPLS 
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Configuring BFD on Provider Edge and Provider Switches for an RSVP-Based LSP 


When BFD is configured for an RSVP-based LSP on the ingress switch, it is enabled on the primary path 
and on all standby secondary paths for that LSP. You can enable BFD for all LSPs on a switch or for specific 
LSPs. If you configure BFD for a specific LSP, whatever values configured globally for BFD are overridden 
on that LSP. The BFD sessions originate only at the ingress switch and terminate at the egress switch. 


Before you configure BFD for an RSVP-based LSP, you must configure the basic components for an MPLS 
network: 


e Configure two PE switches. See “Configuring MPLS on Provider Edge Switches Using IP-Over-MPLS” 
on page 68. 

e Configure one or more provider switches. See “Configuring MPLS on EX8200 and EX4500 Provider 
Switches” on page 78. 


To configure BFD on PE and provider switches: 


1. Specify the minimum transmit and receive interval for the BFD configuration: 


NOTE: If you configure the minimum-interval statement, you do not need to configure the 
minimum-receive-interval statement or the minimum-transmit-interval statement. 


[edit] 
user@switch# set protocols mpls label-switched-path Isp-name oam bfd-liveness-detection 


minimum-interval time 
or 


[edit] 

user@switch# set protocols mpls label-switched-path Isp-name oam bfd-liveness-detection 
minimum-receive-interval time 

user@switch# set protocols mpls label-switched-path Isp-name oam bfd-liveness-detection 


minimum-transmit-interval time 


2. Specify the detection time multiplier. The negotiated transmit interval multiplied by this value gives 
the detection time for the receiving system in Asynchronous mode: 


[edit] 
user@switch# set protocols mpls label-switched-path Isp-name oam bfd-liveness-detection multiplier 


multiplier 


3. Specify the minimum transmit interval (or the minimum receive interval): 
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[edit] 
user@switch# set protocols mpls label-switched-path Isp-name oam bfd-liveness-detection 


transmit-interval minimum-interval time 


4. Configure route and next-hop actions in the event of a BFD session failure event on the RSVP-based 
LSP: 


[edit] 
user@switch# set protocols mpls label-switched-path Isp-name oam bfd-liveness-detection 


failure-action action 


NOTE: When a BFD session goes down, you can configure the Junos OS to resignal the LSP 
path or to simply disable the LSP path. You can configure a standby LSP path to handle traffic 
while the primary LSP path is unavailable. The switch can automatically recover from LSP 
failures that can be detected by BFD. By default, if a BFD session fails, the event is simply 
logged if you do not specifically configure a failure action. 


BFD-Triggered Local Repair for Rapid Convergence 


IN THIS SECTION 


@ Understanding BFD-Triggered Local Protection | 141 


Understanding BFD-Triggered Local Protection 


IN THIS SECTION 


@ Purpose of BFD-Triggered Local Repair | 142 
@ = Configuring BFD-Triggered Local Repair | 143 
@ Disabling BFD-Triggered Local Repair | 143 


The time it takes for a network to converge following a link or node failure can vary dramatically based 
on anumber of factors, including network size, the protocols used, and network design. However, while 
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each particular convergence event is different, the process of convergence is essentially consistent. The 
failure is detected, the failure is reported (flooded) in the network, an alternate path is found for traffic, 
and the forwarding plane is updated to pass traffic on a new path. 


This overview discusses how Bidirectional Forwarding Detection (BFD)-triggered local repair contributes 
to a quicker restoration time for rapid convergence in an MPLS network. 


Purpose of BFD-Triggered Local Repair 


In Junos OS, general MPLS traffic protection for RSVP-signaled label-switched path (LSP) failures is provided 
by several complementary mechanisms. These protection mechanisms include local protection (fast reroute, 
link protection, and node-link protection) and path protection (primary and secondary paths). Local protection 
in conjunction with path protection can provide minimum packet loss for an LSP, and control the way the 
LSP is rerouted after a failure. Traditionally, both types of protection rely on fast detection of connectivity 
failure at the physical level. However, for transmission media without fast physical level detection, Junos 
OS supports BFD and MPLS ping for fast failure detection. 


With links between routers, when a route goes down, the routing protocol process recalculates the next 
best path. When MPLS fast reroute (FRR) is enabled, ifl messages are flooded to all Flexible PIC 
Concentrators (FPCs). The edge FPC enables the bypass MPLS LSP tunnel. Lastly, all routes are repaired 
and sent through the bypass MPLS LSP tunnel. The amount of time it takes to repair all routes is proportional 
to the number of routes. 


This repair scenario becomes more difficult when a switch lies between two links. See Figure 9 on page 142. 


Figure 9: Topology with BFD-Triggered Local Repair 
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When a link goes down at the remote end, the failure is not detected at the local end until the interior 
gateway protocol (IGP) goes down. To wait for the routing protocol process to recalculate the next best 
path takes too much time. 


With BFD-triggered local repair enabled, the Packet Forwarding Engine completes the repair first, using 
the bypass MPLS LSP tunnel (that is preconfigured and installed), then informs the routing protocol process 
to recalculate a new route. By doing this, when the primary MPLS LSP tunnel goes down, the FPC can 
intermittently and immediately divert traffic to the FPC with the bypass MPLS LSP tunnel. 


Using local repair in this way achieves a faster restoration time of less than 50 ms. 
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Configuring BFD-Triggered Local Repair 


BFD-triggered local repair is not configurable, but is part of the default configuration. 


BFD-triggered local repair works within the legacy Junos OS features MPLS-FRR, BFD for IGP, and loop-free 
alternates (LFAs). 


Disabling BFD-Triggered Local Repair 


By default, BFD-triggered local repair is enabled for all routing interfaces. If desired, you can disable 
BFD-triggered local repair at the [edit routing-options] hierarchy level. 


To explicitly disable BFD-triggered local repair: 


1. Include the no-bfd-triggered-local-repair statement at the [edit routing-options] hierarchy level: 


user@host # set no-bfd-triggered-local-repair 


2. (Optional) Verify your configuration settings before committing them by using the show routing-options 
command. 


user@host# run show routing-options 


Confirm your configuration by issuing the show routing-options command. 


user@host# show routing-options 


no-bfd-triggered-local-repair; 


} 


NOTE: When you disable this feature, you must also restart routing by including the 
graceful-restart statement for the IGP. For example, for OSPF, this is accomplished by including 
the graceful-restart statement at the [edit protocols ospf] hierarchy level. 


Configuring BFD for MPLS IPv4 LSPs 


You can configure Bidirectional Forwarding Detection (BFD) protocol on MPLS IPv4 LSPs as outlined in 
the Internet draft draft-ietf-bfd-mpls-O2.txt, BFD for MPLS LSPs. BFD is used as a periodic Operation, 
Administration, and Maintenance (OAM) feature for LSPs to detect LSP data plane faults. You can configure 
BFD for LSPs that use either LDP or RSVP as the signaling protocol. 
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NOTE: BFD for MPLS IPv4 LSP is based on the Routing Engine and is not distributed. As a result, 
the minimum supported BFD timer interval is (100 ms * 3) per one LSP session, and for scaled 
LSP sessions, the minimum supported BFD timer interval is (300 ms * 3). As you increase the 
number of LSP sessions with BFD, you must also increase (scale) the interval timers to support 
the network. 


For Routing Engine switchover instances with nonstop active routing (NSR) support, the minimum 
supported BFD timer interval is (2.5 seconds * 3). 


You can also use the LSP ping commands to detect LSP data plane faults. However, BFD has a couple of 
benefits: it requires less computer processing than LSP ping commands and can quickly detect faults in 
large numbers of LSPs (LSP ping commands must be issued for each LSP individually). On the other hand, 
BFD cannot be used to verify the control plane against the data plane at the egress LSR, which is possible 
when an LSP ping echo request is associated with a forwarding equivalence class (FEC). 


The BFD failure detection timers are adaptive and can be adjusted to be more or less aggressive. For 
example, the timers can adapt to a higher value if the adjacency fails, or a neighbor can negotiate a higher 
value for a timer than the configured value. The timers adapt to a higher value when a BFD session flap 
occurs more than three times in a span of 15 seconds. A back-off algorithm increases the receive (Rx) 
interval by two if the local BFD instance is the reason for the session flap. The transmission (Tx) interval 
is increased by two if the remote BFD instance is the reason for the session flap. You can use the clear 
bfd adaptation command to return BFD interval timers to their configured values. The clear bfd adaptation 
command is hitless, meaning that the command does not affect traffic flow on the routing device. 


Starting from Junos OS Release 13.2R4, 13.3R2, and 14.1, you can set the time interval between LSP ping 
messages and the number of LSP ping responses, respectively, after which the Bidirectional Forwarding 
Detection (BFD) session is brought down. To so do, you configure the Isp-ping-interval statement and the 
Isp-ping-multiplier statement at the [edit protocols mpls oam] hierarchy level. 


For configuration instructions for LDP-signaled LSPs, see “Configuring BFD for LDP LSPs” on page 908. 
For configuration instructions for RSVP-signaled LSPs, see the following section. 


Configuring BFD for RSVP-Signaled LSPs 


BFD for RSVP supports unicast IPv4 LSPs. When BFD is configured for an RSVP LSP on the ingress router, 
it is enabled on the primary path and on all standby secondary paths for that LSP. The source IP address 
for outgoing BFD packets from the egress side of an MPLS BFD session is based on the outgoing interface 
IP address. You can enable BFD for all LSPs on a router or for specific LSPs. If you configure BFD for a 
specific LSP, whatever values configured globally for BFD are overridden. The BFD sessions originate only 
at the ingress router and terminate at the egress router. 
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An error is logged whenever a BFD session for a path fails. The following example shows how BFD for 
RSVP LSP log messages might appear: 


RPD_MPLS_PATH_BFD_UP: MPLS BFD session for path pathl up on LSP RO_to_R3 
RPD_MPLS_PATH_BFD_DOWN: MPLS BFD session for path pathl down on LSP RO_to_R3 














You can configure BFD for all of the RSVP LSPs on the router, a specific LSP, or the primary path of a 
specific LSP. To configure BFD for RSVP LSPs, include the oam and bfd-liveness-detection statements. 


oam { 
bfd-liveness-detection { 
failure-action { 
make-before-break teardown-timeout seconds; 
teardown; 
} 
failure-action teardown; 
minimum-interval milliseconds; 
minimum-receive-interval milliseconds; 
minimum-transmit-interval milliseconds; 
multiplier detection-time-multiplier, 
} 
Isp-ping-interval time-interval; 
Isp-ping-multiplier multiplier; 


You can configure this statement at the following hierarchy levels: 

e [edit protocols mpls] 

e [edit protocols mpls label-switched-path Isp-name] 

e [edit protocols mpls label-switched-path Isp-name primary path-name] 


The bfd-liveness-detection statement includes the following options: 


e minimum-interval—Specifies the minimum transmit and receive interval. 


e minimum-receive-interval—Specifies the minimum receive interval. The range is from 1 through 
255,000 milliseconds. 


e minimum-transmit-interval—Specifies the minimum transmit interval. The range is from 1 through 
255,000 milliseconds. 


e Isp-ping-multiplier—Specifies the detection time multiplier. The range is from 1 through 255. 
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NOTE: To avoid triggering false negatives, configure a BFD fault detection time that is longer 
than the fast reroute time. 


You can also configure the Isp-ping-interval option to adjust the time interval between LSP pings. The LSP 
ping command for RSVP-signaled LSPs is ping mpls rsvp. For more information on the ping mpls rsvp 
command, see the CL! Explorer. 


Configuring a Failure Action for the BFD Session on an RSVP LSP 


When the BFD session for an RSVP LSP goes down, the LSP is torn down and resignaled. Traffic can be 
switched to a standby LSP, or you can simply tear down the LSP path. Any actions performed are logged. 


When a BFD session for an RSVP LSP path goes down, you can configure the Junos OS to resignal the 
LSP path or to simply disable the LSP path. A standby LSP path could be configured to handle traffic while 
the primary LSP path is unavailable. The router can automatically recover from LSP failures that can be 
detected by BFD. By default, if a BFD session fails, the event is simply logged. 


To enable the Junos OS to tear down an RSVP LSP path in the event of a BFD event, include the 
failure-action statement: 


failure-action { 
make-before-break teardown-timeout seconds; 
teardown; 


For a list of the hierarchy levels at which you can include this statement, see the statement summary 
section for this statement. 


You can configure either the teardown or make-before-break options: 


teardown—Causes the LSP path to be taken down and resignaled immediately. 


make-before-break—Causes the Junos OS to attempt to signal a new LSP path before tearing down the 


old LSP path. You can also configure the teardown-timeout option to automatically tear down the LSP 
after the time period specified if the attempt to resignal the LSP fails within the teardown-timeout 
interval. If you specify a value of O for the teardown-timeout interval, the LSP is taken down and 
resignaled immediately (the same behavior as when you configure the teardown option). 


To configure a failure action for all of the RSVP LSPs, include the failure-action statement at the [edit 
protocols mpls oam bfd-liveness-detection] hierarchy level. To configure a failure action for a specific 
RSVP LSP, include the failure-action statement at the [edit protocols mpls label-switched-path Isp-name 
oam bfd-liveness-detection] hierarchy level. 


To configure a failure action for a specific primary path, include the failure-action statement at the [edit 
protocols mpls label-switched path Isp-name primary path-name oam bfd-liveness-detection] hierarchy 
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level. To configure a failure action for a specific secondary LSP path, include the failure-action statement 
at the [edit protocols mpls label-switched-path Isp-name secondary path-name oam bfd-liveness-detection] 


hierarchy level. 
Release History Table 


Release Description 


13.2R4 Starting from Junos OS Release 13.2R4, 13.3R2, and 14.1, you can set the time interval 
between LSP ping messages and the number of LSP ping responses, respectively, after which 
the Bidirectional Forwarding Detection (BFD) session is brought down. 
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You can configure an MPLS firewall filter to count packets based on the EXP bits for the top-level MPLS 
label in a packet. You can also configure policers for MPLS LSPs. 


The following sections discuss MPLS firewall filters and policers: 


Configuring MPLS Firewall Filters 


You can configure an MPLS firewall filter to count packets based on the EXP bits for the top-level MPLS 
label in a packet. You can then apply this filter to a specific interface. You can also configure a policer for 
the MPLS filter to police (that is, rate-limit) the traffic on the interface to which the filter is attached. You 
cannot apply MPLS firewall filters to Ethernet (fxpO) or loopback (loO) interfaces. 


You can configure the following match criteria attributes for MPLS filters at the [edit firewall family mpls 
filter filter-name term term-name from] hierarchy level: 


e exp 
e exp-except 
These attributes can accept EXP bits in the range O through 7. You can configure the following choices: 


e Asingle EXP bit—for example, exp 3; 
e Several EXP bits—for example, exp 0, 4; 


e A range of EXP bits—for example, exp [0-5]; 


If you do not specify a match criterion (that is, you do not configure the from statement and use only the 
then statement with the count action keyword), all the MPLS packets passing through the interface on 
which the filter is applied will be counted. 


You also can configure any of the following action keywords at the [edit firewall family mpls filter filter-name 
term term-name then] hierarchy level: 


e count 
e accept 
e discard 
e next 

e policer 


For more information about how to configure firewall filters, see the Routing Policies, Firewall Filters, and 
Traffic Policers User Guide. For more information about how to configure interfaces, see the Junos OS 
Network Interfaces Library for Routing Devices and the Junos OS Services Interfaces Library for Routing Devices. 
Examples: Configuring MPLS Firewall Filters 

The following examples illustrate how you might configure an MPLS firewall filter and then apply the filter 


to an interface. This filter is configured to count MPLS packets with EXP bits set to either O or 4. 


The following shows a configuration for an MPLS firewall filter: 
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[edit firewall] 
family mpls { 
filter expf { 
term expt0 { 
from { 
exp 0,4; 
} 
then { 
count counterQ; 
accept; 


} 


The following shows how to apply the MPLS firewall filter to an interface: 


[edit interfaces] 
so-0/0/0 { 
mtu 4474; 
encapsulation ppp; 
sonet-options { 
fcs 32; 


} 
unit O { 
point-to-point; 
family mpls { 
filter { 
input expf; 
output expf; 
} 


The MPLS firewall filter is applied to the input and output of an interface (see the input and output 


statements in the preceding example). 


Configuring Policers for LSPs 


MPLS LSP policing allows you to control the amount of traffic forwarded through a particular LSP. Policing 
helps to ensure that the amount of traffic forwarded through an LSP never exceeds the requested bandwidth 
allocation. LSP policing is supported on regular LSPs, LSPs configured with DiffServ-aware traffic engineering, 
and multiclass LSPs. You can configure multiple policers for each multiclass LSP. For regular LSPs, each 
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LSP policer is applied to all of the traffic traversing the LSP. The policer's bandwidth limitations become 
effective as soon as the total sum of traffic traversing the LSP exceeds the configured limit. 


NOTE: The PTX10003 router only supports regular LSPs. 


You configure the multiclass LSP and DiffServ-aware traffic engineering LSP policers in a filter. The filter 
can be configured to distinguish between the different class types and apply the relevant policer to each 
class type. The policers distinguish between class types based on the EXP bits. 


You configure LSP policers under the family any filter. The family any filter is used because the policer is 
applied to traffic entering the LSP. This traffic might be from different families: IPv6, MPLS, and so on. 
You do not need to know what sort of traffic is entering the LSP, as long as the match conditions apply to 
all types of traffic. 


You can configure only those match conditions that apply across all types of traffic. The following are the 
supported match conditions for LSP policers: 


e forwarding-class 
e packet-length 
e interface 


e interface-set 


To enable a policer on an LSP, first you need to configure a policing filter and then include it in the LSP 
configuration. For information about how to configure policers, see the Routing Policies, Firewall Filters, and 
Traffic Policers User Guide. 


To configure a policer for an LSP, specify a filter by including the filter option to the policing statement: 


policing { 
filter filter-name; 


You can include the policing statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 
e [edit protocols mpls static-label-switched-path Isp-name] 
e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name] 


LSP Policer Limitations 


When configuring MPLS LSP policers, be aware of the following limitations: 
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e LSP policers are supported for packet LSPs only. 

e LSP policers are supported for unicast next hops only. Multicast next hops are not supported. 
e LSP policers are not supported on aggregated interfaces. 

e The LSP policer runs before any output filters. 


e Traffic sourced from the Routing Engine (for example, ping traffic) does not take the same forwarding 
path as transit traffic. This type of traffic cannot be policed. 


e LSP policers work on all T Series routers and on M Series routers that have the Internet Processor II 
application-specific integrated circuit (ASIC). 


NOTE: Starting with Junos OS Release 12.2R2, on T Series routers only, you can configure an 
LSP policer for a specific LSP to be shared across different protocol family types. To do so, you 
must configure the logical-interface-policer statement at the [edit firewall policer policer-name] 
hierarchy level. 


Example: Configuring an LSP Policer 


The following example shows how you can configure a policing filter for an LSP: 


[edit firewall] 
policer police-ct1 { 
if-exceeding { 
bandwidth-limit 50m; 
burst-size-limit 1500; 
} 
then { 
discard; 


} 
policer police-ctO { 
if-exceeding { 
bandwidth-limit 200m; 
burst-size-limit 1500; 
} 
then { 
discard; 


} 
family any { 
filter bar { 
term discard-ctO { 


then { 
policer police-ctO; 
accept; 


} 
term discard-ct1 { 
then { 
policer police-ct1; 
accept; 


Configuring Automatic Policers 
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Automatic policing of LSPs allows you to provide strict service guarantees for network traffic. Such 
guarantees are especially useful in the context of Differentiated Services for traffic engineered LSPs, 
providing better emulation for ATM wires over an MPLS network. For more information about Differentiated 
Services for LSPs, see “DiffServ-Aware Traffic Engineering Introduction” on page 1118. 


Differentiated Services for traffic engineered LSPs allow you to provide differential treatment to MPLS 
traffic based on the EXP bits. To ensure these traffic guarantees, it is insufficient to simply mark the traffic 
appropriately. If traffic follows a congested path, the requirements might not be met. 


LSPs are guaranteed to be established along paths where enough resources are available to meet the 
requirements. However, even if the LSPs are established along such paths and are marked properly, these 
requirements cannot be guaranteed unless you ensure that no more traffic is sent to an LSP than there is 
bandwidth available. 


It is possible to police LSP traffic by manually configuring an appropriate filter and applying it to the LSP 
in the configuration. However, for large deployments it is cumbersome to configure thousands of different 
filters. Configuration groups cannot solve this problem either, since different LSPs might have different 
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bandwidth requirements, requiring different filters. To police traffic for numerous LSPs, it is best to configure 
automatic policers. 


When you configure automatic policers for LSPs, a policer is applied to all of the LSPs configured on the 
router. However, you can disable automatic policing on specific LSPs. 


NOTE: When you configure automatic policers for DiffServ-aware traffic engineering LSP, GRES 
is not supported. 


NOTE: You cannot configure automatic policing for LSPs carrying CCC traffic. 


The following sections describe how to configure automatic policers for LSPs: 


Configuring Automatic Policers for LSPs 


To configure automatic policers for standard LSPs (neither DiffServ-aware traffic engineered LSPs nor 
multiclass LSPs), include the auto-policing statement with either the class all policer-action option or the 
class ctO policer-action option: 


auto-policing { 
class all policer-action; 
class ctO policer-action; 


You can include this statement at the following hierarchy levels: 

e [edit protocols mpls] 

e [edit logical-systems logical-system-name protocols mpls] 

You can configure the following policer actions for automatic policers: 
e drop—Drop all packets. 

e loss-priority-high—Set the packet loss priority (PLP) to high. 

e loss-priority-low—Set the PLP to low. 


These policer actions are applicable to all types of LSPs. The default policer action is to do nothing. 


Automatic policers for LSPs police traffic based on the amount of bandwidth configured for the LSPs. You 
configure the bandwidth for an LSP using the bandwidth statement at the [edit protocols mpls 
label-switched-path Isp-path-name] hierarchy level. If you have enabled automatic policers on a router, 
change the bandwidth configured for an LSP, and commit the revised configuration, the change does not 


154 


take affect on the active LSPs. To force the LSPs to use the new bandwidth allocation, issue a clear mpls 
Isp command. 


NOTE: You cannot configure automatic policers for LSPs that traverse aggregated interfaces or 
Multilink Point-to-Point Protocol (MLPPP) interfaces. 


Configuring Automatic Policers for DiffServ-Aware Traffic Engineering LSPs 


To configure automatic policers for DiffServ-aware traffic engineering LSPs and for multiclass LSPs, include 
the auto-policing statement: 


auto-policing { 
class all policer-action; 
class ctnumber policer-action; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


You include either the class all policer-action statement or a class ctnumber policer-action statement for 
each of one or more classes (you can configure a different policer action for each class). For a list of the 
actions that you can substitute for the policer-action variable, see “Configuring Automatic Policers for 
LSPs” on page 153. The default policer action is to do nothing. 


NOTE: You cannot configure automatic policers for LSPs that traverse aggregated interfaces or 
MLPPP interfaces. 


Configuring Automatic Policers for Point-to-Multipoint LSPs 


You can configure automatic policers for point-to-multipoint LSPs by including the auto-policing statement 
with either the class all policer-action option or the class ctO policer-action option. You only need to 
configure the auto-policing statement on the primary point-to-multipoint LSP (for more information on 
primary point-to-multipoint LSPs, see “Configuring the Primary Point-to-Multipoint LSP” on page 687). No 
additional configuration is required on the subLSPs for the point-to-multipoint LSP. Point-to-multipoint 
automatic policing is applied to all branches of the point-to-multipoint LSP. In addition, automatic policing 
is applied to any local VRF interfaces that have the same forwarding entry as a point-to-multipoint branch. 
Feature parity for automatic policers for MPLS point-to-multipoint LSPs on the Junos Trio chipset is 
supported in Junos OS Releases 11.1R2, 11.2R2, and 11.4. 
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The automatic policer configuration for point-to-multipoint LSPs is identical to the automatic policer 
configuration for standard LSPs. For more information, see “Configuring Automatic Policers for LSPs” on 
page 153. 


Disabling Automatic Policing on an LSP 


When you enable automatic policing, all of the LSPs on the router or logical system are affected. To disable 
automatic policing on a specific LSP on a router where you have enabled automatic policing, include the 
policing statement with the no-auto-policing option: 


policing no-auto-policing; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


Example: Configuring Automatic Policing for an LSP 


Configure automatic policing for a multiclass LSP, specifying different actions for class types ctO, ct1, ct2, 
and ct3. 


[edit protocols mpls] 
diffserv-te { 
bandwidth-model extended-mam; 
} 
auto-policing { 
class ct1 loss-priority-low; 
class ctO loss-priority-high; 
class ct2 drop; 
class ct3 loss-priority-low; 
} 
traffic-engineering bgp-igp; 
label-switched-path sample-lIsp { 
to 3.3.3.3; 
bandwidth { 
ctO 11; 
cule 
ct2 1; 
ct3 1; 


} 
interface fxp0.0 { 


disable; 
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interface t1-0/5/3.0; 
interface t1-0/5/4.0; 


Writing Different DSCP and EXP Values in MPLS-Tagged IP Packets 


You can selectively set the DiffServ code point (DSCP) field of MPLS-tagged IPv4 and IPvé6 packets to O 
without affecting output queue assignment, and continue to set the MPLS EXP field according to the 
configured rewrite table, which is based on forwarding classes. You can accomplish this by configuring a 
firewall filter for the MPLS-tagged packets. 


Overview of MPLS Firewall Filters on Loopback Interface 


Although all interfaces are important, the loopback interface might be the most important because it is 
the link to the Routing Engine, which runs and manages all the routing protocols. The loopback interface 
is a gateway for all the control traffic that enters the Routing Engine of the switch. You can control this 
traffic by configuring a firewall filter on the loopback interface (loO) on family mpls. Loopback firewall 
filters affect only traffic destined for the Routing Engine CPU. You can apply a loopback firewall filter only 
in the ingress direction (packets entering the interface). Starting with Junos OS Release 19.2R1, you can 
apply an MPLS firewall filter to a loopback interface ona label switch router (LSR) on QFX5100, QFX5110, 
QFX5200, and QFX5210 switches. 


When you configure an MPLS firewall filter, you define filtering criteria (terms, with match conditions) for 
the packets and an action for the switch to take if the packets match the filtering criteria. Because you 
apply the filter to a loopback interface, you must explicitly specify the time to live (TTL) match condition 
under family mpls and set its TTL value to 1 (ttl=1). The TTL is an 8-bit (IPv4) header field that signifies 
the remaining time an IP packet has left before its life ends and is dropped. You can also match packets 
with other MPLS qualifiers such as label, exp, Layer 4 source port, and Layer 4 destination port. For more 
information, see Firewall Filter Match Conditions for MPLS Traffic. 


Benefits of Adding MPLS Firewall Filters on the Loopback Interface 

e Protects the Routing Engine by ensuring that it accepts traffic only from trusted networks. 

e Helps protect the Routing Engine from denial-of-service attacks. 

e Gives you the flexibility to match packets on the source port and destination port. For example, if you 


run a traceroute, you can selectively filter traffic by choosing either TCP or UDP. 


Guidelines and Limitations 


e You can apply a loopback firewall filter only in the ingress direction 
e Only MPLS fields label, exp, ttl=1 and Layer 4 fields tcp and udp port numbers are supported. 
e Only accept, discard, and count actions are supported. 


e You must explicitly specify ttl=1 under family mpls to match on TLL packets. 
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e Filters applied on the loopback interface cannot be matched on the destination port (inner payload) of 
an IPv6 packet. 


e You cannot apply a filter on packets that have more than two MPLS labels. 
e You cannot specify a port range for TCP or UDP match conditions. 


e Only 255 firewall terms are supported. 


Configuring MPLS Firewall Filters and Policers on Switches 


IN THIS SECTION 


Configuring an MPLS Firewall Filter | 157 
Applying an MPLS Firewall Filter to an MPLS Interface | 158 
Applying an MPLS Firewall Filter to a Loopback Interface | 158 


Configuring Policers for LSPs | 159 


You can configure firewall filters to filter MPLS traffic. To use an MPLS firewall filter, you must first 
configure the filter and then apply it to an interface you have configured for forwarding MPLS traffic. You 
can also configure a policer for the MPLS filter to police (that is, rate-limit) the traffic on the interface to 
which the filter is attached. 


When you configure an MPLS firewall filter, you define the filtering criteria (terms, with match conditions) 
and an action for the switch to take if the packets match the filtering criteria. 


NOTE: You can only configure MPLS filters in the ingress direction. Egress MPLS firewall filters 
are not supported. 


Configuring an MPLS Firewall Filter 
To configure an MPLS firewall filter: 
1. Configure the filter name, term name, and at least one match condition—for example, match on MPLS 


packets with EXP bits set to either O or 4: 


[edit firewall family mpls] 
user@switch# set filter ingress-exp-filter term term-one from exp 0,4 
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2. In each firewall filter term, specify the actions to take if the packet matches all the conditions in that 
term—for example, count MPLS packets with EXP bits set to either O or 4: 


[edit firewall family mpls filter ingress-exp-filter term term-one then] 
user@switch# set count counterO 
user@switch# set accept 


3. When you are finished, follow the steps below to apply the filter to an interface. 


Applying an MPLS Firewall Filter to an MPLS Interface 


To apply the MPLS firewall filter to an interface you have configured for forwarding MPLS traffic (using 
the family mpls statement at the [edit interfaces interface-name unit unit-number] hierarchy level): 


NOTE: You can apply firewall filters only to filter MPLS packets that enter an interface. 


1. Apply the firewall filter to an MPLS interface—for example, apply the firewall filter to interface xe-0/0/5: 


[edit interfaces] 
user@switch# set xe-0/0/5 unit O family mpls filter input ingress-exp-filter 


2. Review your configuration and issue the commit command: 


[edit interfaces] 
user@switch# commit 
commit complete 


Applying an MPLS Firewall Filter to a Loopback Interface 
To apply an MPLS firewall filter to a loopback interface (loO): 


1. First, specify the packet format by using the packet-format-match command. You must restart the PFE 
every time you configure this command. 


2. Configure the firewall filter match conditions and actions as described in “Configuring an MPLS Firewall 
Filter” on page 157. You must explicitly set the TTL match condition to (ttl=1). You can also match 
packets with other MPLS qualifiers such as label, exp, and Layer 4 source port, and destination port. 


3. Apply the filter to the loopback interface as an input filter. 


[edit interfaces] 
user@switch# set loO unit O family mpls filter input ingress-exp-filter 


4. Review your configuration and issue the commit command: 


[edit interfaces] 
user@switch# commit 
commit complete 


The following is an example configuration. 


set groups lo_mpls_filter interfaces loO unit O family mpls filter input mpls_lo 

set groups lo_mpls_filter firewall family mpls filter mpls_lo term mpls_lo_term from ttl 1 

set groups lo_mpls_filter firewall family mpls filter mpls_lo term mpls_lo_term from ip-version ipv4 protocol 
udp source-port 10 

set groups lo_mpls_filter firewall family mpls filter mpls_lo term mpls_lo_term from ip-version ipv4 protocol 
udp destination-port 11 

set groups lo_mpls_filter firewall family mpls filter mpls_lo term mpls_lo_term then count c1 

set groups lo_mpls_filter firewall family mpls filter mpls_lo term mpls_lo_term then accept 


Configuring Policers for LSPs 


Starting with Junos OS 13.2X51-D15, you can send traffic matched by an MPLS filter to a two-color policer 
or three-color policer. MPLS LSP policing allows you to control the amount of traffic forwarded through 
a particular LSP. Policing helps to ensure that the amount of traffic forwarded through an LSP never 
exceeds the requested bandwidth allocation. LSP policing is supported on regular LSPs, LSPs configured 
with DiffServ-aware traffic engineering, and multiclass LSPs. You can configure multiple policers for each 
multiclass LSP. For regular LSPs, each LSP policer is applied to all of the traffic traversing the LSP. The 
policer's bandwidth limitations become effective as soon as the total sum of traffic traversing the LSP 
exceeds the configured limit. 


You configure the multiclass LSP and DiffServ-aware traffic engineering LSP policers in a filter. The filter 
can be configured to distinguish between the different class types and apply the relevant policer to each 
class type. The policers distinguish between class types based on the EXP bits. 


You configure LSP policers under the family any filter. The family any filter is used because the policer is 
applied to traffic entering the LSP. This traffic might be from different families: IPv6, MPLS, and so on. 
You do not need to know what sort of traffic is entering the LSP, as long as the match conditions apply to 
all types of traffic. 


When configuring MPLS LSP policers, be aware of the following limitations: 
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e LSP policers are supported for packet LSPs only. 
e LSP policers are supported for unicast next hops only. Multicast next hops are not supported. 
e The LSP policer runs before any output filters. 


e Traffic sourced from the Routing Engine (for example, ping traffic) does not take the same forwarding 
path as transit traffic. This type of traffic cannot be policed. 


Release History Table 


Release Description 

19.2R1 Starting with Junos OS Release 19.2R1, you can apply an MPLS firewall filter to a loopback 
interface on a label switch router (LSR) on QFX5100, QFX5110, QFX5200, and QFX5210 
switches. 


| System Log Messages and SNMP Traps for MPLS 


Whenever an LSP makes a transition from up to down, or down to up, and whenever an LSP switches 
from one active path to another, the ingress router generates a system log message and sends an SNMP 
trap. The following shows a sample system log message: 


RUE ID) IMIPILS,_ILSj2_ (023 IMIPINS} InSI sSleveeyoil wis im joresaBuey (Eu) Reouire 192 168,11 192. 16s. i .2 
192 168.1 53 
RPD_MPLS_LSP_CHANGE: MPLS LSP sheepl change on primary(any) Route 192.168.1.1 
192,168 1,2 192.168.5153 

RPD_MPLS_LSP_DOWN: MPLS LSP sheepl down on primary (any) 




















For information about the MPLS SNMP traps and the proprietary MPLS MIBs, see the Network Management 
and Monitoring Guide. 


System log messages for LSPs are generated by default. To disable the default logging of messages for 
LSPs, configure the no-syslog option under the log-updown statement: 


log-updown { 
no-syslog; 


To generate SNMP traps for LSPs, include the trap option to the log-updown statement: 
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log-updown { 
trap; 


To generate SNMP traps whenever an LSP path goes down, include the trap-path-down option to the 
log-updown statement: 


log-updown { 
trap-path-down; 


To generate SNMP traps whenever an LSP path comes up, include the trap-path-up option to the 
log-updown statement: 


log-updown { 
trap-path-up; 


To disable the generation of system log messages, include the no-syslog option to the log-updown 
statement: 


log-updown { 
no-syslog; 


To disable the generation of SNMP traps, include the no-trap statement: 


no-trap { 
mpls-Isp-traps; 
rfc3812-traps; 


You can include this statement at the following hierarchy levels: 
e [edit protocols mpls log-updown] 
e [edit logical-systems logical-system-name protocols mpls log-updown] 


For scalability reasons, only the ingress router generates SNMP traps. By default, MPLS issues traps for 
all configured LSPs. If you have many LSPs, the number of traps can become quite large. To disable the 
generation of SNMP traps, configure the no-trap statement. 
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The no-trap statement also includes the following options which allow you to block certain categories of 
MPLS SNMP traps: 


e mpls-Isp-traps—Blocks the MPLS LSP traps defined in the jnx-mpls.mib, but allows the rfc3812.mib 
traps. 


e rfc-3812-traps—Blocks the traps defined in the rfc3812.mib, but allows the MPLS LSP traps defined in 
the jnx-mpls.mib. 


| Load Balancing MPLS Traffic 


IN THIS SECTION 


Configuring Load Balancing Based on MPLS Labels | 162 

Example: Load-Balanced MPLS Network | 167 

Router Configurations for the Load-Balanced MPLS Network | 168 

Configuring Load Balancing Based on MPLS Labels on ACX Series Routers | 183 
MPLS Encapsulated Payload Load-balancing Overview | 187 

Configuring MPLS Encapsulated Payload for Load Balancing | 188 

Policy-Based Multipath Routes Overview | 188 


Understanding IP-Based Filtering and Selective Port Mirroring of MPLS Traffic | 194 


Configuring Load Balancing Based on MPLS Labels 


Load balancing occurs on a per-packet basis for MPLS flows on supported platforms. Entropy, or random 
distribution, is essential for the uniform distribution of packets to their next hops. By default, when load 

balancing is used to help distribute traffic, Junos OS employs a hash algorithm to select a next-hop address 
to install into the forwarding table. Whenever the set of next hops for a destination changes, the next-hop 
address is reselected by means of the hash algorithm. You can configure how the hash algorithm is used 

to load-balance traffic across a set of equal-cost label switched paths (LSPs). 


To ensure entropy for VPLS & VPWS traffic, Junos OS can create a hash based on data from the IP header 
and as many as three MPLS labels (the so-called top labels). 


In some cases, as the number of network feature that use labels grows (such as MPLS Fast Reroute, and 
RFC 3107, RSVP and VPN) data in the top three labels can become static and thus not a sufficient source 
for entropy. Load balancing can become skewed as a result, or the incidence of out-of-order packet delivery 
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may rise. For these cases, labels from the bottom of the label stack can be used (see Table 1, below for 
qualifications). Top labels and bottom labels cannot be used at the same time. 


NOTE: MPC cards do not support the regular hash key configuration. For the MPC-based hash 
key configuration to be effective, you need an enhanced-hash-key configuration. 


Load balancing is used to evenly distribute traffic when the following conditions apply: 


e There are multiple equal-cost next hops over different interfaces to the same destination. 


e There is a single next hop over an aggregated interface. 


An LSP tends to load-balance its placement by randomly selecting one of the equal-cost next hops and 
using it exclusively. The random selection is made independently at each transit router, which compares 
Interior Gateway Protocol (IGP) metrics alone. No consideration is given to bandwidth or congestion levels. 


This feature applies to aggregated Ethernet and aggregated SONET/SDH interfaces as well as multiple 
equal-cost MPLS next hops. In addition, on the T Series, MX Series, M120, and M320 routers only, you 
can configure load balancing for IPv4 traffic over Layer 2 Ethernet pseudowires. You can also configure 
load balancing for Ethernet pseudowires based on IP information. The option to include IP information in 
the hash key provides support for Ethernet circuit cross-connect (CCC) connections. 


To load-balance based on the MPLS label information, configure the family mpls statement: 


[edit forwarding-options hash-key] 
family mpls { 
all-labels; 
bottom-label-1; 
bottom-label-2; 
bottom-label-3; 
label-1; 
label-2; 
label-3; 
no-labels; 
no-label-1-exp; 
payload { 
ether-pseudowire; 
ip { 
disable; 
layer-3-only; 
port-data { 
destination-Isb; 
destination-msb; 
source-Isb; 


source-msb; 
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You can include this statement at the following hierarchy levels: 


e [edit forwarding-options hash-key] 


Table 9 on page 164 provides detailed information about all of the possible MPLS LSP load-balancing 


options. 


Table 9: MPLS LSP Load Balancing Options 


Statement 


all-labels 


bottom-abet2 


bottom-abe3 


label-l 


label-2 


Supported 
Platforms 


MxX Series and 
PTX Series 


MX Series with 
DPC (I-Chip). Not 
supported on M10i, 
M7i, and M120. 


MX Series with 
DPC (I-Chip). Not 
supported on M10i, 
M7i, and M120. 


MX Series with 
DPC (I-Chip). Not 
supported on M10i, 
M7i, and M120. 


M Series, 
MX Series, T Series 


M Series, 
MX Series, T Series 


MPLS LSP Load Balancing Options 


Prior to Junos OS Release 19.1R1, up to eight MPLS labels were included in the 
hash key to identify the uniqueness of a flow in the Packet Forwarding Engine. 
On PTX Series routers, this value is set by default. 


Starting in Junos OS Release 19.1R1, for MX Series routers with MPC and MIC 
interfaces, up to sixteen incoming MPLS labels are included in the hash key. 


Uses the bottom-most label for calculating the hash key, for example if the top 
labels do not provide sufficient variable for the required level of entropy. 


Uses the second label from the bottom for calculating the hash key, for example 
if the top labels do not provide sufficient variable for the required level of entropy. 


Uses the third label from the bottom for calculating the hash key, for example if 
the top labels do not provide sufficient variable for the required level of entropy. 


Include the first label in the hash key. Use this option for single label packets. 


Include the second label in the hash key. You must also configure the label-1 
option. The entire first label and the first 16 bits of the second label are used in 
the hash key. 


Table 9: MPLS LSP Load Balancing Options (continued) 


Statement 


label-3 


no-labels 


nobbe-Lep 


payload 


disable 


dhapschnie 


layer-3-only 


port-data 


Supported 
Platforms 


M Series, 
MX Series, T Series 


All 


M Series, 
MX Series, T Series 


All 


PTX Series 


M120, M320, 
MX Series, T Series 


All 


All 


M Series, 
MX Series, T Series 


M Series, 
MX Series, T Series 


M Series, 
MX Series, T Series 


MPLS LSP Load Balancing Options 


Include the third label in the hash key. You must also configure the label-1 option 
and the label-2 option. 


Excludes MPLS labels from the hash key. 


Excludes the EXP bit of the top label from the hash key. You must also configure 
the label-I option. 


For Layer 2 VPNs, the router could encounter a packet reordering problem. When 
a burst of traffic pushes the customer traffic bandwidth to exceed its limits, the 
traffic might be affected in mid flow. Packets might be reordered as a result. By 
excluding the EXP bit from the hash key, you can avoid this reordering problem. 


Allows you to configure which parts of the IP packet payload to include in the 
hash key. For the PTX Series Packet Transport Router, this value is set by default. 


Exclude IP payload from the hash key. 


Load-balance |Pv4 traffic over Layer 2 Ethernet pseudowires. 


Include the IPv4 or IPv6 address in the hash key. You must also configure either 
label-I or no-labels. 


Include only the Layer 3 IP information in the hash key. Excludes all of the port-data 
bytes from the hash key. 


Include the source and destination port field information. By default, the most 
significant byte and least significant byte of the source and destination port fields 
are used in the hash key. To select specific bytes to use in the hash key, include 
one or more of the source-msb, source-Isb, destination-msb, and destination-Isb 
options at the [edit forwarding-options hash-key family mpls payload ip port-data] 
hierarchy level. To prevent all four bytes from being hashed, include the 
layer-3-only statement at the [edit forwarding-options hash-key family mpls 
payload ip] hierarchy level. 


Include the least significant byte of the destination port in the hash key. Can be 
combined with any of the other port-data options. 


Include the most significant byte of the destination port in the hash key. Can be 
combined with any of the other port-data options. 
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Table 9: MPLS LSP Load Balancing Options (continued) 


Supported 
Statement Platforms MPLS LSP Load Balancing Options 
source-Isb_ M Series, Include the least significant byte of the source port in the hash key. Can be 


MX Series, T Series | combined with any of the other port-data options. 


source-msb_ WM Series, Include the most significant byte of the source port in the hash key. Can be 
MX Series, T Series | combined with any of the other port-data options. 


The following examples illustrate ways in which you can configure MPLS LSP load balancing: 


e To include the IP address as well as the first label in the hash key: 


e For M Series, MX Series, and T Series routers, configure the label-1 statement and the ip option for 
the payload statement at the [edit forwarding-options hash-key family mpls] hierarchy level: 


[edit forwarding-options hash-key family mpls] 
label-1; 
payload { 
ip; 
} 


e For PTX Series Packet Transport Routers, the all-labels and ip payload options are configured by 
default, so no configuration is necessary. 


e (M320 and T Series routers only) To include the IP address as well as both the first and second labels in 
the hash key, configure the label-1 and label-2 options and the ip option for the payload statement at 
the [edit forwarding-options hash-key family mpls] hierarchy level: 


[edit forwarding-options hash-key family mpls] 
label-1; 
label-2; 
payload { 
ip; 
} 


NOTE: You can include this combination of statements on M320 and T Series routers only. If 
you include them on an M Series Multiservice Edge Router, only the first MPLS label and the 
IP payload are used in the hash key. 


167 


e For T Series routers, ensure proper load balancing by including the label-1, label-2, and label-3 options 
at the [edit forwarding-options hash-key family mpls] hierarchy level: 


[edit forwarding-options hash-key family mpls] 
label-1; 
label-2; 
label-3; 


e (M Series, MX Series, and T Series routers only) For Layer 2 VPNs, the router could encounter a packet 
reordering problem. When a burst of traffic pushes the customer traffic bandwidth to exceed its limits, 
the traffic might be affected in mid flow. Packets might be reordered as a result. By excluding the EXP 
bit from the hash key, you can avoid this reordering problem. To exclude the EXP bit of the first label 
from the hash calculations, include the no-label-1-exp statement at the [edit forwarding-options hash-key 
family mpls] hierarchy level: 


[edit forwarding-options hash-key family mpls] 
label-1; 
no-label-1-exp; 
payload { 
ip; 
} 


Example: Load-Balanced MPLS Network 


When you configure several RSVP LSPs to the same egress router, the LSP with the lowest metric is 
selected and carries all traffic. If all of the LSPs have the same metric, one of the LSPs is selected at random 
and all traffic is forwarded over it. To distribute traffic equally across all LSPs, you can configure load 
balancing on the ingress or transit routers, depending on the type of load balancing configured. 


Figure 10 on page 168 illustrates an MPLS network with four LSPs configured to the same egress router 
(RO). Load balancing is configured on ingress router R1. The example network uses Open Shortest Path 
First (OSPF) as the interior gateway protocol (IGP) with OSPF area 0.0.0.0. An IGP is required for the 
Constrained Shortest Path First (CSPF) LSP, which is the default for the Junos OS. In addition, the example 
network uses a policy to create BGP traffic. 
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Figure 10: Load-Balancing Network Topology 
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The network shown in Figure 10 on page 168 consists of the following components: 

e A full-mesh interior BGP (IBGP) topology, using AS 65432 

e MPLS and RSVP enabled on all routers 

e Asend-statics policy on routers R1 and RO that allows a new route to be advertised into the network 


e Four unidirectional LSPs between R11 and RO, and one reverse direction LSP between RO and R1, which 
allows for bidirectional traffic 


e Load balancing configured on ingress router R1 


The network shown in Figure 10 on page 168 is a BGP full-mesh network. Since route reflectors and 
confederations are not used to propagate BGP learned routes, each router must have a BGP session with 
every other router running BGP. 


Router Configurations for the Load-Balanced MPLS Network 


Purpose 


The configurations in this topic are for the six load-balanced routers in the example network illustrated in 
“Load-Balancing Network Topology” on page 167. 


Action 


To display the configuration of a router, use the following Junos OS CLI operational mode command: 


user@host> show configuration | no-more 


Sample Output 1 


The following configuration output is for edge router R6. 


user@R6> show configuration | no-more 
[Ole pUEMEEUne@ated ss] 
interfaces { 
fe-0/1/2 { 
vinaic OW 4 
family inet { 
ackcleess 100,16, 14/ 30s 
} 
family mpls; #MPLS enabled on relevant interfaces 





} 
re-L/ S/o { 
unit O { 
family inet { 
addinestsn Oss OmslbAre ly. 2Ar. 


} 
fxpod { 
unit O { 
family inet { 
address 192.168.70.148/21; 


} 
Leo) {| 
wimaie © ff 
family inet { 
ackiness 192. 168.6. 1/329 


} 
routing-options { 
Statue 
Loc pOUlEOUIE ete AZceCl. oa] 
router-id 192.168.6.1; #Manually configured RID 
autonomous-system 65432; #Full mesh IBGP 
} 
} 
WuROEOCOUS 
ESwo {| 
interface fe-0/1/2.0; 
interface fxp0.0 { 
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disable; 


} 
mpls { 
interface fe-0/1/2.0; 
interface fxp0.0 { 
disable; 


} 
bgp { 
group internal { 
type internal; 
local-address 192.168.6.1; 


Mmeleinoo~ 192, 68.1, ibe 
meacingor i192), L682. ibe 
neighbor 192.168.4.1; 
mEeieinoor i192). 68,8). ip 
neighbor 192.168.0.1; 


} 
ospf { #IGP enabled 
traffic-engineering; 
area 0.0.0.0 { 
interface fe-0/1/2.0; 
interface fe-1/3/0.0; 


interface 100.0 { 





passive; #Ensures protocols do not run over this interface 


Sample Output 2 


The following configuration output is for ingress router R1. 


user@R1> show configuration | no-more 
lsc cOUlicjoule. eho sicSCl. 5 « || 
interfaces { 
fe-0/1/0 { 
winaie O ff 


family inet { 
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acdizess 10,0 ,12,13/ 305 


} 
family mpls; #MPLS enabled on relevant interfaces 





} 
fe-0/1/2 { 
Winasic OW 4 
family inet { 
address 10.0 ,16. 13/309 
} 
family mpls; 


} 
fxpO { 
wimaie 0 ff 
family inet { 
address 192.168.70.143/21; 


} 
Leo 4 
wimsie 0 ff 
family inet { 
acelease 197,168, 1,1 / 325 


} 
routing-options { 
Static { 
lsc pOQUEOUE icici ACeCl, oc] 
route 100.100.1.0/24 reject; #Static route for send-statics policy 


router-id 192.168.1.1; #Manually configured RID 
autonomous-system 65432; #Full mesh IBGP 
forwarding-table { 


export Ibpp; #Routes exported to forwarding table 


} 
DBOwOCoSma 
rsvp { 
interface fe-0/1/0.0; 
interface fe-0/1/2.0; 
interface fxp0.0 { 


disable; 


} 
mpls { 
label-switched-path Isp 1 { #First LSP 
to 192.168.0.1; # Destination of the LSP 
install 10.0.90.14/32 active; # The prefix is installed in the 


primary via-r4; # inet.0 routing table 
} 
label-switched-path Isp2 { 
Eq 192.1680, 
imecali 10.090, 1a/32 aceiweg 
primany vVia—v2, 
} 
label-switched-path Isp3 { 
tO 192. 168.017 
Hoaeicelli 1.0.90, 1a/32 acca 
primary via-r2; 
} 
label-switched-path Isp4 { 
tO 192.168.0117 
is ecllel OPO One ayePmac tine) 
primary via-r4; 
} 
path via-r2 { #Primary path to spread traffic across interfaces 
IN -O.29,2 loose 
} 
path via-r4 { 
10.0.24.2 loose; 
} 
interface fe-0/1/0.0; 
LiMESESCS 12S-0/il/2.0p 
interface fxp0.0 { 
disable; 


} 
bgp { 
export send-statics; #Allows advertising of a new route 
group internal { 
type internal; 
local address ho 2ewlG Cream: 
neighbor 192.168.2.1; 
neighbor 192.168.4.1; 
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MaLteinioew i192) . iss}. ©). ibe 
inSaelaloore IL), ISI}... ihe 
neighbor 192.168.0.1; 


} 
ospf { #IGP enabled 
traffic-—engineering; 
area O207,0.0 f 
interface fe-0/1/0. 
interface fe-0/1/2. 


=a SS) 
Ne oNe 


interface 100.0 { 





passive; #Ensures protocols do not run over this interface 


} 
policy-options{ #Load balancing policy 
policy-statement Ibpp { 
then { 


load-balance per-packet; 


} 
policy-statement send-statics{ #Static route policy 
term statics { 
from { 
route-filter 100.100.1.0/24 exact; 
} 


then accept; 


Sample Output 3 


The following configuration output is for transit router R2. 


user@R2> show configuration | no-more 
lsc sOUliEUE. cee AICeCl. «| 
interfaces { 
so-0/0/1 { 
unit O { 


family inet { 
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acEre ss lOmOm 24. ll/si0r 
} 
family mpls; #MPLS enabled on relevant interfaces 





} 
so-0/0/2 { 
unit O { 
family inet { 
Acllise sisi Or One Omele/asiOre 
} 
family mpls; 


} 
fe-0/1/0 { 
wimaie 0 ff 
family inet { 
acelieess 100.12, 14/305 
} 
family mpls; 


} 
fxpoO { 
winaic © 4 
family inet { 
address 192.168.70.144/21; 


} 
HO Omet 
wince © 4 
family inet { 
addmesis el OA eligi / 32). 


} 
routing-options { 
Siteciteslec mat 
[so oOUlEowNE KieWACGZEScl. . .] 
router-id 192.168.2.1; #Manually configured RID 
autonomous-system 65432; #Full mesh IBGP 
} 
} 


DBOwOCo Sm 
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rsvp { 
interface so-0/0/1.0; 
interface fe-0/1/0.0; 
interface so-0/0/2.0; 
interface fxp0.0 { 
disable; 


} 
mpls { 
interface fe-0/1/0.0; 
interface so-0/0/1.0; 
interface so-0/0/2.0; 
interface fxp0.0 { 
disable; 


} 
bgp { 
group internal { 
type internal; 
iloeall—aciclsess 192. 16S, 2. ip 


Mmeleinooe 192, 1681, ibe 
NelGhworwes NOOR MGC. dels, 
medeinloee i122) . Ios}, ©). ibs 
meLeinooe i192). OS .6. ip 
mMmeielnloee i122! . iS}. (0). 1s 


} 
ospf { #IGP enabled 
traffic-—engineering; 
area 0.0.0.0 { 
interface fe-0/1/0.0; 
interface so-0/0/1.0; 
interface so-0/0/2.0; 


interface 100.0 { 





passive; #Ensures protocols do not run over this interface 


Sample Output 4 


The following configuration output is for transit router R4. 


user@R4> show configuration | no-more 
[Ole PUL ME EUnecated=:.| 
interfaces { 
so-0/0/1 { 
unit O { 
family inet { 
address 1070.24 .2/30; 
} 
family mpls; # MPLS enabled on relevant interfaces 





} 
so-0/0/3 { 
unit O { 
family inet { 
acGise sts lOm Orc Ony War 
} 
family mpls; 


} 
fxpod { 
Binnie O ff 
family inet { 
address 192.168.70.146/21; 


} 
1oO { 
binwic O ff 
family inet { 
aicelrass 192, 168), 41, 1/329 


} 
routing-options { 
Sie cielo mr 
Los pOUlEE. eietiocaicecl. ..] 
router-id 192.168.4.1; #Manually configured RID 
autonomous-system 65432; #Full mesh IBGP 
} 
PBOEOCOMmsm 
rsvp { 
interface so-0/0/1.0; 
interface so-0/0/3.0; 
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interface fxp0.0 { 
disable; 


} 
mpls { 
interface so-0/0/1.0; 
interface so-0/0/3.0; 
interface fxp0.0 { 
disable; 


} 
bgp { 
group internal { 
type internal; 
ilo@ell—aiciclisess 92. 1 6s4 . ip 


iMmeakeingore I19)2), IG}. . ibe 
mELgidoor 192. 168.2. ip 
maielalorere iL S)2 . IMSis}.. 2), ie 
meigidooec 192. 168.6. ip 
meaclnoor i192), L680. ie 


} 
ospf { #IGP enabled 
traffic-—engineering; 
area 0.0.0.0 { 
interface so-0/0/1.0; 
interface so-0/0/3.0; 


interface 100.0 { 





passive; #Ensures protocols do not run over this interface 


Sample Output 5 


The following configuration output is for transit router R9. 


user@R9> show configuration | no-more 
lsc SOUlEjowle eto sicScl. 5 «| 
interfaces { 

so-0/0/2 4 


ipo momo ment 
family inet { 
acGise scm lO Oreo Or 
} 
family mpls; #MPLS enabled on relevant interfaces 





} 
SO=-O/O/S 4 
binaic O { 
family inet { 
ackizess 10.,0,49),2/ 30s 
} 
family mpls; 


} 
fe-0/1/0 { 
tinaic OW 4 
family inet { 
FKo lo hal -1- 4-00 oO GY 0) OF 
} 
family mpls; 


} 
fxpodO { 
wiawic © 4 
family inet { 
address 192.168.69.206/21; 


} 
Loo) 4 
Bimaie 0 ff 
family inet { 
address 192.168.9.1/32; 


} 
routing-options { 
Sieciteslecume( 
[...Output truncated...] 
router-id 192.168.9.1; #Manually configured RID 


autonomous-system 65432; #Full mesh IBGP 
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DEOOCO Sm 
rsvp { 
interface so-0/0/2.0; 
interface so-0/0/3.0; 
interface fe-0/1/0.0; 
interface fxp0.0 { 
disable; 


} 
mpls { 
interface so-0/0/2.0; 
interface so-0/0/3.0; 
interface fe-0/1/0.0; 
interface fxp0.0 { 
disable; 


} 
bgp { 
group internal { 
type internal; 
llocall—acicligess 192 5 i168 8), ip 


meacinoor 192), 168.1. ibe 
meielinloee i192). IlSs}. 2. ibs 
fel wKe pol elon amu cares Mol ora Graal ar 
meielnloyere i122! . IMS}. (0) , 1s 
iMSakelnoore IZ), ISS}... ibe 


} 
ospf { #IGP enabled 
traffic-—engineering; 
area 0.0.0.0 { 
interface so-0/0/2.0; 
interface so-0/0/3.0; 
interface fe-0/1/0.0; 


interface 100.0 { 





passive; #Ensures protocols do not run over this interface 


Sample Output 6 


The following configuration output is for egress router RO. 


user@RO> show configuration | no-more 
[Ole DUE ME EUne@ated ts] 
interfaces { 
fe-0/1/0 { 
bbe momm Oneal 
family inet { 
address 10.0.90.14/30; 
} 
family mpls; #MPLS enabled on relevant interfaces 





} 
e=L/ S/O { 
unit O { 
family inet { 
adcrass 10.10.51, 1/246 


} 
fxpod { 
vinaic WO 4 
family inet { 
address 192.168.69.207/21; 


} 
Leo) 4 
bine O ff 
family inet { 
address 192.168.0.1/32; 


} 
routing-options { 
Siecliteelicunl 
los pOUlEoue TeietlincacEecl. ..] 
route 100.100.10.0/24 reject; #Static route for send-statics policy 
} 
router-id 192.168.0.1; #Manually configured RID 


autonomous-system 65432; #Full mesh IBGP 
} 
PBMOEOCOMmSm 
rsvp { 
interface fe-0/1/0.0; 
interface fe-1/3/0.0; 
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interface fxp0.0 { 
disable; 


} 
mpls { 
label-switched-path r0-ré { 
to 192.168.6.1; 
} 
interface fe-0/1/0.0; 
interface fe-1/3/0.0; 
interface fxp0.0 { 
disable; 


} 
bgp { 
group internal { 

type internal; 
llocal-address 192-1687 0- 1; 
export send-statics; #Allows advertising of a new route 
meiginoor 192, L689. ie 
MmeLeiooe 192, 68.6. ibe 
neighbor 192.168. 
neighbor 192.168. 
neighbor 192.168. 


, 


1 
edlg 
1 


fs RS [= 


’ 


} 
ospf { #IGP enabled 
traffic-engineering; 
area 0.0.0.0 { 
interface fe-0/1/0.0; 
interface fe-1/3/0.0; 
interface 100.0 { 


passive; #Ensures protocols do not run over this interface 





} 
policy-options { 
policy-statement send-statics { 
term statics { 
from { 


route-filter 100.100.10.0/24 exact; 
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then accept; 


Meaning 

Sample Outputs 1 through 6 show the base interfaces, routing options, protocols, and policy options 
configurations for all six routers in the example network illustrated in “Example: Load-Balanced MPLS 
Network” on page 167. 


All routers in the network have MPLS, RSVP, and BGP enabled. OSPF is configured as the IGP, and relevant 
interfaces have basic IP information and MPLS support. 


In addition, all routers have the router ID (RID) configured manually at the [edit routing-options] hierarchy 
level to avoid duplicate RID problems. The passive statement is included in the OSPF configuration to 
ensure that protocols are not run over the loopback (loO) interface and that the loopback (loO) interface 
is advertised correctly throughout the network. 


Sample Outputs 1, 3, 4, and 5 for R6, R2, R4, and RI show the base configuration for transit label-switched 
routers. The base configuration includes all interfaces enabled for MPLS, the RID manually configured, 
and the relevant protocols (RSVP, MPLS, BGP, and OSPF). 


Sample Output 2 from ingress router R1 shows the base configuration plus four LSPs (Isp1 through Isp4) 
configured to RO. The four LSPs are configured with different primary paths that specify a loose hop 
through R4 for Isp1 and Isp4, and through R2 for Isp2 and Isp3. 


To create traffic, R1 has a static route (100.100.1.0/24) configured at the [edit routing-options static 
route] hierarchy level. The prefix is included in the send-statics policy at the [edit policy-options send 
statics] hierarchy level so the routes can become BGP routes. 


In addition, on the ingress router R1, load balancing is configured using the per-packet option, and the 
policy is exported at the [edit routing-options forwarding-table] hierarchy level. 


Sample Output 6 from egress router RO shows one LSP (r0-r6) to R6 used to create bidirectional traffic. 
OSPF requires bidirectional LSP reachability before it will advertise the LSP into the IGP. Although the 
LSP is advertised into the IGP, no hello messages or routing updates occur over the LSP—only user traffic 
is sent over the LSP. The router uses its local copy of the IGP database to verify bidirectional reachability. 


In addition, RO has a static route (100.100.10.0/24) configured at the [edit routing-options static route] 
hierarchy level. The prefix is included in the send-statics policy at the [edit policy-options send statics] 
hierarchy level so the routes can become BGP routes. 


Configuring Load Balancing Based on MPLS Labels on ACX Series Routers 


ACX Series routers can load-balance on a per-packet basis in MPLS. Load balancing can be performed on 
information in both the IP header and on up to three MPLS labels, providing a more uniform distribution 
of MPLS traffic to next hops. This feature is enabled on supported platforms by default and requires no 
configuration. 


Load balancing is used to evenly distribute traffic when there is a single next hop over an aggregated 
interface or a LAG bundle. Load balancing using MPLS labels is supported only for LAG interfaces and not 
for equal-cost multipath (ECMP) links. 


By default, when load balancing is used to help distribute traffic, Junos OS employs a hash algorithm to 
select a next-hop address to install into the forwarding table. Whenever the set of next hops for a destination 
changes in any way, the next-hop address is reselected by means of the hash algorithm. You can configure 
how the hash algorithm is used to load-balance traffic across interfaces in an aggregated Ethernet (ae) 
interface. 


An LSP tends to load-balance its placement by randomly selecting one of the interfaces in an ae- interface 
bundle and using it exclusively. The random selection is made independently at each transit router, which 
compares Interior Gateway Protocol (IGP) metrics alone. No consideration is given to bandwidth or 
congestion levels. 


To load-balance based on the MPLS label information, configure the family mpls statement: 


[edit forwarding-options hash-key] 
family mpls { 
all-labels; 
label-1; 
label-2; 
label-3; 
no-labels; 
payload { 
ether-pseudowire; 
ip { 
layer-3-only; 
port-data { 
destination-I|sb; 
destination-msb; 
source-Isb; 
source-msb; 
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You can include this statement at the [edit forwarding-options hash-key] hierarchy level. 


NOTE: When you configure payload ip (user@host# set forwarding-options hash-key family 
mpls payload ip), configuring layer-3-only and port-data is mandatory. 


Load balancing functionality, without proper hash-keys configuration, may result in an 
unpredictable behavior. 


For Layer 2 VPN/pseudowire tunnel termination, upto two labels are used for hashing and payload MAC 
destination and source addresses can be optionally selected. These controls can be used to support 
ether-pseudowire knob in family mpls under hash-key configuration shown above. However, since ACX2000 
and ACX4000 also support TDM pseudowires, the ether-pseudowire knobs needs to be used only when 
TDM pseudowires are not being used. 


For Layer 3 VPN tunnel termination, upto two labels are used for hasing and payload IP source and 
destination addresses and Layer 4 source and destination ports can be optionally selected. These controls 
can be used for supporting ip port-data knobs in family mpls under hash-key configuration shown above. 
However, since Layer 4 port MSB and LSB cannot be individually selected, one of destination-Isb or 
destination-msb knobs or one of source-Isb or source-msb knobs would select Layer 4 destination or 
source ports, respectively. 


For LSR case, upto three labels are used for hashing. If a BOS is seen when parsing the first three labels, 
BCM examines the first nibble of payload - if the nibble is 4, the payload is treated as IPv4 and if the first 
nibble is 6, the payload is treated as IPv6 and in such cases payload source and destination IP addresses 
can be speculatively used for hashing. These controls can be used for supporting ip port-data knobs in 
family mpls under hash-key configuration. However, Layer 4 ports cannot be used for hashing in LSR case, 
and only layer-3-only knob is applicable. BCM does not claim support for hashing on fields beyond the 
three MPLS labels. Load Balancing for a single pseudowire session does not take place in case of LSR as 
all the traffic specific to that session will carry the same set of MPLS labels. 


Load balancing on LSR AE interfaces can be achieved for a higher number of MPLS sessions, that is minimum 
of 10 sessions. This is applicable for CCC/VPLS/L3VPN. In case of Layer 3 VPN, the traffic may not be 
equally distributed across the member links as the layer 3 addresses also get accounted for (along with 
the labels) for the hash input function. 


For LER scenarios, in case of ACX5048 and ACX5096, hashing based on Layer 3 and Layer 4 fields is 
possible by configuring the payload option under the “family mpls” hierarchy. Hashing on the LER is not 
be based on Labels. For Layer 3 service, it is mandatory to mention the payload as “layer-3-only” and 
specify “port-data” in case of Layer 4 service. You can also mention the label count while configuring 
hash-keys on LER routers. 
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NOTE: LER and LSR load balancing behavior is applicable for CCC/VPLS/Layer 3 VPN and other 
IP MPLS scenarios. 


This feature applies to aggregated Ethernet and aggregated SONET/SDH interfaces. In addition, you can 


configure load balancing for IPv4 traffic over Layer 2 Ethernet pseudowires. You can also configure load 


balancing for Ethernet pseudowires based on IP information. The option to include IP information in the 


hash key provides support for Ethernet circuit cross-connect (CCC) connections. 


Table 10 on page 185 provides detailed information about all of the possible MPLS LSP load-balancing 


options. 


Table 10: MPLS LSP Load Balancing Options 


Statement 


label-l 


label-2 


label-3 


no-labels 


payload 


disable 


etherspseudowire 


ip 


layer-3-only 


MPLS LSP Load Balancing Options 
Include the first label in the hash key. Use this option for single label packets. 


Include the second label in the hash key. You must also configure the label-1 option. The entire first 
label and the first 16 bits of the second label are used in the hash key. 


Include the third label in the hash key. You must also configure the label-1 option and the label-2 


option. 


Excludes MPLS labels from the hash key. 


Allows you to configure which parts of the IP packet payload to include in the hash key. For the PTX 
Series Packet Transport Switch, this value is set by default. 


Exclude IP payload from the hash key. 


Load-balance |Pv4 traffic over Layer 2 Ethernet pseudowires. 


Include the IPv4 or IPv6é address in the hash key. You must also configure either label-I or no-labels. 


Include only the Layer 3 IP information in the hash key. Excludes all of the port-data bytes from the 
hash key. 


Table 10: MPLS LSP Load Balancing Options (continued) 


Statement 


port-data 


destination-Isb 


destination-msb 


source-Isb 


source-msb 


MPLS LSP Load Balancing Options 


Include the source and destination port field information. By default, the most significant byte and 
least significant byte of the source and destination port fields are used in the hash key. To select 
specific bytes to use in the hash key, include one or more of the source-msb, source-Isb, 
destination-msb, and destination-Isb options at the [edit forwarding-options hash-key family mpls 
payload ip port-data] hierarchy level. To prevent all four bytes from being hashed, include the 
layer-3-only statement at the [edit forwarding-options hash-key family mpls payload ip] hierarchy 
level. 


Include the least significant byte of the destination port in the hash key. Can be combined with any 
of the other port-data options. 


Include the most significant byte of the destination port in the hash key. Can be combined with any 
of the other port-data options. 


Include the least significant byte of the source port in the hash key. Can be combined with any of the 
other port-data options. 


Include the most significant byte of the source port in the hash key. Can be combined with any of the 
other port-data options. 


To include the IP address as well as the first label in the hash key, configure the label-1 statement and the 


ip option for the payload statement at the [edit forwarding-options hash-key family mpls] hierarchy level: 


[edit forwarding-options hash-key family mpls] 


label-1; 

payload { 
ip; 

} 


To include the IP address as well as both the first and second labels in the hash key, configure the label-1 


and label-2 options and the ip option for the payload statement at the [edit forwarding-options hash-key 


family mpls] hierarchy level: 


[edit forwarding-options hash-key family mpls] 


label-1; 

label-2; 

payload { 
ip; 

} 
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Ensure proper load balancing by including the label-1, label-2, and label-3 options at the 
[edit forwarding-options hash-key family mpls] hierarchy level: 


[edit forwarding-options hash-key family mpls] 
label-1; 
label-2; 
label-3; 


MPLS Encapsulated Payload Load-balancing Overview 


Routers can load-balance on a per-packet basis in MPLS. Load balancing can be performed on the 
information in both the IP header and on up to three MPLS labels, providing a more uniform distribution 
of MPLS traffic to next hops. 


Load balancing is used to evenly distribute traffic when the following conditions apply: 


e There are multiple equal-cost next hops over different interfaces to the same destination. 
e There is a single next hop over an aggregated interface. 


By default, when load balancing is used to help distribute traffic, a hash algorithm is used to select a 
next-hop address to install into the forwarding table. Whenever the set of next hops for a destination 
changes in any way, the next-hop address is reselected by means of the hash algorithm. 


In case of multiple transport layer networks such as Ethernet over MPLS or Ethernet pseudowire, the hash 
algorithm needs to look beyond the outer header of the payload and into the inner headers to generate 
an even distribution. To determine the inner encapsulation, the PFE relies on the presence of certain codes 
or numbers at fixed payload offets; for example the presence of payload type OX800 or the presence of 
protocol number 4 for an IPv4 packet. In Junos OS, you can configure zero-control-word option to indicate 
the start of an Ethernet frame in an MPLS ether-pseudowire payload. On seeing this control word, which 
is four bytes having a numerical value of all zeros, the hash generator assumes the start of an Ethernet 
frame at the end of the control word in an MPLS ether-pseudowire packet. 


NOTE: For DPC I-chip-based cards, configure the zero-control-word option at the [edit 
forwarding-options hash-key family mpls ether-pseudowire] hierarchy level; and for MPC cards, 
configure the zero-control-word option at the [edit forwarding-options enhanced-hash-key 
family mpls ether-pseudowire] hierarchy level. 
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Configuring MPLS Encapsulated Payload for Load Balancing 


By default, when load balancing is used to help distribute traffic, a hash algorithm is used to select a 
next-hop address to install into the forwarding table. Whenever the set of next hops for a destination 
changes in any way, the next-hop address is reselected by means of the hash algorithm. Configure the 
zero-control-word option to indicate the start of an Ethernet frame in an MPLS ether-pseudowire payload. 
On seeing this control word, four bytes having a numerical value of all zeros, the hash generator assumes 
the start of the Ethernet frame at the end of the control word in an MPLS ether-pseudowire packet. 


Before you begin to configure MPLS encapsulated payload for load balancing, configure routing and 
signaling protocols. 


To configure MPLS encapsulated payload for load balancing: 
1. Configure the zero-control-word option to indicate the start of an Ethernet frame in an MPLS 
ether-pseudowire payload. 


e For DPC I|-chip-based cards, configure the zero-control-word option at the [edit forwarding-options 
hash-key family mpls ether-pseudowire] hierarchy level. 


[edit forwarding-options hash-key family mpls ether-pseudowire] 
user@host# set zero-control-word 


e For MPC cards, configure the zero-control-word option at the [edit forwarding-options 
enhanced-hash-key family mpls ether-pseudowire] hierarchy level. 


[edit forwarding-options enhanced-hash-key family mpls ether-pseudowire] 
user@host# set zero-control-word 


Policy-Based Multipath Routes Overview 
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Segment routing networks can have multiple transport protocols in the core. You can combine segment 
routing SR-TE LDP or RSVP routes and SR-TE IP routes and install a multipath route in the routing 
information base (also known as routing table). You can then steer selective service traffic using the 
mutlipath route through policy configuration. 


Understanding Policy-Based Multipath Routes 


There are different transport protocols in a network, such as IGP, labelled IGP, RSVP, LDP, and segment 
routing traffic-engineering (SR-TE) protocols, that are used to resolve service traffic. However, you could 
not use a combination of the transport protocols to resolve the service traffic. With the introduction of 
the policy-based multipath feature, you can combine segment routing traffic-engineered (SR-TE) LDP or 
RSVP routes and SR-TE IP routes to create a multipath route that is installed in the routing information 
base. You can resolve BGP service routes over the mutlipath route through policy configuration and steer 
traffic differently for different prefixes. 


A multipath route has combined next hops of route entries that are used for load balancing. All the 
supporting routes of the multipath route entry must be in same routing information base. When the 
supporting routes are under different routing information base, you can use the rib-group configuration 
statement to add route entries to a particular routing information base. 


You can configure a multipath route using a policy to select the list of routes whose next hops is to be 
combined together. When you include the policy-multipath statement along with the policy statement at 
the [edit routing-options rib routing-table-name] hierarchy level, a policy-based multipath route is created. 


The policy-based multipath feature is supported for both IP and IPvé6 protocols, and can be configured 
under the [edit routing-instances] hierarchy level. 


For example: 


[edit routing-options] 

user@host# set rib inet.3 policy-multipath policy example-policy 

[edit policy-options] 

user@host# set policy-statement example-policy from example-conditions 
user@host# set policy-options policy-statement example-policy then accept 


The configured policy is applied to each route entry for a given prefix. The multipath route is created only 
when more than one route (including active route) passes the policy. Any action commands configured in 
the policy, such as apply, is evaluated using the active route. For non-active routes, the policy is applied 
to check if the routes can participate in the multipath route or not. Multipath routes inherit all attributes 
of the active route. These attributes can be modified using the multipath policy configuration. 


Benefits of Policy-Based Multipath Routes 


e Provides flexibility to combine core network protocols to steer selective traffic. 


e Optimizes network performance with weighted equal-cost multipath using multipath routes. 
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Policy-Based Multipath Routes for Route Resolution 


You can combine segment routing traffic-engineered (SR-TE) LDP or RSVP routes and SR-TE IP routes 
and install a multipath route in the routing information base. The policy-based multipath routes are not 
active entries in the routing information base. When a multipath route is generated by configuration of 
policy, it is used for resolving protocol next hops instead of active routes. A multipath route next hop is 
created by merging gateways of next hops of each constituent route. 


Take the following into consideration when configuring policy-based multipath routes for route resolution: 


If the member route of a multipath route points to a next hop other than the router next hop or an 


indirect next hop with forwarding next hop to the router next hop, such next hops are ignored. 


If the constituent routes point to indirect next hop, then gateways from the forwarding-next hop are 


merged and the indirect next hop is ignored. 


If total number of gateways exceeds the maximum-ecmp supported on the device, then only the 
maximum-ecmp gateways are retained and all other gateways are ignored. 


e Gateways with lower weights are given preference. When one of the member route has unilist of indirect 
next hops and each of the next hop is pointing to a forwarding next hop, there can be weight values 
both at the indirect next hop and at forwarding next hop. In such cases, weight value of gateways is 
updated to reflect the combined effect of weights at both levels. 


Sample Route Resolution Using Policy-Based Multipath Routes 


Taking as an example, let us assume there are segment routing traffic-engineered LSPs, label IS-IS routes, 
and LDP LSPs for a destination 1.1.1.1/32, as displayed in the output below: 


ete lo Ly se2 * [SPRING-TE/8] 00:00:58, metric 1, metric2 30 
> ico Is ,l,1,.2 wie Ge-O/0/1.1, Busia S3393, Pusia BOLOOS, Pwsia 





801006 (top) 
[L-IES1S/14] 1IwOd 00:15:57, metric 10 
> to 12Z,i,1,1 wile @e-0/0/0.1 


t@ IP 22.l.1 wie Ge-0/0/0.2 
e© 12.23 ,l,1 Waa Ge-O0/0/0.3 
to 12.24.1.1 via ge-0/0/0.4 
CO 12,25. 1,1 waa ce-O/0/0.5 


co Is,i1.1.2 wie Ge-O/O/i1.1, Busia SOLOOL, wWiwisle, SOLOS (eiojsy) 
DIP / LS], ievcl OOSOSs27 meee AL 

> ice 121,11 wla ge-0/0/0.1 

t@ I2.22,l.1 wie Ge-0/0/0.2 

to 12.23.1.1 via ge-0/0/0.3 

so 12 24.1, wile ce-0/0/0.4 

to 12.25.1.1 via ge-0/0/0.5 

c© Is,1,1.2 wie ge-O/O/il.l, Busia SOLOOL, wisi SO00S (eiojsy) 
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Here, segment routing LSP is the active route entry to the 1.1.1.1 destination, and by default, only this 


route is used to resolve any services resolving over 1.1.1.1. 


When there is a requirement to use more than one protocols for resolving service routes, you can achieve 


this by configuring policy-multipath to combine the protocols. For instance, if segment routing and LDP 


paths are required for service resolution, you must configure policy-multipath combining the segement 
routing and LDP routes for prefix 1.1.1.1. 


For example: 


[edit policy-options] 


user@host# set rib inet.3 policy-multipath policy example-policy 


user@host# set policy-statement abc term 1 from protocol spring-te 


user@host# set policy-statement abc term 1 from protocol Idp 


user@host# set policy-statement abc term 1 from route-filter 1.1.1.1/32 exact 


user@host# set policy-statement abc term 1 then accept 


With this configuration, you create a policy-based multipath route for prefix 1.1.1.1/32 that uses constituent 


route entries of segment routing and LDP protocols. 


You can view the multipath route using the show route command output, as follows: 


ig ib 6 ils Ly Se * [SPRING-TE/8] 00:10:28, metric 1, metric2 30 
> cO Is,1,1.2 wie Ge-O/O0/1.l, Pusin ASSIS, Busia SOLOOS, Pusia 


801006 (top) 





[SS / lei) Is@cl OOse5627, ireiereste’ 110) 


= 


(=! 


Wools wha Ce—0/0/0.1 


IZ 22olol wie GS-0/0/0.2 
12.23.1.1 via ge-0/0/0.3 
12.24.1.1 via ge-0/0/0.4 
1A 25 oi wile Ge—-0/O/0.5 
iSpy 2 vera 0) 0)/ esl ae esis OOO aust Ss OM OOS tsar) 


D2/iS)|) Apel OOSLSsS7, wmercicae IL 


IWoioiod wha Ce—0/0/0.1 

12222 vata ge—0)/ 0/02 
IA 23, io Wile Ge—0/O/0.8 
12.24.1.1 via ge-0/0/0.4 
IA 25 lol wile Ge—0/O/0.5 


IS ,1,1.2 Wila oGe-O/0/1l.1, Pusia SOLOOI, Pusin SOLOS (ees) 


[Multipath/8] 00:03:13, metric 1, metric2 30 


> 


CO 


CO 


CO 





CO 


I2,1,1,1 wia ge-0/0/0.1 

127, 22.1.1 vila ge—0/0/0).2 
12 2S eval —0l/ O10 
12.24.1.1 via ge-0/0/0.4 
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tO 12,25. 1,1 wia ge-0/0/0.5 

tO IZ 1.1.2 wia oGe-O/0/1.il, Pusin SISIS, Pusia SOIOOS, Pusin 
801006 (top) 

GO IZ 1.1.2 wia oe-O/0/1.il, Pusin SOLOOL, Pugin SOLOOS (ees) 


You can see form the command output that the multipath route combines next hops of segment routing 
and LDP paths. The multipath route it is not active, and by default, the route preference and metric is the 
same as that of active route. 


NOTE: 


You can use the following combinations for the poilcy-based multipath route: However we 
cannot create multipath of LDP/L-ISIS as active-route is not part of multipath. 


e Segment routing traffic-engineered LSPs and LDP LSPs. 
e Segment routing traffic-engineered LSPs, and label IS-IS paths. 
e Segment routing traffic-engineered LSPs, LDP LSPs, and label IS-IS paths. 


However, you cannot create multipath route of LDP and label IS-IS, as the active route is not 
part of the multipath route. 


With the same configuration, assuming that there is a static route 1.2.3.4/32 configured with a protocol 
next hop of 1.1.1.1, this route is resolved using the multipath route over both segment routing 
traffic-engineered LSPs and LDP LSPs. 


For example: 


Ws ee Sg Ay SO “[Siracac/ >] OOsO0OsI2, weiciene? i 
tO IZ i ii wie Ge-0/0/0. 1 


2S ico 12.22.11 wie ¢e-0/0/0 62 
c© 12,23. 1.1 waa oe-O/0/0.3 
bo IZ 2H i. wale Ce-0/0/0.4 
co 12,251, waa ce-0/0/0.5 


f© IZ ,il,1,.2 wile Ge-O/0/1o1, Busia 33333, Busia BOLOOS, Pisin 
801006 (top) 





e© IS ,l,1,.2 wile Ge-O/0/lol, Busia BOLOOL, Pusin SOUOOS (ees) 


Enhancement to Class-of-Service (CoS) Forwarding-Policy 


For class-of-service-based forwarding, you must use the forwarding-policy next-hop-map configuration 
statement. 
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Prior to Junos OS Release 19.1R1, the match conditions supported under class-of-service-based forwarding 


included: 


e next-hop—Match next hop based on outgoing interface or next hop address. 
e Isp-next-hop—Match named LSPs using regular expression of LSP name. 


e non-Isp-next-hop—Match all LSPs without an LSP name. 


With the policy-based multipath route feature, you can also match all next hops without a label for certain 
prefixes. To do this, you must enable the non-labelled-next-hop option at the [edit class-of-service 
forwarding-policy next-hop-map map-name forwarding-class forwarding-class-name hierarchy level. 


For example: 


[edit] 
class-of-service { 
forwarding-policy { 
next-hop-map abc { 
forwarding-class best-effort { 
non-labelled-next-hop; 


Enhancements to Policy Match Protocol 


Prior to Junos OS Release 19.1R1, when you used a policy to match protocol using the from protocol 
statement at the [edit policy-options policy-statement statement-name] hierarchy level, all protocol routes 
(labeled and unlabeled) were matched. With the policy-based multipath route feature, you can match 
labeled protocol routes specifically. 


The options for matching labeled protocols) are: 


e |-isis—Match labeled IS-IS routes. The isis option matches IS-IS routes, excluding label IS-IS routes. 


e l-ospf—Match labled OSPF routes. The ospf option matches all OSPF routes, including OSPFv2, OSPFv3 
and label OSPF. 


For example: 


[edit] 
policy-options { 
policy-statement abc { 
from protocol [ |-ospf I-isis ]; 
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Impact of Configuring Policy-Based Multipath Route on Network Performance 


When you configure policy-based multipath route, a change of route in the routing information base results 
in the evaluation of the policy to check if a multipath route needs to be created. Because this feature 
requires that member routes must be in the same routing information base, the rib-group statement is 
used to merge routes from different routing information base. Configuring the rib-group statement at the 
application level increases number of routes in the system. 


When there are a number of routes in the routing information base, constant change of routes leads to 
reevaluation of the multipath policy. This could impact network performance. It is recommended to 
configure the policy-based multipath route feature only when required. 


Understanding IP-Based Filtering and Selective Port Mirroring of MPLS Traffic 


IN THIS SECTION 


@ _‘|P-Based Filtering of MPLS Traffic | 194 
@ Selective Port Mirroring of MPLS Traffic | 195 


@ Sample Configurations | 196 


Inan MPLS packet, the IP header comes immediately after the MPLS header. The IP-based filtering feature 
provides a deep inspection mechanism, where a maximum of upto eight MPLS labels of the inner payload 
can be inspected to enable filtering of MPLS traffic based on IP parameters. The filtered MPLS traffic can 
also be port mirrored to a monitoring device to offer network-based services in the core MPLS network. 


IP-Based Filtering of MPLS Traffic 


Prior to Junos OS Release 18.4R1, filtering based on IP parameters was not supported for MPLS family 
filter. With the introduction of the IP-based filtering feature, you can apply inbound and outbound filters 
for MPLS-tagged IPv4 and IPv6 packets based on IP parameters, such as source and destination addresses, 
Layer 4 protocol type, and source and destination ports. 


The IP-based filtering feature enables you to filter MPLS packets at the ingress of an interface, where the 
filtering is done using match conditions on the inner payload of the MPLS packet. The selective MPLS 
traffic can then be port mirrored to a remote monitoring device using logical tunnels. 


To support IP-based filtering, additional match conditions are added that allow MPLS packets to be deep 
inspected to parse the inner payload with Layer 3 and Layer 4 headers before the appropriate filters are 
applied. 
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NOTE: The IP-based filtering feature is supported only for MPLS-tagged IPv4 and IPv6 packets. 
In other words, the MPLS filters match IP parameters only when the IP payload comes immediately 
after the MPLS labels. 


In other scenarios, where the MPLS payload includes pseudowires, protocols other than inet 
and inet6, or other encapsulations like Layer 2 VPN or VPLS, the IP-based filtering feature is not 
supported. 


The following match conditions are added for the IP-based filtering of MPLS traffic: 


e |Pv4 source address 
e IPv4 destination address 
e IPv6é source address 


IPv6 destination address 


Protocol 


Source port 


Destination port 


Source IPv4 prefix list 


Destination IPv4 prefix list 


Source IPv6 prefix list 


Destination IPvé6 prefix list 


NOTE: The following match combinations are supported for the IP-based filtering of MPLS 
traffic: 


e Source and destination address match conditions with IPv4 and IPv6 prefix lists. 


e Source and destination port address and protocol types match conditions with IPv4 and IPv6é 
prefix lists. 


Selective Port Mirroring of MPLS Traffic 


Port mirroring is the capability of mirroring a packet to a configured destination, in addition to the normal 
processing and forwarding of the packets. Port mirroring is applied as an action for a firewall filter, which 
is applied at the ingress or egress of any interface. Similarly, the selective port mirroring feature provides 
the capability to mirror MPLS traffic, which is filtered based on IP parameters, to a mirrored destination 
using logical tunnels. 
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To enable selective port mirroring, additional actions are configured at the [edit firewall family mpls filter 
filter-nameterm term-name then] hierarchy level, in addition to the existing counter, accept, and discard 
actions: 


e port-mirror 
e port-mirror-instance 
Port Mirroring 


The port-mirror action enables port mirroring globally on the device, which applies to all Packet Forwarding 
Engines (PFEs) and associated interfaces. 


For MPLS family filter, the port-mirror action is enabled for global port mirroring. 
Port Mirroring Instance 


The port-mirror-instance action enables you to customize each instance with different properties for input 
sampling and port mirroring output destinations, instead of having to use a single system-wide configuration 
for port mirroring. 


You can configure only two port mirroring instances per Flexible PIC Concentrator (FPC) by including the 
instance port-mirror-instance-name statement at the [edit forwarding-options port-mirror] hierarchy level. 
You can then associate individual port mirroring instances with an FPC, PIC, or (Forwarding Engine Board 
(FEB) depending on the device hardware. 


For MPLS family filter, the port-mirror-instance action is enabled only for the port-mirroring instance. 


NOTE: For both port-mirror and port-mirror-instance actions, the output interface must be 
enabled with Layer 2 family and not family MPLS (Layer 3) for the selective port mirroring feature 
to work. 


Sample Configurations 
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IP-Based Filtering Configuration 


[edit firewall family mpls filter mpls-filter] 
term ipv4-term { 
from { 
ip-version { 
ipv4 { 
source-address { 
10.10.10.10/24; 
} 
destination-address { 
20.20.20.20/24; 
} 
protocol tcp { 
source-port 100; 
destination-port 200; 
} 
soure-prefix-list ipv4-source-users; 
destination-prefix-list ipv4-destination-users; 


} 
exp 1; 
} 
then port-mirror; 
then accept; 
then count; 
} 
term ipvé-term { 
from { 
ip-version { 
ipvé { 
source-address { 
2000::1/128; 
} 
destination-address { 
3000::1/128; 
} 
protocol tcp { 
source-port 100; 
destination-port 200; 
} 
source-prefix-list ipv6-source-users; 
destination-prefix-list ipv6-destination-users; 
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exp 1; 
} 
then port-mirror-instance port-mirror-instance1; 
then accept; 
then count; 


[edit policy-options] 

prefix-list ipv4-source-users { 
172.16.1.16/28; 
172.16.2.16/28; 

} 

prefix-list ipv6-source-users { 
2001::1/128, 
3001::1/128, 


[edit interfaces] 
xe-0/0/1 { 
unit O { 
family inet { 
address 100.100.100.1/30; 
} 
family mpls { 
filter { 
input mpls-filter; 


Selective Port Mirroring Configuration 


[edit forwarding-options] 
port-mirroring { 
input { 
rate 2; 
run-length 4; 
maximum-packet-length 500; 
} 
family any { 
output { 
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interface xe-2/0/2.0; 


[edit forwarding-options] 
port-mirroring { 
instance { 
port-mirror-instance1 { 
input { 
rate 3; 
run-length 5; 
maximum-packet-length 500; 
} 
family any { 
output { 
interface xe-2/0/2.0; 


NOTE: The output interface xe-2/0/2.0 is configured for Layer 2 family and not family MPLS. 


For both port-mirror and port-mirror-instance actions, the output interface must be enabled 
with Layer 2 family and not family MPLS (Layer 3) for the selective port mirroring feature to 


work. 


Mirrored Destination Configuration 


[edit interfaces] 
xe-2/0/2 { 
vian-tagging; 
encapsulation extended-vlan-bridge; 
unit O { 
vlan-id 600; 
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[edit bridge-domains] 
bd { 
domain-type bridge; 
interface xe-2/0/2.0; 


Release History Table 


Release Description 


19.1R1 Starting in Junos OS Release 19.1R1, for MX Series routers with MPC and MIC interfaces, 


up to sixteen incoming MPLS labels are included in the hash key. 
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SRLG Overview 


In MPLS traffic engineering, a Shared Risk Link Group (SRLG) is a set of links sharing a common resource, 
which affects all links in the set if the common resource fails. These links share the same risk of failure and 
are therefore considered to belong to the same SRLG. For example, links sharing a common fiber are said 
to be in the same SRLG because a fault with the fiber might cause all links in the group to fail. 


An SRLG is represented by a 32-bit number unique within an IGP (OSPFv2 and IS-IS) domain. A link might 
belong to multiple SRLGs. The SRLG of a path in a label-switched path (LSP) is the set of SRLGs for all the 
links in the path. When computing the secondary path for an LSP, it is preferable to find a path such that 
the secondary and primary paths do not have any links in common in case the SRLGs for the primary and 
secondary paths are disjoint. This ensures that a single point of failure on a particular link does not bring 
down both the primary and secondary paths in the LSP. 


When the SRLG is configured, the device uses the Constrained Shortest Path First (CSPF) algorithm and 
tries to keep the links used for the primary and secondary paths mutually exclusive. If the primary path 
goes down, the CSPF algorithm computes the secondary path by trying to avoid links that share any SRLG 
with the primary path. In addition, when computing the path for a bypass LSP, CSPF tries to avoid links 
that share any SRLG with the protected links. 


When the SRLG is not configured, CSPF only takes into account the costs of the links when computing 
the secondary path. 


Any change in link SRLG information triggers the IGP to send LSP updates for the new link SRLG information. 
CSPF recomputes the paths during the next round of reoptimization. 


Junos OS Release 11.4 and later supports SRLG based on the following RFCs: 


e RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). 
e RFC 5307, IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS). 


NOTE: Currently, the “Fate Sharing” feature continues to be supported with the SRLG feature. 
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This example shows how to configure Shared Risk Link Groups (SRLGs) on a device. 
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Requirements 


This example uses the following hardware and software components: 


e Seven routers that can be a combination of M Series, MX Series, or T Series routers 


e Junos OS Release 11.4 or later running on all the devices 


Overview 


Junos OS Release 11.4 and later support SRLG configuration in an IGP (OSPF v2 and IS-IS) domain. In this 
example, you configure SRLG and associate it with the MPLS interface on a device. 


The device uses the SRLG cost parameter for the Constrained Shortest Path First (CSPF) algorithm and 
tries to keep the links used for the primary and secondary paths mutually exclusive by avoiding links that 
share any SRLG with the primary path. 


To configure the SRLG, you first define the SRLG parameters at the [edit routing-options srlg srlg-name] 
hierarchy level and then associate the SRLG with an MPLS interface at the [edit mpls interface 
interface-name] hierarchy level. 


The srlg srig-name statement has the following options: 


srlg-cost—Include a cost for the SRLG ranging from 1 through 65535. The cost of the SRLG determines 
the level of impact this SRLG has on the CSPF algorithm for path computations. The higher the cost, the 


less likely it is for a secondary path to share the same SRLG as the primary path. By default, the srlg-cost 
is 1. 


srlg-value—Include a group ID for the SRLG ranging from 1 through 4294967295. 


In this example, PE1 is the ingress router and PE2 is the egress router. P1, P2, and P3, P4, and P5 are 
transit routers. OSPF is configured on all the routers as the interior gateway protocol (IGP). SRLG is 
configured on all seven routers. The primary path includes SRLG srlg-a. For the standby secondary path, 


the link P2>PE2 belongs to SRLG srlg-a. The effective link metric, with the added srlg-cost of 10, becomes 
11. Therefore, the computed secondary path is PE1>P3>P4>P5>PE2 with a CSPF link metric of 4. 


Primary path 


------- Secondary path 


I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
g040925 


Configuration 


CLI Quick Configuration 


To quickly configure this section of the example, copy the following commands, paste them into a text 
file, remove any line breaks, change any details necessary to match your network configuration, and then 
copy and paste the commands into the CLI at the [edit] hierarchy level. 


Router PE1 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.1/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.13.1/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 192.168.14.1/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.1/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols rsvp interface ge-0/0/3.0 
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set protocols mpls optimize-timer 120 

set protocols mpls label-switched-path pe1-pe2 to 10.255.0.7 
set protocols mpls label-switched-path pe1-pe2 primary via-p1 
set protocols mpls label-switched-path pe1-pe2 secondary path2 standby 
set protocols mpls path via-p1 10.255.0.2 strict 

set protocols mpls path path2 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/3.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Router P1 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.2/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.27.2/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.0.2/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 srlg srlg-a 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Router P2 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.13.3/24 
set interfaces ge-0/0/1 unit 0 family mpls 
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set interfaces ge-0/0/2 unit 0 family inet address 192.168.37.3/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.0.3/32 
set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 srlg srlg-a 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Router P3 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.14.4/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.45.4/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.0.4/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Router P4 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.45.5/24 
set interfaces ge-0/0/1 unit 0 family mpls 
set interfaces ge-0/0/2 unit 0 family inet address 192.168.56.5/24 
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set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.5/32 
set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 
set protocols ospf area 0.0.0.0 interface lo0.0 


Router P5 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.56.6/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.67.6/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.6/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Router PE2 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.27.7/24 
set interfaces ge-0/0/1 unit 0 family mpls 
set interfaces ge-0/0/2 unit 0 family inet address 192.168.37.7/24 
set interfaces ge-0/0/2 unit 0 family mpls 
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set interfaces ge-0/0/3 unit 0 family inet address 192.168.67.7/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.7/32 
set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols rsvp interface ge-0/0/3.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/3.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure the ingress router PE1: 


1. Configure the device interfaces. 


[edit interfaces] 

user@PE1# set ge-0/0/1 unit 0 family inet address 192.168.12.1/24 
user@PE1# set ge-0/0/1 unit O family mpls 

user@PE1# set ge-0/0/2 unit O family inet address 192.168.13.1/24 
user@PE1# set ge-0/0/2 unit 0 family mpls 

user@PE1# set ge-0/0/3 unit O family inet address 192.168.14.1/24 
user@PE1# set ge-0/0/3 unit 0 family mpls 

user@PE1# set loO unit O family inet address 10.255.0.1/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@PE1# set traffic-engineering 

user@PE1# set area 0.0.0.0 interface ge-0/0/1.0 
user@PE1# set area 0.0.0.0 interface ge-0/0/2.0 
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user@PE1# set area 0.0.0.0 interface ge-0/0/3.0 
user@PE1# set area 0.0.0.0 interface 1o0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
user@PE1# set srlg srlg-a srlg-value 101 
user@PE1# set srlg srlg-a srlg-cost 10 


4. Configure MPLS and the LSPs. 


[edit protocols mpls] 

user@PE1# set interface ge-0/0/1.0 

user@PE1# set interface ge-0/0/2.0 

user@PE1# set interface ge-0/0/3.0 

user@PE1# set optimize-timer 120 

user@PE1# set label-switched-path pe1-pe2 to 10.255.0.7 
user@PE1# set label-switched-path pe1-pe2 primary via-p1 
user@PE1# set label-switched-path pe1-pe2 secondary path2 standby 
user@PE1# set path via-p1 10.255.0.2 strict 

user@PE1# set path path2 


5. Enable RSVP on the interfaces. 


[edit protocols rsvp] 

user@PE1# set interface ge-0/0/1.0 
user@PE1# set interface ge-0/0/2.0 
user@PE1# set interface ge-0/0/3.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show routing-options, show protocols mpls, and show protocols rsvp commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@PE1# show interfaces 
interfaces { 
ge-0/0/1 { 
unit O { 
family inet { 


address 192.168.12.1/24- 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 192.168.13.1/24, 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 192.168.14.1/24, 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 10.255.0.1/32; 


user@PE1# show protocols ospf 
traffic-engineering; 
area 0.0.0.0 { 


interface ge-0/0/1.0;; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 
interface 100.0; 


user@PE1# show protocols mpls 
optimize-timer 120; 


label-switched-path pe1-pe2 { 
to 10.255.0.7; 
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primary via-p1; 
secondary path2 { 
standby; 


} 

path via-p1 { 
10.255.0.2 strict; 

} 

path path2; 

interface ge-0/0/1.0; 

interface ge-0/0/2.0; 

interface ge-0/0/3.0; 


user@PE1# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@PE1# show routing-options 
routing-options { 
srlg { 
srlg-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 


NOTE: Repeat this procedure for every Juniper Networks router in the IGP domain, after 
modifying the appropriate interface names, addresses, and any other parameters for each router. 
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Verification 


IN THIS SECTION 


@ Verifying SRLG Definitions | 211 
@ Verify TE-Link SRLG | 211 
@ Verify Standby Secondary Path | 212 


Confirm that the configuration is working properly. 
Verifying SRLG Definitions 


Purpose 


Verify SRLG-to-value mappings and SRLG cost. 


Action 





user@PE1> show mpls srlg 


SRLG Value Cost 
Saale 1(O)aL 10 


Verify TE-Link SRLG 


Purpose 


Verify the traffic engineering link SRLG association. 
Action 


user@PE1> show ted link detail 





ID 25S cOs2-SlVZ IOS. 27,71, be@als 192 los Atoa, INSMeIESs 





Local interface index: 0, Remote interface index: 0 


LocalPath: 1, Metric: 1, StaticBW: 1000Mbps, AvailBW: 





Color: 0 <none> 
SRLGs: srlg-a 
localBW [0] Obps [1] Obps [2] Obps [3] Obps 
localBW [4] Obps [5] Obps [6] Obps [7] Obps 
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ID 2SS>oOsS-FIVZ MSS S7o7—-1l,;, hoeals 192,163 37.3, Rewocrces 0.0.0.0 


Local interface index: 0, Remote interface index: 0 








LocalPath: 0, Metric: 1, StaticBW: 1000Mbps, AvailBW: 1000Mbps 
Color: 0 <none> 

SRLGs: srlg-a 

localBW [0] Obps [1] Obps [2] Obps [SIO bps 

localBW [4] Obps [5] Ooos [6] Obps [7] Obps 


Meaning 
Links P1-PE2 and P2-PE2 are associated with SRLG srlg-a. 


Verify Standby Secondary Path 


Purpose 


Check the SRLG link cost and its impact on the CSPF computation of the standby secondary path link. 


Action 





user@PE1> show mpls Isp ingress extensive 


Ingress LSP: 1 sessions 


10.255 40.7) 
From: 10.255.0.1, State: Up, ActiveRoute: 0, LSPname: pel-pe2 
ActivePath: via-pl (primary) 

LSPtype: Static Configured 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


= 





Primary via-pl State: Up 
Picw@ediciess 7 O 

OptimizeTimer: 120 
SmartOptimizeTimer: 180 

SRLG: srlg-a 


Reoptimization in 110 second(s). 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2) 
192 168 .12.2 8 192,168.27 .7 & 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID): 
IS 168 .12.2 192. 168,27 47 
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7 Oct 13 15:17:11.310 CSPF: computation result ignored, new path no benefit 
COC srl S lp) 4 SONS elected walsmactlvcmpatl 
S Occ 13 lSsilssil4é.95s3 Record inNowres I92.168.12.2 192,168.27 67 
Al (yeie 1s) iSyg aye ial Sel (io) 
3 Oe 19 Isgiseil4i 79S Oeicainaice Celi 
~ Oee 13 Ihsisci4t’.79s CSPRFs Conjeutacdcm result acegerscd I192,168,12.2 
192 168.27 67 
1 Oct 13 15:14:46.214 CSPF failed: no route toward 10.255.0.2 
Standby path2 State: Up 
Pigdoriiietess 7 (0) 
OptimizeTimer: 120 
SmartOptimizeTimer: 180 
Reoptimization in 115 second(s). 





Computed ERO (S 
192,168 .,14.4 S$ 192.,168.45.5 § 192.153,.56,.6 S 192.168.6727 § 


4=B/W 8=Nod 


[L] denotes strict [loose] hops): 


Received RRO (ProtectionFlag 1=Available 2=InUs 


(CSPF metric: 


4) 


10=SoftPr 





20=Node-ID): 
192,168,144 192. 168.45.5 192.168.56,.6 192.168 .67 .7 

















10 Oee 13 Lagiveilil, 29 insecorrmel Nowe s 
192.168 67.7 
) Gee 1S Igilyeti Vasey iyo 
@ Ot 15 iSeilvsiil,729 Origimece: Call 
7 O@e 13 iSsivsiil.729 Clear Call 
6 Oct 13 15:17:11.729 CSPF: computation result accepted 192 
192 ,168.45.5 192 .168.56.6 192.168.67 .7 
DeOcty Poel se sei 29M CSPR RCT OuLCmGlc™ LOmGCSOpiilmEZatslon 
4 Occ 1s ISsilacil4 984 Record Rowces I92.168.13.3 192,168.37. 
S Oye is) iSy¢ ise Lal, Sisto) 
2 Oct 13 ISsiscia’.830 Oragaumecre Calli 
1 Oct 13 15:15:14.830 CSPF: computation result accepted 192 
192 168.37 .7 
CHecirScls Wom Occ 13 LHsilseao Boil 


Total 1 displayed, Up 1, Down 0 


Meaning 


mpt 


IQA os dA 4 IA eS oA. S 12 5 oso SO6G 


.168.14.4 


5 LOS, 1353 


Check the standby secondary path. The effective link cost for P2>PE2 is 11 (with the added srlg-cost of 
10). CSPF computes the secondary path as PE1>P3>P4>P5>PE2 with a CSPF link metric of 4. 


Example: Excluding SRLG Links Completely for the Secondary LSP 


IN THIS SECTION 


Requirements | 214 
Overview | 214 
Configuration | 215 


Verification | 219 


This example shows how to configure the exclude-srlg option to exclude Shared Risk Link Group (SRLG) 
links for the secondary label-switched path (LSP). 


Requirements 


This example uses the following hardware and software components: 


e M Series, MX Series, or T Series devices 


e Junos OS Release 11.4 or later running on all the devices 


Overview 


For critical links where it is imperative to keep the secondary and primary paths completely disjoint from 
any common SRLG, you can optionally configure the exclude-srlg statement at the [edit protocols mpls] 
or [edit protocols mpls label-switched-path path-name] hierarchy levels. For logical systems, you configure 
the exclude-srlg statement at the edit logical-systems protocols mpls[edit logical-systems 
logical-system-name protocols mpls label-switched-path path-name] hierarchy level. 


If exclude-srlg is configured, the Constrained Shortest Path First (CSPF) algorithm excludes any link 
belonging to the set of SRLGs in the primary path. If exclude-srlg is not configured, and if a link belongs 
to the set of SRLGs in the primary path, CSPF adds the SRLG cost to the metric, but still accepts the link 
for computing the path. 


In this example, PE1 is the ingress router and PE2 is the egress router. P1, P2, and P3, P4, and P5 are 
transit routers. OSPF is configured on all the routers as the interior gateway protocol (IGP). SRLG is 
configured on all seven routers. The primary path includes SRLG srlg-a. For the standby secondary path, 
the link P2>PE2 belongs to SRLG srlg-a. Because exclude-srlg is configured, CSPF rejects link P2>PE2 as 
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the link belongs to the SRLG srlg-a. Therefore, the computed standby secondary path is 
PE1>P3>P4>P5>PE2. 


Primary path 


------- Secondary path 


I 
I 
I 
I 
I 
I 
I 
I 
I 
I 
g040925 


Configuration 


CLI Quick Configuration 


To quickly configure this section of the example, copy the following commands, paste them into a text 
file, remove any line breaks, change any details necessary to match your network configuration, and then 
copy and paste the commands into the CLI at the [edit] hierarchy level. 


Router PE1 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.1/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.13.1/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 192.168.14.1/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.1/32 

set routing-options srlg srlg-a srlg-value 101 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols rsvp interface ge-0/0/3.0 

set protocols mpls optimize-timer 120 
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set protocols mpls exclude-srlg 

set protocols mpls label-switched-path pe1-pe2 to 10.255.0.7 
set protocols mpls label-switched-path pe1-pe2 primary via-p1 
set protocols mpls label-switched-path pe1-pe2 secondary path2 standby 
set protocols mpls path via-p1 10.255.0.2 strict 

set protocols mpls path path2 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/3.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


1. Configure the device interfaces. 


[edit interfaces] 

user@PE1# set ge-0/0/1 unit 0 family inet address 192.168.12.1/24 
user@PE1# set ge-0/0/1 unit 0 family mpls 

user@PE1# set ge-0/0/2 unit O family inet address 192.168.13.1/24 
user@PE1# set ge-0/0/2 unit O family mpls 

user@PE1# set ge-0/0/3 unit O family inet address 192.168.14.1/24 
user@PE1# set ge-0/0/3 unit 0 family mpls 

user@PE1# set loO unit O family inet address 10.255.0.1/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@PE1# set traffic-engineering 

user@PE11# set area 0.0.0.0 interface ge-0/0/1.0 
user@PE11# set area 0.0.0.0 interface ge-0/0/2.0 
user@PE1# set area 0.0.0.0 interface ge-0/0/3.0 
user@PE1# set area 0.0.0.0 interface 1o0.0 


3. Configure the SRLG definitions. 
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[edit routing-options] 
user@PE1# set routing-options srlg srlg-a srlg-value 101 


4. Configure MPLS and the LSPs. 


[edit protocols mpls] 

user@PE1# set interface ge-0/0/1.0 

user@PE1# set interface ge-0/0/2.0 

user@PE1# set interface ge-0/0/3.0 

user@PE1# set optimize-timer 120 

user@PE1# set exclude-srlg 

user@PE1# set label-switched-path pe1-pe2 to 10.255.0.7 
user@PE1# set label-switched-path pe1-pe2 primary via-p1 
user@PE1# set label-switched-path pe1-pe2 secondary path2 standby 
user@PE1# set path via-p1 10.255.0.2 strict 

user@PE1# set path path2 


5. Configure the exclude-srlg statement to forcibly keep the links for the secondary path completely 
disjoint from the primary LSP path. 


user@PE1 set protocols mpls exclude-srlg 


6. Enable RSVP on the interfaces. 


[edit protocols rsvp] 

user@PE1# set interface ge-0/0/1.0 
user@PE1# set interface ge-0/0/2.0 
user@PE1# set interface ge-0/0/3.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show routing-options, show protocols mpls, and show protocols rsvp commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@PE1# show interfaces 
interfaces { 
ge-0/0/1 { 
unit O { 
family inet { 


address 192.168.12.1/24- 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 192.168.13.1/24, 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 192.168.14.1/24, 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 10.255.0.1/32; 


user@PE1# show protocols ospf 
traffic-engineering; 
area 0.0.0.0 { 


interface ge-0/0/1.0;; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 
interface 100.0; 


user@PE1# show protocols mpls 
optimize-timer 120; 


label-switched-path pe1-pe2 { 
to 10.255.0.7; 
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primary via-p1; 
secondary path2 { 
standby; 


} 

path via-p1 { 
10.255.0.2 strict; 

} 

path path2; 

interface ge-0/0/1.0; 

interface ge-0/0/2.0; 

interface ge-0/0/3.0; 


user@PE1# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@PE1# show routing-options 
routing-options { 
srlg { 
srlg-a srig-value 101; 


If you are done configuring the device, enter commit from configuration mode. 


NOTE: Repeat this procedure for every Juniper Networks router in the IGP domain, after 
modifying the appropriate interface names, addresses, and any other parameters for each router. 


Verification 


Confirm that the configuration is working properly. 


Verifying the Secondary Path Link for the LSP 


Purpose 


Verify that the link for the secondary path is completely disjoint from the primary path. 
Action 


user@PE1> show mpls Isp detail 
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Ingress LSP: 1 sessions 


10.255 6057 
From: 10.255.0.1, State: Up, ActiveRoute: 0, LSPname: pel-—pe2 
ActivePath: via-pl (primary) 

LSPtype: Static Configured 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


+ 





Primary via-pl State: Up 
Rigl@riiciess 7 © 

OptimizeTimer: 120 
SmartOptimizeTimer: 180 

SRLG: srlg-a 


Reoptimization in 77 second(s). 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2) 
192 IGS 12.2 8 192 168.27.) § 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID) : 
I92 168.127 .2 192,168.27. 7 
Standby path2 State: Up 





IiealOnedic dese 7 (0) 
OptimizeTimer: 120 
SmartOptimizeTimer: 180 


Reoptimization in 106 second(s). 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4) 
IA L68 14.4 S 192,168 .45.5 S 192.168.56.6 § 192. 163.67.7 § 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID): 
192 ,16S.,14,.4 192. 168-4555 192 168.5666 192.168 .67.7 
Total 1 displayed, Up 1, Down 0 





inuliokk Pi-SPm2zs SwRI syelle =a 








Tink P2-SPEh2: SRG srlg-a 














as) 





Primary path: Hil =P (ESE aie eraser) 


Standby secondary: PE1—-P3-P4-P5-PE2 (CSPF metric: 4) 








Meaning 


Primary path includes SRLG srlg-a. For the standby secondary path, the link P2>PE2 belongs to SRLG 
srlg-a. CSPF rejects link P2>PE2 because the link belongs to the SRLG srlg-a. 


Example: Configuring SRLG with Link Protection 


IN THIS SECTION 


Requirements | 221 
Overview | 221 
Configuration | 222 


Verification | 246 


This example shows how to configure SRLG with link protection without the exclude-srlg option. 
Requirements 

This example uses the following hardware and software components: 

e M Series, MX Series, or T Series devices 


e Junos OS Release 11.4 or later running on all the devices 


Overview 


In this example, PE1 is the ingress router and PE2 is the egress router. P1, P2, and P3, P4, and P5 are 
transit routers. OSPF is configured on all the routers as the interior gateway protocol (IGP). SRLG is 


configured on all seven routers. The link P1>PE2 (primary path) and the link P2>PE2 belong to SRLG srlg-a. 


You configure link protection for the interface P1>PE2 by including the link-protection statement. 
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When SRLG srlg-a is configured on the link P1>PE2 and P2>PE2, the bypass takes the longer path 
P1>P4>P5>PE2, not selecting the link P2>PE2 because of the added SRLG cost for srlg-a. 


Primary path 
ae Secondary path 


srig-a 


‘ 
| 


Configuration 


CLI Quick Configuration 


To quickly configure this section of the example, copy the following commands, paste them into a text 
file, remove any line breaks, change any details necessary to match your network configuration, and then 
copy and paste the commands into the CLI at the [edit] hierarchy level. 


Router PE1 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.1/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.13.1/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 192.168.14.1/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.0.1/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 
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set protocols rsvp interface ge-0/0/3.0 

set protocols mpls optimize-timer 120 

set protocols mpls label-switched-path pe1-pe2 to 10.255.0.7 
set protocols mpls label-switched-path pe1-pe2 link-protection 
set protocols mpls label-switched-path pe1-pe2 primary via-p1 
set protocols mpls label-switched-path pe1-pe2 secondary path2 standby 
set protocols mpls path via-p1 10.255.0.2 strict 

set protocols mpls path path2 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/3.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Router P1 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.2/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.27.2/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 192.168.23.2/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces ge-0/0/4 unit 0 family inet address 192.168.25.2/24 
set interfaces ge-0/0/4 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.2/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 link-protection 

set protocols rsvp interface ge-0/0/3.0 

set protocols rsvp interface ge-0/0/4.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 srlg srlg-a 

set protocols mpls interface ge-0/0/3.0 

set protocols mpls interface ge-0/0/4.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 


224 


set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 
set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 
set protocols ospf area 0.0.0.0 interface lo0.0 


Router P2 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.13.3/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.37.3/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 192.168.23.3/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.0.3/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols rsvp interface ge-0/0/3.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 srlg srlg-a 

set protocols mpls interface ge-0/0/3.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Router P3 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.14.4/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.45.4/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.0.4/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 
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set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 
set protocols ospf area 0.0.0.0 interface lo0.0 


Router P4 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.45.5/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.56.5/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 192.168.25.5/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.0.5/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols rsvp interface ge-0/0/3.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/3.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Router P5 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.56.6/24 
set interfaces ge-0/0/1 unit 0 family mpls 
set interfaces ge-0/0/2 unit 0 family inet address 192.168.67.6/24 
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set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.6/32 
set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 
set protocols ospf area 0.0.0.0 interface lo0.0 


Router PE2 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.27.7/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.37.7/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 192.168.67.7/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.7/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols rsvp interface ge-0/0/3.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/3.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Configuring Device PE1 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure the ingress router PE1: 


1. Configure the device interfaces. 


[edit interfaces] 

user@PE1# set ge-0/0/1 unit 0 family inet address 192.168.12.1/24 
user@PE1# set ge-0/0/1 unit 0 family mpls 

user@PE1# set ge-0/0/2 unit O family inet address 192.168.13.1/24 
user@PE1# set ge-0/0/2 unit O family mpls 

user@PE1# set ge-0/0/3 unit O family inet address 192.168.14.1/24 
user@PE1# set ge-0/0/3 unit 0 family mpls 

user@PE1# set loO unit O family inet address 10.255.0.1/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@PE1# set traffic-engineering 

user@PE1# set area 0.0.0.0 interface ge-0/0/1.0 
user@PE1# set area 0.0.0.0 interface ge-0/0/2.0 
user@PE1# set area 0.0.0.0 interface ge-0/0/3.0 
user@PE1# set area 0.0.0.0 interface 1o0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
user@PE1# set srlg srlg-a srlg-value 101 
user@PE1# set srlg srlg-a srlg-cost 10 


4. Configure MPLS and the LSPs and configure link protection for the pe1-pe2 LSP. 


[edit protocols mpls] 

user@PE1# set interface ge-0/0/1.0 

user@PE1# set interface ge-0/0/2.0 

user@PE1# set interface ge-0/0/3.0 

user@PE1# set optimize-timer 120 

user@PE1# set label-switched-path pe1-pe2 to 10.255.0.7 

user@PE1# set protocols mpls label-switched-path pe1-pe2 link-protection 
user@PE1# set label-switched-path pe1-pe2 primary via-p1 

user@PE1# set label-switched-path pe1-pe2 secondary path2 standby 
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user@PE1# set path via-p1 10.255.0.2 strict 
user@PE1# set path path2 


5. Enable RSVP on the interfaces. 


[edit protocols rsvp] 

user@PE1# set interface ge-0/0/1.0 
user@PE1# set interface ge-0/0/2.0 
user@PE1# set interface ge-0/0/3.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show routing-options, show protocols mpls, and show protocols rsvp commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@PE1# show interfaces 
ge-0/0/1 { 
unit O { 
family inet { 
address 192.168.12.1/24- 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 192.168.13.1/24; 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 192.168.14.1/24, 
} 


family mpls; 


loO { 
unit O { 
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family inet { 
address 10.255.0.1/32; 


user@PE1# show protocols ospf 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 
interface 100.0; 


user@PE1# show protocols mpls 
optimize-timer 120; 
label-switched-path pe1-pe2 { 

to 10.255.0.7; 

link-protection; 

primary via-p1; 

secondary path2 { 

standby; 


} 

path via-p1 { 
10.255.0.2 strict; 

} 

path path2; 

interface ge-0/0/1.0; 

interface ge-0/0/2.0; 

interface ge-0/0/3.0; 


user@PE1# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@PE1# show routing-options 
srig { 
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srlg-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 
Configuring Device P1 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure device P1: 


1. Configure the device interfaces. 


[edit interfaces] 

user@P1# set ge-0/0/1 unit 0 family inet address 192.168.12.2/24 
user@P1# set ge-0/0/1 unit 0 family mpls 

user@P1# set ge-0/0/2 unit O family inet address 192.168.27.2/24 
user@P1# set ge-0/0/2 unit O family mpls 

user@P1# set ge-0/0/3 unit O family inet address 192.168.23.2/24 
user@P1# set ge-0/0/3 unit O family mpls 

user@P1# set ge-0/0/4 unit O family inet address 192.168.25.2/24 
user@P1# set ge-0/0/4 unit O family mpls 

user@P1# set loO unit 0 family inet address 10.255.0.2/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@P1# set traffic-engineering 

user@P1# set area 0.0.0.0 interface ge-0/0/1.0 
user@P1# set area 0.0.0.0 interface ge-0/0/2.0 
user@P1# set area 0.0.0.0 interface ge-0/0/3.0 
user@P1# set area 0.0.0.0 interface ge-0/0/4.0 
user@P1# set area 0.0.0.0 interface lo0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
user@P1# set srlg srlg-a srlg-value 101 
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user@P1# set srlg srlg-a srlg-cost 10 


4. Configure MPLS on the interfaces and associate the SRLG srlg-a with interface ge-0/0/2.0 for the 
P1>PE2 link. 


[edit protocols mpls] 

user@P1# set interface ge-0/0/1.0 
user@P1# set interface ge-0/0/2.0 srlg srlg-a 
user@P1# set interface ge-0/0/3.0 
user@P1# set interface ge-0/0/4.0 


5. Enable RSVP on the interfaces and configure link-protection for interface ge-0/0/2.0. 


[edit protocols rsvp] 

user@P1# set interface ge-0/0/1.0 

user@P1# set interface ge-0/0/2.0 link-protection 
user@P1# set interface ge-0/0/3.0 

user@P1# set interface ge-0/0/4.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show protocols mpls, show protocols rsvp, and show routing-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@P1# show interfaces 
ge-0/0/1 { 
unit O { 
family inet { 
address 192.168.12.2/24- 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 192.168.27.2/24- 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 192.168.23.2/24- 
} 


family mpls; 


} 
ge-0/0/4 { 
unit O { 
family inet { 
address 192.168.25.2/24- 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 10.255.0.2/32; 


user@P1# show protocols ospf 

traffic-engineering; 

area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 
interface ge-0/0/4.0; 
interface 100.0; 


user@P1# show protocols mpls 
interface ge-0/0/1.0; 
interface ge-0/0/2.0 { 
srlg srlg-a; 
} 
interface ge-0/0/3.0; 
interface ge-0/0/4.0; 
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user@P1# show protocols rsvp 

interface ge-0/0/1.0; 

interface ge-0/0/2.0 { 
link-protection; 

} 

interface ge-0/0/3.0; 

interface ge-0/0/4.0; 


user@P1# show routing-options 
srig { 
srig-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 
Configuring Device P2 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure P2: 


1. Configure the device interfaces. 


[edit interfaces] 

user@P2# set ge-0/0/1 unit 0 family inet address 192.168.13.3/24 
user@P2# set ge-0/0/1 unit O family mpls 

user@P2# set ge-0/0/2 unit O family inet address 192.168.37.3/24 
user@P2# set ge-0/0/2 unit O family mpls 

user@P2# set ge-0/0/3 unit O family inet address 192.168.23.3/24 
user@P2# set ge-0/0/3 unit 0 family mpls 

user@P2# set loO unit 0 family inet address 10.255.0.3/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@P2# set traffic-engineering 

user@P2# set area 0.0.0.0 interface ge-0/0/1.0 
user@P2# set area 0.0.0.0 interface ge-0/0/2.0 
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user@P2# set area 0.0.0.0 interface ge-0/0/3.0 
user@P2# set area 0.0.0.0 interface lo0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
user@P2# set srlg srlg-a srlg-value 101 
user@P2# set srlg srlg-a srlg-cost 10 


4. Configure MPLS on the interfaces and associate the SRLG srlg-a with interface ge-0/0/2.0 for the 
P2>PE2 link. 


[edit protocols mpls] 

user@P2# set interface ge-0/0/1.0 
user@P2# set interface ge-0/0/2.0 srlg srlg-a 
user@P2# set interface ge-0/0/3.0 


5. Enable RSVP on the interfaces. 


[edit protocols rsvp] 

user@P2# set interface ge-0/0/1.0 
user@P2# set interface ge-0/0/2.0 
user@P2# set interface ge-0/0/3.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show protocols mpls, show protocols rsvp, and show routing-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@P2# show interfaces 
ge-0/0/1 { 
unit O { 
family inet { 
address 192.168.13.3/24, 
} 


family mpls; 


} 
ge-0/0/2 { 


unit O { 
family inet { 
address 192.168.37.3/24, 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 192.168.23.3/24, 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 10.255.0.3/32; 


user@P2# show protocols ospf 

traffic-engineering; 

area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 
interface 100.0; 


user@P2# show protocols mpls 
interface ge-0/0/1.0; 
interface ge-0/0/2.0 { 
srlg srlg-a; 
} 
interface ge-0/0/3.0; 
} 


user@P2# show protocols rsvp 
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interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@P2# show routing-options 


srg { 
srlg-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 
Configuring Device P3 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure P3: 


1. Configure the device interfaces. 


[edit interfaces] 

user@P3# set ge-0/0/1 unit O family inet address 192.168.14.4/24 
user@P3# set ge-0/0/1 unit O family mpls 

user@P3# set ge-0/0/2 unit O family inet address 192.168.45.4/24 
user@P3# set ge-0/0/2 unit 0 family mpls 

user@P3# set loO unit 0 family inet address 10.255.0.4/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@P3# set traffic-engineering 

user@P3# set area 0.0.0.0 interface ge-0/0/1.0 
user@P3# set area 0.0.0.0 interface ge-0/0/2.0 
user@P3# set area 0.0.0.0 interface lo0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
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user@P3# set srlg srlg-a srlg-value 101 
user@P3# set srlg srlg-a srlg-cost 10 


4. Configure MPLS on the interfaces. 


[edit protocols mpls] 
user@P3# set interface ge-0/0/1.0 
user@P3# set interface ge-0/0/2.0 


5. Enable RSVP on the interfaces. 


[edit protocols rsvp] 
user@P3# set interface ge-0/0/1.0 
user@P3# set interface ge-0/0/2.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show protocols mpls, show protocols rsvp, and show routing-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@P3# show interfaces 
interfaces { 
ge-0/0/1 { 
unit O { 
family inet { 
address 192.168.14.4/24, 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 192.168.45.4/24- 
} 


family mpls; 


lo0 { 
unit O { 
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family inet { 
address 10.255.0.4/32; 


user@P3# show protocols ospf 

traffic-engineering; 

area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface 100.0; 


user@P3# show protocols mpls 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 


user@P3# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 


user@P3# show routing-options 


srg { 
srlg-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 
Configuring Device P4 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure P4: 


1. Configure the device interfaces. 
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[edit interfaces] 

user@P4# set ge-0/0/1 unit 0 family inet address 192.168.45.5/24 
user@P4# set ge-0/0/1 unit 0 family mpls 

user@P4# set ge-0/0/2 unit O family inet address 192.168.56.5/24 
user@P4# set ge-0/0/2 unit O family mpls 

user@P4# set ge-0/0/3 unit O family inet address 192.168.25.5/24 
user@P4# set ge-0/0/3 unit O family mpls 

user@P4# set loO unit 0 family inet address 10.255.0.5/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@P4# set traffic-engineering 

user@P4# set area 0.0.0.0 interface ge-0/0/1.0 
user@P4# set area 0.0.0.0 interface ge-0/0/2.0 
user@P4# set area 0.0.0.0 interface ge-0/0/3.0 
user@P4# set area 0.0.0.0 interface lo0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
user@P4# set srlg srlg-a srlg-value 101 
user@P4# set srlg srlg-a srlg-cost 10 


4. Configure MPLS on the interfaces. 


[edit protocols mpls] 

user@P4# set interface ge-0/0/1.0 
user@P4# set interface ge-0/0/2.0 
user@P4# set interface ge-0/0/3.0 


5. Enable RSVP on the interfaces. 


[edit protocols rsvp] 

user@P4# set interface ge-0/0/1.0 
user@P4# set interface ge-0/0/2.0 
user@P4# set interface ge-0/0/3.0 


Results 
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From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show protocols mpls, show protocols rsvp, and show routing-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@P4# show interfaces 
ge-0/0/1 { 
unit O { 
family inet { 
address 192.168.45.5/24, 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 192.168.56.5/24- 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 192.168.25.5/24- 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 10.255.0.5/32; 


user@P4# show protocols ospf 

traffic-engineering; 

area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 
interface 100.0; 


user@P4# show protocols mpls 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@P4# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@P4# show routing-options 


srlg { 
srlg-a { 
srlg-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 
Configuring Device P5 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure P5: 


1. Configure the device interfaces. 


[edit interfaces] 

user@P5# set ge-0/0/1 unit O family inet address 192.168.56.6/24 
user@P5# set ge-0/0/1 unit 0 family mpls 

user@P5# set ge-0/0/2 unit O family inet address 192.168.67.6/24 
user@P5# set ge-0/0/2 unit O family mpls 

user@P5# set loO unit O family inet address 10.255.0.6/32 


2. Configure OSPF on the interfaces. 
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[edit protocols ospf] 

user@P5# set traffic-engineering 

user@P5# set area 0.0.0.0 interface ge-0/0/1.0 
user@P5# set area 0.0.0.0 interface ge-0/0/2.0 
user@P5# set area 0.0.0.0 interface lo0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
user@P5# set srlg srlg-a srlg-value 101 
user@P5# set srlg srlg-a srlg-cost 10 


4. Configure MPLS on the interfaces. 


[edit protocols mpls] 
user@P5# set interface ge-0/0/1.0 
user@P5# set interface ge-0/0/2.0 


5. Enable RSVP on the interfaces. 


[edit protocols rsvp] 
user@P5# set interface ge-0/0/1.0 
user@P5# set interface ge-0/0/2.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show protocols mpls, show protocols rsvp, and show routing-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@P5# show interfaces 
ge-0/0/1 { 
unit O { 
family inet { 
address 192.168.56.6/24- 
} 


family mpls; 


} 
ge-0/0/2 { 


unit O { 
family inet { 
address 192.168.67.6/24, 
} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 10.255.0.6/32; 


user@P5# show protocols ospf 

traffic-engineering; 

area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface 100.0; 


user@P5# show protocols mpls 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 


user@P5# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 


user@P5# show routing-options 
srlg { 
srig-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 
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Configuring Device PE2 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure PE2: 


1. Configure the device interfaces. 


[edit interfaces] 

user@PE2# set ge-0/0/1 unit O family inet address 192.168.27.7/24 
user@PE2# set ge-0/0/1 unit O family mpls 

user@PE2# set ge-0/0/2 unit O family inet address 192.168.37.7/24 
user@PE2# set ge-0/0/2 unit 0 family mpls 

user@PE2# set ge-0/0/3 unit O family inet address 192.168.67.7/24 
user@PE2# set ge-0/0/3 unit 0 family mpls 

user@PE2# set loO unit O family inet address 10.255.0.7/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@PE2# set traffic-engineering 

user@PE2# set area 0.0.0.0 interface ge-0/0/1.0 
user@PE2# set area 0.0.0.0 interface ge-0/0/2.0 
user@PE2# set area 0.0.0.0 interface ge-0/0/3.0 
user@PE2# set area 0.0.0.0 interface 1o0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
user@PE2# set srlg srlg-a srlg-value 101 
user@PE2# set srlg srlg-a srlg-cost 10 


4. Configure MPLS on the interfaces. 


[edit protocols mpls] 

user@PE2# set interface ge-0/0/1.0 
user@PE2# set interface ge-0/0/2.0 
user@PE2# set interface ge-0/0/3.0 


5. Enable RSVP on the interfaces. 
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[edit protocols rsvp] 

user@PE2# set interface ge-0/0/1.0 
user@PE2# set interface ge-0/0/2.0 
user@PE2# set interface ge-0/0/3.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show protocols mpls, show protocols rsvp, and show routing-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@PE2# show interfaces 
interfaces { 
ge-0/0/1 { 
unit O { 
family inet { 
address 192.168.27.7/24, 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 192.168.37.7/24; 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 192.168.67.7/24- 
} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 10.255.0.7/32; 
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user@PE2# show protocols ospf 

traffic-engineering; 

area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 
interface 100.0; 


user@PE2# show protocols mpls 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@PE2# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@PE2# show routing-options 


srig { 
srig-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 
Verification 

Confirm that the configuration is working properly. 

Verifying the SRLG Cost Is Added to the TE Link 


Purpose 


Verify that the SRLG cost is added to the TE link if it belongs to the SRLG of the protected link. Issue the 
show ted link detail and show rsvp session extensive bypass commands on device P1. 
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Action 


user@P1> show ted link detail 


10 255-0. 2-S192 1683 27.71, mocails 192.168.2752, iRemoces 0.0.0.0 
Local interface index: 0, Remote interface index: 0 


LocalPath: 0, Metric: 1, StaticBW: 1000Mbps, AvailBW: 1000Mbps 








Color: 0 <none> 
SRLGs: srlg-a 
localBW [0] Obps [1] Obps [2] Obps [3] Obps 
localBW [4] Obps [Si-Obps [6] Obps PISO bps 
Pace aa 
10. 255.4.0,3=S192 168.37 -.7=1, bocails 192.168.37,.3, Remoces 0.0.0.0 
Local interface index: 0, Remote interface index: 0 


LocalPath: 0, Metric: 1, StaticBW: 1000Mbps, AvailBW: 1000Mbps 








Color: 0 <none> 
SRLGs: srlg-a 
localBW [0] Obps [I MObps [2] Obps [3] Obps 
localBW [4] Obps [5] Obps [6] Obps [7] Obps 


user@P1> show rsvp session extensive bypass 


Ingress RSVP: 1 sessions 


10. 255.407 

From: 10.255.0.2, LSPstate: Up, ActiveRoute: 0 
LSPname: Bypass—>192.168.27.7 
LSPtype: Static Configured 





Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 299776 








Resv style: 1 SE, Label in: , Label out: 299776 
eT elec etertens =, Salm@ees wie, Oee 21 Isisil@ezil Zoli 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 52081 protocol 0 


Type: Bypass LSP 





Number of data route tunnel through: 1 
Number of RSVP session tunnel through: 0 
PATH revfrom: localclient 


Adspec: sent MTU 1500 
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Path MTU: received 1500 

PATH sentto: 192.168.25.5 (ge-0/0/4.0) 26 pkts 

RESV revfrom: 192.168.25.5 (ge-0/0/4.0) 26 pkts 

Dole womees IZ 168 25,5 192 163. 56,6 192,168.67 67 
Reece! moures <se@llie> LIZ L6Ss255,5 L216. 5G5,6 12. Osa st 
Total 1 displayed, Up 1, Down 0 








Meaning 

The shortest path for the bypass protecting the link P1->PE2 would have been P1->P2->PE2. Because 
the links P1>PE2 and P2>PE2 both belong to SRLG srlg-a, the SRLG cost of 10 for srlg-a is added to the 
metric for the link P2>PE2. This makes the metric for the link P2>PE2 too high to be selected for the 
shortest path. Therefore, the CSPF result for the computed path for the bypass becomes P1>P4>P5>PE2. 


Example: Configuring SRLG with Link Protection with the exclude-srlg Option 


IN THIS SECTION 


Requirements | 248 
Overview | 248 
Configuration | 249 


Verification | 273 


This example shows how to configure SRLG with link protection with the exclude-srlg option. 


Requirements 


This example uses the following hardware and software components: 


e M Series, MX Series, or T Series devices 


e Junos OS Release 11.4 or later running on all the devices 


Overview 


In this example, PE1 is the ingress router and PE2 is the egress router. P1, P2, and P3, P4, and P5 are 
transit routers. OSPF is configured on all the routers as the interior gateway protocol (IGP). SRLG is 
configured on all seven routers. The link P1>PE2 (primary path) and the link P2>PE2 belong to SRLG srlg-a. 


You configure link protection for the interface P1>PE2 by including the link-protection statement along 
with the exclude-srlg option. This makes the bypass LSP and the protected link completely disjoint in any 
SRLG. 
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When SRLG srlg-a is configured on the link P1>PE2 and P2>PE2, the link P2>PE2 is rejected for CSPF 
consideration due to the exclude-srlg configuration. Therefore, the computed path for the bypass becomes 
P1>P4>P5>PE2. 


Primary path 





——— Secondary path 


go40926 


Configuration 


CLI Quick Configuration 


To quickly configure this section of the example, copy the following commands, paste them into a text 
file, remove any line breaks, change any details necessary to match your network configuration, and then 
copy and paste the commands into the CLI at the [edit] hierarchy level. 


Router PE1 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.1/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.13.1/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 192.168.14.1/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.1/32 

set routing-options srlg srlg-a srlg-value 101 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 
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set protocols rsvp interface ge-0/0/3.0 

set protocols mpls optimize-timer 120 

set protocols mpls label-switched-path pe1-pe2 to 10.255.0.7 
set protocols mpls label-switched-path pe1-pe2 link-protection 
set protocols mpls label-switched-path pe1-pe2 primary via-p1 
set protocols mpls label-switched-path pe1-pe2 secondary path2 standby 
set protocols mpls path via-p1 10.255.0.2 strict 

set protocols mpls path path2 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/3.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Router P1 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.12.2/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.27.2/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 192.168.23.2/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces ge-0/0/4 unit 0 family inet address 192.168.25.2/24 
set interfaces ge-0/0/4 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.0.2/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 link-protection exclude-srlg 
set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 srlg srlg-a 

set protocols mpls interface ge-0/0/3.0 

set protocols mpls interface ge-0/0/4.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 
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set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 
set protocols ospf area 0.0.0.0 interface lo0.0 


Router P2 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.13.3/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.37.3/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 192.168.23.3/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.0.3/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols rsvp interface ge-0/0/3.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 srlg srlg-a 

set protocols mpls interface ge-0/0/3.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Router P3 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.14.4/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.45.4/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.4/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 
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set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 
set protocols ospf area 0.0.0.0 interface lo0.0 


Router P4 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.45.5/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.56.5/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 192.168.25.5/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.5/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols rsvp interface ge-0/0/3.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/3.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Router P5 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.56.6/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.67.6/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.6/32 
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set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 
set protocols ospf area 0.0.0.0 interface lo0.0 


Router PE2 


set interfaces ge-0/0/1 unit 0 family inet address 192.168.27.7/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 192.168.37.7/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 192.168.67.7/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.7/32 

set routing-options srlg srlg-a srlg-value 101 

set routing-options srlg srlg-a srlg-cost 10 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols rsvp interface ge-0/0/3.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/3.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 


Configuring Device PE1 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure the ingress router PE1: 


1. Configure the device interfaces. 


[edit interfaces] 

user@PE1# set ge-0/0/1 unit O family inet address 192.168.12.1/24 
user@PE1# set ge-0/0/1 unit 0 family mpls 

user@PE1# set ge-0/0/2 unit O family inet address 192.168.13.1/24 
user@PE1# set ge-0/0/2 unit O family mpls 

user@PE1# set ge-0/0/3 unit 0 family inet address 192.168.14.1/24 
user@PE1# set ge-0/0/3 unit 0 family mpls 

user@PE1# set loO unit O family inet address 10.255.0.1/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@PE1# set traffic-engineering 

user@PE1# set area 0.0.0.0 interface ge-0/0/1.0 
user@PE1# set area 0.0.0.0 interface ge-0/0/2.0 
user@PE1# set area 0.0.0.0 interface ge-0/0/3.0 
user@PE1# set area 0.0.0.0 interface 1o0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
user@PE1# set routing-options srlg srlg-a srlg-value 101 
user@PE1# set routing-options srlg srlg-a srlg-cost 10 


4. Configure MPLS and the LSPs and configure link protection for the pe1-pe2 LSP. 


[edit protocols mpls] 

user@PE1# set interface ge-0/0/1.0 

user@PE1# set interface ge-0/0/2.0 

user@PE1# set interface ge-0/0/3.0 

user@PE1# set optimize-timer 120 

user@PE1# set label-switched-path pe1-pe2 to 10.255.0.7 

user@PE1# set protocols mpls label-switched-path pe1-pe2 link-protection 
user@PE1# set label-switched-path pe1-pe2 primary via-p1 

user@PE1# set label-switched-path pe1-pe2 secondary path2 standby 
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user@PE1# set path via-p1 10.255.0.2 strict 
user@PE1# set path path2 


5. Enable RSVP on the interfaces. 


[edit protocols rsvp] 

user@PE1# set interface ge-0/0/1.0 
user@PE1# set interface ge-0/0/2.0 
user@PE1# set interface ge-0/0/3.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show routing-options, show protocols mpls, and show protocols rsvp commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@PE1# show interfaces 
ge-0/0/1 { 
unit O { 
family inet { 
address 192.168.12.1/24- 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 192.168.13.1/24; 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 192.168.14.1/24, 
} 


family mpls; 


loO { 
unit O { 
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family inet { 
address 10.255.0.1/32; 


user@PE1# show protocols ospf 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 
interface 100.0; 


user@PE1# show protocols mpls 
optimize-timer 120; 
label-switched-path pe1-pe2 { 

to 10.255.0.7; 

link-protection; 

primary via-p1; 

secondary path2 { 

standby; 


} 

path via-p1 { 
10.255.0.2 strict; 

} 

path path2; 

interface ge-0/0/1.0; 

interface ge-0/0/2.0; 

interface ge-0/0/3.0; 


user@PE1# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@PE1# show routing-options 
srig { 
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srlg-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 
Configuring Device P1 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure device P1: 


1. Configure the device interfaces. 


[edit interfaces] 

user@P1# set ge-0/0/1 unit 0 family inet address 192.168.12.2/24 
user@P1# set ge-0/0/1 unit 0 family mpls 

user@P1# set ge-0/0/2 unit O family inet address 192.168.27.2/24 
user@P1# set ge-0/0/2 unit O family mpls 

user@P1# set ge-0/0/3 unit O family inet address 192.168.23.2/24 
user@P1# set ge-0/0/3 unit O family mpls 

user@P1# set ge-0/0/4 unit O family inet address 192.168.25.2/24 
user@P1# set ge-0/0/4 unit O family mpls 

user@P1# set loO unit 0 family inet address 10.255.0.2/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@P1# set traffic-engineering 

user@P1# set area 0.0.0.0 interface ge-0/0/1.0 
user@P1# set area 0.0.0.0 interface ge-0/0/2.0 
user@P1# set area 0.0.0.0 interface ge-0/0/3.0 
user@P1# set area 0.0.0.0 interface ge-0/0/4.0 
user@P1# set area 0.0.0.0 interface lo0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
user@P1# set routing-options srlg srlg-a srlg-value 101 
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user@P1# set routing-options srlg srlg-a srig-cost 10 


4. Configure MPLS on the interfaces and associate the SRLG with interface ge-0/0/2.0 for the P1>PE2 
link. 


[edit protocols mpls] 

user@P1# set interface ge-0/0/1.0 
user@P1# set interface ge-0/0/2.0 srlg srlg-a 
user@P1# set interface ge-0/0/3.0 
user@P1# set interface ge-0/0/4.0 


5. Enable RSVP on the interfaces and include the link-protection statement with the exclude-srlg option 
for interface ge-0/0/2.0. 


[edit protocols rsvp] 

user@P1# set interface ge-0/0/1.0 

user@P1# set interface ge-0/0/2.0 link-protection exclude-srlg 
user@P1# set interface ge-0/0/3.0 

user@P1# set interface ge-0/0/4.0 


Results 

From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show protocols mpls, show protocols rsvp, and show routing-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@P1# show interfaces 
ge-0/0/1 { 
unit O { 
family inet { 
address 192.168.12.2/24. 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 192.168.27.2/24, 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 192.168.23.2/24- 
} 


family mpls; 


} 
ge-0/0/4 { 
unit O { 
family inet { 
address 192.168.25.2/24- 
} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 10.255.0.2/32; 


user@P1# show protocols ospf 

traffic-engineering; 

area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 
interface ge-0/0/4.0; 
interface 100.0; 


user@P1# show protocols mpls 
interface ge-0/0/1.0; 
interface ge-0/0/2.0 { 
srlg srlg-a; 
} 
interface ge-0/0/3.0; 
interface ge-0/0/4.0; 
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user@P1# show protocols rsvp 

interface ge-0/0/1.0; 

interface ge-0/0/2.0 { 
link-protection { 

exclude-srlg; 

} 

interface ge-0/0/3.0; 

interface ge-0/0/4.0; 

} 


user@P1# show routing-options 
srg { 
srlg-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 
Configuring Device P2 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure P2: 


1. Configure the device interfaces. 


[edit interfaces] 

user@P2# set ge-0/0/1 unit O family inet address 192.168.13.3/24 
user@P2# set ge-0/0/1 unit O family mpls 

user@P2# set ge-0/0/2 unit 0 family inet address 192.168.37.3/24 
user@P2# set ge-0/0/2 unit 0 family mpls 

user@P2# set ge-0/0/3 unit O family inet address 192.168.23.3/24 
user@P2# set ge-0/0/3 unit 0 family mpls 

user@P2# set loO unit 0 family inet address 10.255.0.3/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 
user@P2# set traffic-engineering 
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user@P2# set area 0.0.0.0 interface ge-0/0/1.0 
user@P2# set area 0.0.0.0 interface ge-0/0/2.0 
user@P2# set area 0.0.0.0 interface ge-0/0/3.0 
user@P2# set area 0.0.0.0 interface lo0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
user@P2# set routing-options srlg srlg-a srlg-value 101 
user@P2# set routing-options srlg srlg-a srlg-cost 10 


4. Configure MPLS on the interfaces and associate the SRLG with interface ge-0/0/2.0 for the P2>PE2 
link. 


[edit protocols mpls] 

user@P2# set interface ge-0/0/1.0 
user@P2# set interface ge-0/0/2.0 srlg srlg-a 
user@P2# set interface ge-0/0/3.0 


5. Enable RSVP on the interfaces. 


[edit protocols rsvp] 

user@P2# set interface ge-0/0/1.0 
user@P2# set interface ge-0/0/2.0 
user@P2# set interface ge-0/0/3.0 


Results 

From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show protocols mpls, show protocols rsvp, and show routing-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@P2# show interfaces 
ge-0/0/1 { 
unit O { 
family inet { 
address 192.168.13.3/24, 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 192.168.37.3/24, 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 192.168.23.3/24, 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 10.255.0.3/32; 


user@P2# show protocols ospf 

traffic-engineering; 

area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 
interface 100.0; 


user@P2# show protocols mpls 
interface ge-0/0/1.0; 
interface ge-0/0/2.0 { 
srlg srlg-a; 
} 
interface ge-0/0/3.0; 
} 
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user@P2# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@P2# show routing-options 


srlg { 
srlg-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 
Configuring Device P3 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure P3: 


1. Configure the device interfaces. 


[edit interfaces] 

user@P3# set ge-0/0/1 unit O family inet address 192.168.14.4/24 
user@P3# set ge-0/0/1 unit O family mpls 

user@P3# set ge-0/0/2 unit O family inet address 192.168.45.4/24 
user@P3# set ge-0/0/2 unit 0 family mpls 

user@P3# set loO unit 0 family inet address 10.255.0.4/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@P3# set traffic-engineering 

user@P3# set area 0.0.0.0 interface ge-0/0/1.0 
user@P3# set area 0.0.0.0 interface ge-0/0/2.0 
user@P3# set area 0.0.0.0 interface lo0.0 


3. Configure the SRLG definitions. 
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[edit routing-options] 


user@P3# set routing-options srlg srlg-a srlg-value 101 
user@P3# set routing-options srlg srlg-a srlg-cost 10 


4. Configure MPLS on the interfaces. 


[edit protocols mpls] 
user@P3# set interface ge-0/0/1.0 
user@P3# set interface ge-0/0/2.0 


5. Enable RSVP on the interfaces. 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show protocols mpls, show protocols rsvp, and show routing-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


[edit protocols rsvp] 
user@P3# set interface ge-0/0/1.0 
user@P3# set interface ge-0/0/2.0 


user@P3# show interfaces 


interfaces { 
ge-0/0/1 { 


} 


unit O { 
family inet { 
address 192.168.14.4/24- 
} 


family mpls; 


ge-0/0/2 { 


unit O { 
family inet { 
address 192.168.45.4/24- 
} 


family mpls; 


loO { 
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unit O { 
family inet { 
address 10.255.0.4/32; 


user@P3# show protocols ospf 

traffic-engineering; 

area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface 100.0; 


user@P3# show protocols mpls 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 


user@P3# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 


user@P3# show routing-options 
srlg { 
srlg-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 


Configuring Device P4 


Step-by-Step Procedure 
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The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure P4: 


1. Configure the device interfaces. 


[edit interfaces] 

user@P4# set ge-0/0/1 unit O family inet address 192.168.45.5/24 
user@P4# set ge-0/0/1 unit 0 family mpls 

user@P4# set ge-0/0/2 unit O family inet address 192.168.56.5/24 
user@P4# set ge-0/0/2 unit O family mpls 

user@P4# set ge-0/0/3 unit O family inet address 192.168.25.5/24 
user@P4# set ge-0/0/3 unit O family mpls 

user@P4# set loO unit 0 family inet address 10.255.0.5/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@P4# set traffic-engineering 

user@P4# set area 0.0.0.0 interface ge-0/0/1.0 
user@P4# set area 0.0.0.0 interface ge-0/0/2.0 
user@P4# set area 0.0.0.0 interface ge-0/0/3.0 
user@P4# set area 0.0.0.0 interface lo0.0 


3. Configure the SRLG definitions. 
[edit routing-options] 


user@P4# set routing-options srlg srlg-a srlg-value 101 
user@P4# set routing-options srlg srlg-a srig-cost 10 


4. Configure MPLS on the interfaces. 


[edit protocols mpls] 

user@P4# set interface ge-0/0/1.0 
user@P4# set interface ge-0/0/2.0 
user@P4# set interface ge-0/0/3.0 


5. Enable RSVP on the interfaces. 


[edit protocols rsvp] 
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Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show protocols mpls, show protocols rsvp, and show routing-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@P4# set interface ge-0/0/1.0 
user@P4# set interface ge-0/0/2.0 
user@P4# set interface ge-0/0/3.0 


user@P4# show interfaces 
ge-0/0/1 { 
unit O { 


} 


family inet { 
address 192.168.45.5/24, 
} 


family mpls; 


ge-0/0/2 { 
unit O { 


} 


family inet { 
address 192.168.56.5/24- 
} 


family mpls; 


ge-0/0/3 { 
unit O { 


} 
oO 


family inet { 
address 192.168.25.5/24- 
} 


family mpls; 


{ 


unit O { 


family inet { 
address 10.255.0.5/32; 
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user@P4# show protocols ospf 

traffic-engineering; 

area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 
interface 100.0; 


user@P4# show protocols mpls 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@P4# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@P4# show routing-options 
srlg { 
srig-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 
Configuring Device P5 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure P5: 


1. Configure the device interfaces. 
[edit interfaces] 


user@P5# set ge-0/0/1 unit O family inet address 192.168.56.6/24 
user@P5# set ge-0/0/1 unit O family mpls 
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user@P5# set ge-0/0/2 unit 0 family inet address 192.168.67.6/24 
user@P5# set ge-0/0/2 unit 0 family mpls 
user@P5# set loO unit O family inet address 10.255.0.6/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@P5# set traffic-engineering 

user@P5# set area 0.0.0.0 interface ge-0/0/1.0 
user@P5# set area 0.0.0.0 interface ge-0/0/2.0 
user@P5# set area 0.0.0.0 interface lo0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
user@P5# set routing-options srlg srlg-a srlg-value 101 
user@P5# set routing-options srlg srlg-a srilg-cost 10 


4. Configure MPLS on the interfaces. 


[edit protocols mpls] 
user@P5# set interface ge-0/0/1.0 
user@P5# set interface ge-0/0/2.0 


5. Enable RSVP on the interfaces. 


[edit protocols rsvp] 
user@P5# set interface ge-0/0/1.0 
user@P5# set interface ge-0/0/2.0 


Results 

From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show protocols mpls, show protocols rsvp, and show routing-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@P5# show interfaces 
ge-0/0/1 { 
unit O { 


family inet { 
address 192.168.56.6/24, 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 192.168.67.6/24- 
} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 10.255.0.6/32; 


user@P5# show protocols ospf 

traffic-engineering; 

area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface 100.0; 


user@P5# show protocols mpls 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 


user@P5# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 


user@P5# show routing-options 


srig { 
srig-a { 


270 


271 


srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 
Configuring Device PE2 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see the CLI User Guide. 


To configure PE2: 


1. Configure the device interfaces. 


[edit interfaces] 

user@PE2# set ge-0/0/1 unit O family inet address 192.168.27.7/24 
user@PE2# set ge-0/0/1 unit O family mpls 

user@PE2# set ge-0/0/2 unit O family inet address 192.168.37.7/24 
user@PE2# set ge-0/0/2 unit O family mpls 

user@PE2# set ge-0/0/3 unit 0 family inet address 192.168.67.7/24 
user@PE2# set ge-0/0/3 unit 0 family mpls 

user@PE2# set loO unit O family inet address 10.255.0.7/32 


2. Configure OSPF on the interfaces. 


[edit protocols ospf] 

user@PE2# set traffic-engineering 

user@PE2# set area 0.0.0.0 interface ge-0/0/1.0 
user@PE2# set area 0.0.0.0 interface ge-0/0/2.0 
user@PE2# set area 0.0.0.0 interface ge-0/0/3.0 
user@PE2# set area 0.0.0.0 interface 1o0.0 


3. Configure the SRLG definitions. 


[edit routing-options] 
user@PE2# set routing-options srlg srlg-a srlg-value 101 
user@PE2# set routing-options srlg srlg-a srlg-cost 10 


4. Configure MPLS on the interfaces. 
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[edit protocols mpls] 

user@PE2# set interface ge-0/0/1.0 
user@PE2# set interface ge-0/0/2.0 
user@PE2# set interface ge-0/0/3.0 


5. Enable RSVP on the interfaces. 


[edit protocols rsvp] 

user@PE2# set interface ge-0/0/1.0 
user@PE2# set interface ge-0/0/2.0 
user@PE2# set interface ge-0/0/3.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols 
ospf, show protocols mpls, show protocols rsvp, and show routing-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@PE2# show interfaces 
interfaces { 
ge-0/0/1 { 
unit O { 
family inet { 
address 192.168.27.7/24- 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 192.168.37.7/24, 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 192.168.67.7/24;, 
} 


family mpls; 
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} 
lo0 { 
unit O { 
family inet { 
address 10.255.0.7/32; 


user@PE2# show protocols ospf 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 
interface 100.0; 


user@PE2# show protocols mpls 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@PE2# show protocols rsvp 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


user@PE2# show routing-options 


srlg { 
srlg-a { 
srig-value 101; 
srlg-cost 10; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


Confirm that the configuration is working properly. 


Verifying the SRLG Cost Is Added to the TE Link 


Purpose 


Verify that the TE link is excluded if it belongs to the SRLG of the protected link when link-protection is 
configured with exclude-srlg. Issue the show ted link detail and show rsvp session extensive bypass 


commands on device P1. 


Action 


user@P1> show ted link detail 


10.2595 .0.2=F192, 168.276 7-1 





LocalPath: 0, Metric: 1, 
Color: O <none> 


SRLGs: srlg-a 





Local interface index: 0, Remote interface index: 
StaticBW: 1000Mbps, AvailBW: 


localBW [0] Obps eee) [2] Obps [3] Obps 
localBW [4] Obps [5] Obps [6] Obps [7] Obps 


as ell 
10.255 50 32192 168,57. 7=1 


Local interface index: 0 





LocalPath: 0, Metric: 1, 
Color: O <none> 


SRLGs: srlg-a 


, Local: 192.168.27.2, Remote: 


, loyeells 192 16S. 37/45, IReumionces 





, Remote interface index: 


StaticBW: 1000Mbps, AvailBW: 1 


localBW [0] Obps [1] Obps FlOloes: [3] Obps 
localBW [4] Obps [5] Obps [6] Obps [7] Obps 


user@P1> show rsvp session extensive bypass 


Ingress RSVP: 1 sessions 


10-2535 60. 7 


From: 10.255.0.2, LSPstate: Up, ActiveRoute: 0 


LSPname: Bypass—>192.168.27.7 
LSPtype: Static Configured 








Recovery label received: 


, Recovery label sent: 











Resv style: 1 SE, Label 


Time left: —, Since: 


ioe =, laloeil omes 2IO7V6 
mea Oe 2 WssilGeri 2Oii 


Suggested label received: -, Suggested label sent: 


0.0.0.0 
0 
1000Mbps 
0.0.0,0 
0 
OO0O0Mbps 
ANDI TG 
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[Tspec: rate Obps size Obps peak Infbps m 20 M 1500 


Port number: sender 1 receiver 52081 protocol 0 





Type: Bypass LSP 





Number of data route tunnel through: 1 
Number of RSVP session tunnel through: 0 
PATH rcevfrom: localclient 
Adspec: sent MTU 1500 
Path MTU: received 1500 
PATH sentto: 192.168.25.5 (ge-0/0/4.0) 63 pkts 
RESV revfrom: 192.168.25.5 (ge-0/0/4.0) 63 pkts 
ipgoler wowees 192,168.25.5 192 .168.56.6 192,168.67 .7 
Recoil mounes <sellie> LIZ 163.2555 IZ 168.5656 192. os a7 4 t 
Total 1 displayed, Up 1, Down 0 








Meaning 


The shortest path for the bypass protecting the link P1>PE2 would have been P1>P2>PE2. Because the 
links P1>PE2 and P2>PE2 both belong to SRLG srlg-a, the link P2>PE2 is rejected for CSPF consideration 
due to the exclude-srlg constraint. Therefore, the computed path for the bypass becomes P1>P4>P5>PE2. 
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MPLS and Traffic Protection 


Typically, when an LSP fails, the router immediately upstream from the failure signals the outage to the 
ingress router. The ingress router calculates a new path to the egress router, establishes the new LSP, and 
then directs the traffic from the failed path to the new path. This rerouting process can be time-consuming 
and prone to failure. For example, the outage signals to the ingress router might get lost, or the new path 
might take too long to come up, resulting in significant packet drops. The Junos OS provides several 
complementary mechanisms for protecting against LSP failures: 


Standby secondary paths—You can configure primary and secondary paths. You configure secondary 


paths with the standby statement. To activate traffic protection, you need to configure these standby 
paths only on the ingress router. If the primary path fails, the ingress router immediately reroutes traffic 
from the failed path to the standby path, thereby eliminating the need to calculate a new route and 
signal a new path. For information about configuring standby LSPs, see “Configuring Hot Standby of 
Secondary Paths for LSPs” on page 573. 


Fast reroute—You configure fast reroute on an LSP to minimize the effect of a failure in the LSP. Fast 
reroute enables a router upstream from the failure to route around the failure quickly to the router 
downstream of the failure. The upstream router then signals the outage to the ingress router, thereby 
maintaining connectivity before a new LSP is established. For a detailed overview of fast reroute, see 
“Fast Reroute Overview” on page 472. For information about configuring fast reroute, see “Configuring 
Fast Reroute” on page 474. 


Link protection—You can configure link protection to help ensure that traffic traversing a specific interface 
from one router to another can continue to reach its destination in the event that this interface fails. 
When link protection is configured for an interface and configured for an LSP that traverses this interface, 
a bypass LSP is created that handles this traffic if the interface fails. The bypass LSP uses a different 
interface and path to reach the same destination. For information about configuring link protection, see 
“Configuring Link Protection on Interfaces Used by LSPs” on page 377. 


When standby secondary path, and fast reroute or link protection are configured on an LSP, full traffic 
protection is enabled. When a failure occurs in an LSP, the router upstream from the failure routes traffic 
around the failure and notifies the ingress router of the failure. This rerouting keeps the traffic flowing 
while waiting for the notification to be processed at the ingress router. After receiving the failure notification, 
the ingress router immediately reroutes the traffic from the patched primary path to the more optimal 
standby path. 


Fast reroute and link protection provide a similar type of traffic protection. Both features provide a quick 
transfer service and employ a similar design. Fast reroute and link protection are both described in RFC 4090, 
Fast Reroute Extensions to RSVP-TE for LSP Tunnels. However, you need to configure only one or the other. 
Although you can configure both, there is little, if any, benefit in doing so. 
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Node-Link Protection Overview 


Node-link protection (many-to-one or facility backup) extends the capabilities of link protection and 
provides slightly different protection from fast reroute. While link protection is useful for selecting an 
alternate path to the same router when a specific link fails, and fast reroute protects interfaces or nodes 
along the entire path of an LSP, node-link protection establishes a bypass path that avoids a particular 
node in the LSP path. 


When you enable node-link protection for an LSP, you must also enable link protection on all RSVP 
interfaces in the path. Once enabled, the following types of bypass paths are established: 


e Next-hop bypass LSP—Provides an alternate route for an LSP to reach a neighboring router. This type 
of bypass path is established when you enable either node-link protection or link protection. 


e Next-next-hop bypass LSP—Provides an alternate route for an LSP through a neighboring router en 
route to the destination router. This type of bypass path is established exclusively when node-link 
protection is configured. 


Figure 11 on page 278 illustrates the example MPLS network topology used in this topic. The example 
network uses OSPF as the interior gateway protocol (IGP) and a policy to create traffic. 


Figure 11: Node-Link Protection 
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The MPLS network in Figure 11 on page 278 illustrates a router-only network that consists of unidirectional 
LSPs between R1 and RS, (Isp2-r1-to-r5) and between R6 and RO (Isp1-r6-to-r0). Both LSPs have strict 
paths configured that go through interface fe-0/1/0. 
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In the network shown in Figure 11 on page 278, both types of bypass paths are preestablished around the 
protected node (R2). A next-hop bypass path avoids interface fe-0/1/0 by going through R7, and a 
next-next-hop bypass path avoids R2 altogether by going through R7 and R9 to R4. Both bypass paths 
are shared by all protected LSPs traversing the failed link or node (many LSPs protected by one bypass 
path). 
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Node-link protection (many-to-one or facility backup) allows a router immediately upstream from a node 
failure to use an alternate node to forward traffic to its downstream neighbor. This is accomplished by 
preestablishing a bypass path that is shared by all protected LSPs traversing the failed link. 


When an outage occurs, the router immediately upstream from the outage switches protected traffic to 
the bypass node, and then signals the failure to the ingress router. Like fast reroute, node-link protection 
provides local repair, restoring connectivity faster than the ingress router can establish a standby secondary 
path or signal a new primary LSP. 


Node-link protection is appropriate in the following situations: 


e Protection of the downstream link and node is required. 
e The number of LSPs to be protected is large. 
e Satisfying path selection criteria (priority, bandwidth, and link coloring) for bypass paths is less critical. 


e Control at the granularity of individual LSPs is not required. 


Path Protection Overview 


The main advantages of path protection are control over where the traffic goes after a failure and minimum 
packet loss when combined with fast reroute (one-to-one backup or link protection). Path protection is 
the configuration, within a label-switched path (LSP), of two types of paths: a primary path, used in normal 
operations, and a secondary path used when the primary fails, as shown in Figure 12 on page 279. 


In Figure 12 on page 279, an MPLS network consisting of eight routers has a primary path between R1 and 
R5 which is protected by the secondary path between R1 and R5. When a failure is detected, such as an 
interface down event, an Resource Reservation Protocol (RSVP) error message is sent to the ingress router 
which switches traffic to the secondary path, maintaining traffic flow. 


Figure 12: Path Protection 
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If the secondary path is pre-signaled or on standby, recovery time from a failure is faster than if the 
secondary path is not pre-signaled. When the secondary path is not pre-signaled a call-setup delay occurs 
during which the new physical path for the LSP is established, extending the recovery time. If the failure 
in the primary path is corrected, and after a few minutes of hold time, the ingress router switches traffic 
back from the secondary path to the primary path. 


Because path protection is provided by the ingress router for the entire path, there can be some 
disadvantages, for example, double-booking of resources and unnecessary protection of links. By protecting 
a single resource at a time, local protection can remedy these disadvantages. 


Configuring Path Protection in an MPLS Network (CLI Procedure) 


The Junos OS implementation of MPLS on EX Series switches provides path protection as a mechanism 
for protecting against label switched path (LSP) failures. Path protection reduces the time required to 
recalculate a route in case of a failure within the MPLS tunnel. You configure path protection on the ingress 
provider edge switch in your MPLS network. You do not configure the egress provider edge switch or the 
provider switches for path protection. You can explicitly specify which provider switches are used for the 
primary and secondary paths, or you can let the software calculate the paths automatically. 


Before you configure path protection, be sure you have: 


e Configured an ingress provider edge switch and an egress provider edge switch. See “Configuring MPLS 
on Provider Edge Switches Using IP-Over-MPLS” on page 68 or “Configuring MPLS on Provider Edge 
EX8200 and EX4500 Switches Using Circuit Cross-Connect” on page 74. 


e Configured at least one provider (transit) switch. See “Configuring MPLS on EX8200 and EX4500 Provider 
Switches” on page 78. 


e Verified the configuration of your MPLS network. 
To configure path protection, complete the following tasks on the ingress provider edge switch: 


1, Configuring the Primary Path | 281 
2. Configuring the Secondary Path | 283 
3. Configuring the Revert Timer | 283 
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Configuring the Primary Path 
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The primary statement creates the primary path, which is the LSP’s preferred path. The secondary statement 
creates an alternative path if the primary path can no longer reach the egress provider edge switch. 


In the tasks described in this topic, the Isp-name has already been configured on the ingress provider 
edge switch as Isp_to_240 and the loopback interface address on the remote provider edge switch has 
already been configured as 127.0.0.8. 


When the software switches from the primary to the secondary path, it continuously attempts to revert 
to the primary path, switching back to it when it is again reachable but no sooner than the retry time 
specified in the revert-timer statement. 


You can configure zero primary paths or one primary path. If you do not configure a primary path, the first 
secondary path (if a secondary path has been configured) is selected as the path. If you do not specify any 
named paths, or if the path that you specify is empty, the software makes all routing decisions necessary 
for the packets to reach the egress provider edge switch. 


To configure a primary path: 


1. Create the primary path for the LSP: 


[edit protocols mpls label-switched-path lsp_to_240 to 127.0.0.8] 
user@switch# set primary primary_path_Isp_to_240 


2. Configure an explicit route for the primary path by specifying the IP address of the loopback interface 
or the switch IP address or hostname of each switch used in the MPLS tunnel. You can specify the link 
types as either strict or loose in each path statement. If the link type is strict, the LSP must go to the 
next address specified in the path statement without traversing other switches. If the link type is loose, 
the LSP can traverse through other switches before reaching this switch. This configuration uses the 
default strict designation for the paths. 


NOTE: You can enable path protection without specifying which provider switches are used. 
If you do not list the specific provider switches to be used for the MPLS tunnel, the switch 
calculates the route. 


TIP: Do not include the ingress provider edge switch in these statements. List the IP address 
of the loopback interface or switch address or hostname of all other switch hops in sequence, 
ending with the egress provider edge switch. 





[edit protocols mpls label-switched-path lsp_to_240 to 127.0.0.8] 
user@switch# set path primary_path_Isp_to_240 127.0.0.2 
user@switch# set path primary_path_Isp_to_240 127.0.0.3 
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user@switch# set path primary_path_Isp_to_240 127.0.0.8 


Configuring the Secondary Path 


You can configure zero or more secondary paths. All secondary paths are equal, and the software tries 
them in the order that they are listed in the configuration. The software does not attempt to switch among 
secondary paths. If the first secondary path in the configuration is not available, the next one is tried, as 
so on. To create a set of equal paths, specify secondary paths without specifying a primary path. If you do 
not specify any named paths, or if the path that you specify is empty, the software makes all routing 
decisions necessary to reach the egress provider edge switch. 


To configure the secondary path: 


1. Create a secondary path for the LSP: 


[edit protocols mpls label-switched-path lsp_to_240 to 127.0.0.8] 





user@switch# set secondary secondary_path_Isp_to_240 standby 


2. Configure an explicit route for the secondary path by specifying the IP address of the loopback interface 
or the switch IP address or hostname of each switch used in the MPLS tunnel. You can specify the link 
types as either strict or loose in each path statement. This configuration uses the default strict 
designation for the paths. 


TIP: Do not include the ingress provider edge switch in these statements. List the IP address 
of the loopback interface or switch address or hostname of all other switch hops in sequence, 
ending with the egress provider edge switch. 


[edit protocols mpls label-switched-path lsp_to_240 to 127.0.0.8] 





user@switch# set path secondary_path_Isp_to_240 127.0.0.4 
user@switch# set path primary_path_Isp_to_240 127.0.0.8 


Configuring the Revert Timer 


For LSPs configured with both primary and secondary paths, you can optionally configure a revert timer. 
If the primary path goes down and traffic is switched to the secondary path, the revert timer specifies the 
amount of time (in seconds) that the LSP must wait before it can revert traffic back to the primary path. 
If the primary path experiences any connectivity problems or stability problems during this time, the timer 
is restarted. 


TIP: If you do not explicitly configure the revert timer, it is set by default to 60 seconds. 
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To configure the revert timer for LSPs configured with primary and secondary paths: 


e For all LSPs on the switch: 


[edit protocols mpls] 


user@switch# setrevert-timer 120 


e For aspecific LSP on the switch: 


[edit protocols mpls label-switched-path] 





user@switch# setIlsp_to_240 revert-timer 120 


Preventing Use of a Path That Previously Failed 


If you configure an alternate path through the network in case the active path fails, you may not want 
traffic to revert back to the failed path, even if it is no longer failing. When you configure a primary path, 
the traffic switches over to the secondary path during a failure, and reverts back to the primary path when 
it returns. 


At times, switching traffic back to a primary path that has previously failed may not be a particularly sound 
idea. In this case, only configure secondary paths, resulting in the next configured secondary path 
establishing when the first secondary path fails. Later, if the first secondary path becomes operational, the 
Junos OS will not revert to it, but will continue using the second secondary path. 


Configuring MPLS Inter-AS Link-Node Protection with Labeled BGP 


IN THIS SECTION 


@ Understanding MPLS Inter-AS Link Protection | 284 
@ Example: Configuring MPLS Inter-AS Link-Node Protection | 286 


Understanding MPLS Inter-AS Link Protection 


Link protection is essential in an MPLS network to ensure traffic restoration in case of an interface failure. 
The ingress router chooses an alternate link through another interface to send traffic to its destination. 


In Figure 13 on page 285, autonomous system border routers (ASBRs) run external BGP (EBGP) to ASBRs 
in another autonomous system (AS) to exchange labels for /32 IPv4 routes. Inside the ASs, internal BGP 
(IBGP) propagates the routes to provider edge (PE) devices. If the link from Device ASBR3 to Device ASBR1 
goes down, until Device ASBR3 reinstalls the new next hop, all traffic going toward AS 64510 from AS 
64511 through the ASBR3-ASBR1 link is dropped. A fast traffic restoration can be achieved if Device 
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ASBR3 preprograms a backup path either through Device ASBR4 or through a direct path to Device ASBR2 
if one exists (not shown in the diagram). This assumes that Device ASBR3 learns a loop-free MPLS path 
for routes that need to protected either through IBGP or EBGP. 


This solution does not handle a failure on Device ASBR3 for traffic going toward AS 64511 from AS 64510 
through the ASBR3-ASBR1 link. This solution is limited to downstream inter-AS link-node protection with 
labeled BGP. This solution does not support service restoration between provider (P) and ASBR routers 

when there is an ASBR failure. For example, this solution does not handle a failure on the P3-ASBR3 link. 


This supported functionality is similar to BGP multipath, except only one next hop is used for active 
forwarding, and a second path is in protected mode. 


Figure 13: MPLS Inter-AS Link-Node Protection Conceptual Topology 
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In an MPLS inter-AS environment, link protection can be enabled when labeled-unicast is used to send 
traffic between ASs. Hence, MPLS inter-AS link protection is configured on the link between two routers 
in different ASs. 


To configure link protection on an interface, use the protection statement at the [edit protocols bgp group 
group-name family inet labeled-unicast] hierarchy level: 


protocols { 


bgp { 
group test1 { 


type external; 
local-address 192.168.1.2; 
family inet { 
labeled-unicast { 
protection; 


NOTE: MPLS inter-AS link protection is supported only with labeled-unicast and external peers 
in a master routing instance. 


The link on which protection is configured is known as the protection path. A protection path is selected 
only after the best path selection and is not selected in the following cases: 


e The best path is a non-BGP path. 


e Multiple next hops are active, as in BGP multipath. 


SEE ALSO 


Example: Configuring MPLS Inter-AS Link-Node Protection | 286 


Example: Configuring MPLS Inter-AS Link-Node Protection 


IN THIS SECTION 


Requirements | 286 
Overview | 287 
Configuration | 288 


Verification | 300 


This example shows how to configure tail-end protection in an inter-AS deployment with Layer 3 VPNs. 


Requirements 


No special configuration beyond device initialization is required before configuring this example. 
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Overview 


In Figure 14 on page 287. autonomous system border routers (ASBRs) run external BGP (EBGP) to ASBRs 
in another autonomous system (AS) to exchange labels for /32 IPv4 routes. Inside the ASs, internal BGP 
(IBGP) propagates the routes to provider edge (PE) devices. 


If the link from Device ASBR3 to Device ASBR1 goes down, until ASBR3 reinstalls the new next hop, all 
traffic going toward AS 64510 from AS 64511 through the ASBR3-ASBR1 link is dropped. 


This example shows how to achieve fast traffic restoration by configuring Device ASBR3 to preprogram 
a backup path through Device ASBR2. 


NOTE: This solution does not handle the Device P3 to Device ASBR3 failure. Nor does it handle 
a failure on Device ASBR3 for traffic going toward AS 645111 from AS 64510 through the 
ASBR3-ASBR1 link. This traffic is dropped. 


Figure 14: MPLS Inter-AS Link-Node Protection Example Topology 
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Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


Device ASBR1 


set interfaces fe-1/2/2 unit 0 family inet address 20.20.20.2/30 

set interfaces fe-1/2/2 unit 0 family mpls 

set interfaces fe-1/2/0 unit O family inet address 21.21.21.1/30 

set interfaces fe-1/2/0 unit O family mpls 

set interfaces loO unit O family inet address 4.4.4.4/32 

set protocols rsvp interface fe-1/2/2.0 

set protocols rsvp interface lo0.0 

set protocols mpls traffic-engineering bgp-igp-both-ribs 

set protocols mpls label-switched-path To_PE1 to 2.2.2.2 

set protocols mpls interface fe-1/2/2.0 

set protocols mpls interface fe-1/2/0.0 

set protocols mpls interface lo0.0 

set protocols bgp group To-PE1 type internal 

set protocols bgp group To-PE1 local-address 4.4.4.4 

set protocols bgp group To-PE1 family inet unicast 

set protocols bgp group To-PE1 family inet labeled-unicast 

set protocols bgp group To-PE1 export next-hop-self 

set protocols bgp group To-PE1 neighbor 2.2.2.2 family inet labeled-unicast 
set protocols bgp group To-ASBR3 type external 

set protocols bgp group To-ASBR3 family inet labeled-unicast 

set protocols bgp group To-ASBR3 export To-ASBR3 

set protocols bgp group To-ASBR3 neighbor 21.21.21.2 peer-as 64511 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set policy-options policy-statement To-ASBR3 term 1 from route-filter 2.2.2.2/32 exact 
set policy-options policy-statement To-ASBR3 term 1 then accept 

set policy-options policy-statement To-ASBR3 term 2 then reject 

set policy-options policy-statement next-hop-self then next-hop self 
set routing-options autonomous-system 64510 


Device ASBR2 
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set interfaces fe-1/2/0 unit 0 description to-P2 

set interfaces fe-1/2/0 unit O family inet address 25.25.25.1/30 

set interfaces fe-1/2/0 unit O family mpls 

set interfaces fe-1/2/1 unit O description to-ASBR3 

set interfaces fe-1/2/1 unit O family inet address 26.26.26.1/30 

set interfaces fe-1/2/1 unit 0 family mpls 

set interfaces loO unit O family inet address 9.9.9.9/32 

set protocols rsvp interface fe-1/2/0.0 

set protocols rsvp interface lo0.0 

set protocols mpls traffic-engineering bgp-igp-both-ribs 

set protocols mpls label-switched-path To_PE1 to 2.2.2.2 

set protocols mpls interface fe-1/2/0.0 

set protocols mpls interface fe-1/2/1.0 

set protocols mpls interface lo0.0 

set protocols bgp group To-PE1 type internal 

set protocols bgp group To-PE1 local-address 9.9.9.9 

set protocols bgp group To-PE1 family inet unicast 

set protocols bgp group To-PE1 family inet labeled-unicast 

set protocols bgp group To-PE1 export next-hop-self 

set protocols bgp group To-PE1 neighbor 2.2.2.2 family inet labeled-unicast 
set protocols bgp group To-ASBR3 type external 

set protocols bgp group To-ASBR3 family inet labeled-unicast 

set protocols bgp group To-ASBR3 export To-ASBR3 

set protocols bgp group To-ASBR3 neighbor 26.26.26.2 peer-as 64511 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set policy-options policy-statement To-ASBR3 term 1 from route-filter 2.2.2.2/32 exact 
set policy-options policy-statement To-ASBR3 term 1 then accept 
set policy-options policy-statement To-ASBR3 term 2 then reject 
set policy-options policy-statement next-hop-self then next-hop self 
set routing-options autonomous-system 64510 


Device ASBR3 


set interfaces fe-1/2/0 unit 0 description to-ASBR1 

set interfaces fe-1/2/0 unit 0 family inet address 21.21.21.2/30 
set interfaces fe-1/2/0 unit O family mpls 

set interfaces fe-1/2/2 unit O description to-P3 

set interfaces fe-1/2/2 unit 0 family inet address 22.22.22.1/30 


set interfaces fe-1/2/2 unit 0 family mpls 

set interfaces fe-1/2/1 unit O description to-ASBR2 

set interfaces fe-1/2/1 unit 0 family inet address 26.26.26.2/30 

set interfaces fe-1/2/1 unit 0 family mpls 

set interfaces loO unit O family inet address 5.5.5.5/32 

set protocols rsvp interface fe-1/2/2.0 

set protocols rsvp interface lo0.0 

set protocols rsvp interface fe-1/2/0.0 

set protocols rsvp interface fe-1/2/1.0 

set protocols mpls traffic-engineering bgp-igp-both-ribs 

set protocols mpls label-switched-path To_PE2 to 7.7.7.7 

set protocols mpls interface lo0.0 

set protocols mpls interface fe-1/2/0.0 

set protocols mpls interface fe-1/2/2.0 

set protocols mpls interface fe-1/2/1.0 

set protocols bgp group To-PE2 type internal 

set protocols bgp group To-PE2 local-address 5.5.5.5 

set protocols bgp group To-PE2 family inet unicast 

set protocols bgp group To-PE2 export next-hop-self 

set protocols bgp group To-PE2 neighbor 7.7.7.7 family inet labeled-unicast 
set protocols bgp group To-ASBR1 type external 

set protocols bgp group To-ASBR1 family inet labeled-unicast protection 
set protocols bgp group To-ASBR1 family inet labeled-unicast per-prefix-label 
set protocols bgp group To-ASBR1 export To-ASBR1 

set protocols bgp group To-ASBR1 neighbor 21.21.21.1 peer-as 64510 

set protocols bgp group To-ASBR2 type external 

set protocols bgp group To-ASBR2 family inet labeled-unicast protection 
set protocols bgp group To-ASBR2 family inet labeled-unicast per-prefix-label 
set protocols bgp group To-ASBR2 export To-ASBR2 

set protocols bgp group To-ASBR2 neighbor 26.26.26.1 peer-as 64510 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 

set policy-options policy-statement To-ASBR1 term 1 from route-filter 7.7.7.7/32 exact 
set policy-options policy-statement To-ASBR1 term 1 then accept 

set policy-options policy-statement To-ASBR1 term 2 then reject 

set policy-options policy-statement To-ASBR2 term 1 from route-filter 7.7.7.7/32 exact 
set policy-options policy-statement To-ASBR2 term 1 then accept 

set policy-options policy-statement To-ASBR2 term 2 then reject 

set policy-options policy-statement next-hop-self then next-hop self 

set routing-options autonomous-system 64511 
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Device CE1 


set interfaces fe-1/2/0 unit O family inet address 18.18.18.1/30 
set interfaces loO unit O family inet address 1.1.1.1/32 

set protocols ospf area 0.0.0.2 interface fe-1/2/0.0 

set protocols ospf area 0.0.0.2 interface lo0.0 passive 


Device CE2 


set interfaces fe-1/2/1 unit O family inet address 24.24.24.2/30 

set interfaces loO unit O family inet address 8.8.8.8/32 

set protocols bgp group To_PE2 neighbor 24.24.24.1 export myroutes 
set protocols bgp group To_PE2 neighbor 24.24.24.1 peer-as 64511 
set policy-options policy-statement myroutes from protocol direct 
set policy-options policy-statement myroutes then accept 

set routing-options autonomous-system 64509 


Device P1 


set interfaces fe-1/2/1 unit 0 family inet address 19.19.19.2/30 
set interfaces fe-1/2/1 unit 0 family mpls 

set interfaces fe-1/2/2 unit 0 family inet address 20.20.20.1/30 
set interfaces fe-1/2/2 unit 0 family mpls 

set interfaces loO unit O family inet address 3.3.3.3/32 

set protocols rsvp interface fe-1/2/1.0 

set protocols rsvp interface fe-1/2/2.0 

set protocols rsvp interface lo0.0 

set protocols mpls interface fe-1/2/1.0 

set protocols mpls interface fe-1/2/2.0 

set protocols mpls interface lo0.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 

set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 


Device P2 
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set interfaces fe-1/2/0 unit 0 description to-ASBR2 

set interfaces fe-1/2/0 unit 0 family inet address 25.25.25.2/30 
set interfaces fe-1/2/0 unit O family mpls 

set interfaces fe-1/2/2 unit O description to-PE1 

set interfaces fe-1/2/2 unit 0 family inet address 28.28.28.1/30 
set interfaces fe-1/2/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.10.10.10/32 

set protocols rsvp interface fe-1/2/0.0 

set protocols rsvp interface fe-1/2/2.0 

set protocols rsvp interface lo0.0 

set protocols mpls interface fe-1/2/0.0 

set protocols mpls interface fe-1/2/2.0 

set protocols mpls interface lo0.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 


Device P3 


set interfaces fe-1/2/2 unit O family inet address 22.22.22.2/30 
set interfaces fe-1/2/2 unit 0 family mpls 

set interfaces fe-1/2/0 unit 0 family inet address 23.23.23.1/30 
set interfaces fe-1/2/0 unit O family mpls 

set interfaces loO unit O family inet address 6.6.6.6/32 

set protocols rsvp interface fe-1/2/2.0 

set protocols rsvp interface fe-1/2/0.0 

set protocols rsvp interface lo0.0 

set protocols mpls interface fe-1/2/2.0 

set protocols mpls interface fe-1/2/0.0 

set protocols mpls interface lo0.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 

set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 


Device PE1 


set interfaces fe-1/2/0 unit O family inet address 18.18.18.2/30 

set interfaces fe-1/2/1 unit O family inet address 19.19.19.1/30 

set interfaces fe-1/2/1 unit 0 family mpls 

set interfaces fe-1/2/2 unit O description to-P2 

set interfaces fe-1/2/2 unit 0 family inet address 28.28.28.2/30 

set interfaces loO unit O family inet address 2.2.2.2/32 

set protocols rsvp interface fe-1/2/0.0 

set protocols rsvp interface lo0.0 

set protocols rsvp interface fe-1/2/2.0 

set protocols mpls label-switched-path To-ASBR1 to 4.4.4.4 

set protocols mpls label-switched-path To-ASBR2 to 9.9.9.9 

set protocols mpls interface fe-1/2/0.0 

set protocols mpls interface lo0.0 

set protocols mpls interface fe-1/2/2.0 

set protocols bgp group To_ASBR1 type internal 

set protocols bgp group To_ASBR1 local-address 2.2.2.2 

set protocols bgp group To_ASBR1 family inet labeled-unicast 

set protocols bgp group To_ASBR1 neighbor 4.4.4.4 family inet labeled-unicast resolve-vpn 
set protocols bgp group To_PE2 type external 

set protocols bgp group To_PE2 multihop ttl 20 

set protocols bgp group To_PE2 local-address 2.2.2.2 

set protocols bgp group To_PE2 family inet-vpn unicast 

set protocols bgp group To_PE2 neighbor 7.7.7.7 peer-as 64511 

set protocols bgp group To_ASBR2 type internal 

set protocols bgp group To_ASBR2 local-address 2.2.2.2 

set protocols bgp group To_ASBR2 family inet labeled-unicast 

set protocols bgp group To_ASBR2 neighbor 9.9.9.9 family inet labeled-unicast resolve-vpn 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface fe-1/2/2.0 

set policy-options policy-statement bgp-to-ospf term 1 from protocol bgp 
set policy-options policy-statement bgp-to-ospf term 1 then accept 

set policy-options policy-statement bgp-to-ospf term 2 then reject 

set policy-options policy-statement vpnexport term 1 from protocol ospf 
set policy-options policy-statement vpnexport term 1 then community add test_comm 
set policy-options policy-statement vpnexport term 1 then accept 

set policy-options policy-statement vpnexport term 2 then reject 

set policy-options policy-statement vpnimport term 1 from protocol bgp 
set policy-options policy-statement vpnimport term 1 from community test_comm 
set policy-options policy-statement vpnimport term 1 then accept 

set policy-options policy-statement vpnimport term 2 then reject 
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set policy-options community test_comm members target:1:64510 

set routing-instances vpn2CE1 instance-type vrf 

set routing-instances vpn2CE1 interface fe-1/2/0.0 

set routing-instances vpn2CE1 route-distinguisher 1:64510 

set routing-instances vpn2CE1 vrf-import vpnimport 

set routing-instances vpn2CE1 vrf-export vpnexport 

set routing-instances vpn2CE1 protocols ospf export bgp-to-ospf 

set routing-instances vpn2CE1 protocols ospf area 0.0.0.2 interface fe-1/2/0.0 
set routing-options autonomous-system 64510 


Device PE2 


set interfaces fe-1/2/0 unit 0 family inet address 23.23.23.2/30 

set interfaces fe-1/2/0 unit O family mpls 

set interfaces fe-1/2/1 unit 0 family inet address 24.24.24.1/30 

set interfaces loO unit O family inet address 7.7.7.7/32 

set protocols rsvp interface fe-1/2/0.0 

set protocols rsvp interface lo0.0 

set protocols mpls label-switched-path To-ASBR3 to 5.5.5.5 

set protocols mpls interface fe-1/2/0.0 

set protocols mpls interface lo0.0 

set protocols bgp group To_ASBR3 type internal 

set protocols bgp group To_ASBR3 local-address 7.7.7.7 

set protocols bgp group To_ASBR3 family inet labeled-unicast 

set protocols bgp group To_ASBR3 neighbor 5.5.5.5 family inet labeled-unicast resolve-vpn 
set protocols bgp group To_PE1 type external 

set protocols bgp group To_PE1 multihop ttl 20 

set protocols bgp group To_PE1 local-address 7.7.7.7 

set protocols bgp group To_PE1 family inet-vpn unicast 

set protocols bgp group To_PE1 neighbor 2.2.2.2 peer-as 64510 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface fe-1/2/0.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set policy-options policy-statement vpnexport term 1 from protocol bgp 

set policy-options policy-statement vpnexport term 1 then community add test_comm 
set policy-options policy-statement vpnexport term 1 then accept 

set policy-options policy-statement vpnexport term 2 then reject 

set policy-options policy-statement vpnimport term 1 from protocol bgp 

set policy-options policy-statement vpnimport term 1 from community test_comm 
set policy-options policy-statement vpnimport term 1 then accept 
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set policy-options policy-statement vpnimport term 2 then reject 

set policy-options community test_comm members target:1:64510 

set routing-instances vpn2CE2 instance-type vrf 

set routing-instances vpn2CE2 interface fe-1/2/1.0 

set routing-instances vpn2CE2 route-distinguisher 1:64510 

set routing-instances vpn2CE2 vrf-import vpnimport 

set routing-instances vpn2CE2 vrf-export vpnexport 

set routing-instances vpn2CE2 protocols bgp group To_CE2 peer-as 64509 

set routing-instances vpn2CE2 protocols bgp group To_CE2 neighbor 24.24.24.2 
set routing-options autonomous-system 64511 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure the EBGP scenario: 


1. Configure the router interfaces. 


[edit interfaces] 

user@ASBR3# set fe-1/2/0 unit O description to-ASBR1 
user@ASBR3# set fe-1/2/0 unit O family inet address 21.21.21.2/30 
user@ASBR3# set fe-1/2/0 unit 0 family mpls 

user@ASBR3# set fe-1/2/2 unit 0 description to-P3 

user@ASBR3# set fe-1/2/2 unit O family inet address 22.22.22.1/30 
user@ASBR3# set fe-1/2/2 unit 0 family mpls 

user@ASBR3# set fe-1/2/1 unit O description to-ASBR2 
user@ASBR3# set fe-1/2/1 unit 0 family inet address 26.26.26.2/30 
user@ASBR3# set fe-1/2/1 unit 0 family mpls 

user@ASBR3# set loO unit O family inet address 5.5.5.5/32 


2. Configure an interior gateway protocol (IGP), such as OSPF or IS-IS. 


[edit protocols ospf] 

user@ASBR3# set traffic-engineering 
[edit protocols ospf area 0.0.0.0] 
user@ASBR3# set interface fe-1/2/2.0 
user@ASBR3# set interface lo0.0 passive 
user@ASBR3# set interface fe-1/2/1.0 


296 


3. Configure the autonomous system (AS) number. 


[edit routing-options] 
user@ASBR3# set autonomous-system 64511 


4. Configure the routing policy. 


[edit policy-options policy-statement To-ASBR1] 
user@ASBR3# set term 1 from route-filter 7.7.7.7/32 exact 
user@ASBR3# set term 1 then accept 

user@ASBR3# set term 2 then reject 

[edit policy-options policy-statement To-ASBR2] 
user@ASBR3# set term 1 from route-filter 7.7.7.7/32 exact 
user@ASBR3# set term 1 then accept 

user@ASBR3# set term 2 then reject 

[edit policy-options policy-statement next-hop-self] 
user@ASBR3# set then next-hop self 


5. Configure the EBGP sessions. 


[edit protocols bgp group To-ASBR1] 

user@ASBR3# set type external 

user@ASBR3# set family inet labeled-unicast protection 
user@ASBR3# set family inet labeled-unicast per-prefix-label 
user@ASBR3# set export To-ASBR1 

user@ASBR3# set neighbor 21.21.21.1 peer-as 64510 

[edit protocols bgp group To-ASBR2] 

user@ASBR3# set type external 

user@ASBR3# set family inet labeled-unicast protection 
user@ASBR3# set family inet labeled-unicast per-prefix-label 
user@ASBR3# set export To-ASBR2 

user@ASBR3# set neighbor 26.26.26.1 peer-as 64510 


6. Configure the IBGP sessions. 


[edit protocols bgp group To-PE2] 

user@ASBR3# set type internal 

user@ASBR3# set local-address 5.5.5.5 

user@ASBR3# set family inet unicast 

user@ASBR3# set export next-hop-self 

user@ASBR3# set neighbor 7.7.7.7 family inet labeled-unicast 


7. Configure MPLS. 


[edit protocols mpls] 

user@ASBR3# set traffic-engineering bgp-igp-both-ribs 
user@ASBR3# set label-switched-path To_PE2 to 7.7.7.7 
user@ASBR3# set interface lo0.0 

user@ASBR3# set interface fe-1/2/0.0 

user@ASBR3# set interface fe-1/2/2.0 

user@ASBR3# set interface fe-1/2/1.0 


8. Configure a signaling protocol. 


[edit protocols rsvp] 

user@ASBR3# set interface fe-1/2/2.0 
user@ASBR3# set interface lo0.0 
user@ASBR3# set interface fe-1/2/0.0 
user@ASBR3# set interface fe-1/2/1.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
show policy-options, and show routing-options, commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


user@ASBR3# show interfaces 
fe-1/2/0 { 
unit O { 
description to-ASBR1; 
family inet { 
address 21.21.21.2/30; 
} 


family mpls; 


} 
fe-1/2/1 { 
unit O { 
description to-ASBR2; 
family inet { 
address 26.26.26.2/30; 
} 


family mpls; 
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fe-1/2/2 { 
unit O { 
description to-P3; 
family inet { 
address 22.22.22.1/30; 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 5.5.5.5/32; 


user@ASBR3# show protocols 
rsvp { 
interface fe-1/2/2.0, 
interface 100.0; 
interface fe-1/2/0.0; 
interface fe-1/2/1.0, 
} 
mpls { 
traffic-engineering bgp-igp-both-ribs; 
label-switched-path To_PE2 { 
to 7.7.7.7; 
} 
interface 100.0; 
interface fe-1/2/0.0; 
interface fe-1/2/2.0, 
interface fe-1/2/1.0; 
} 
bgp { 
group To-PE2 { 
type internal; 
local-address 5.5.5.5; 
family inet { 
unicast; 
} 
export next-hop-self; 
neighbor 7.7.7.7 { 
family inet { 
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labeled-unicast; 


} 
group To-ASBR1 { 
type external; 
family inet { 
labeled-unicast { 
protection; 


} 

export To-ASBR1; 

neighbor 21.21.21.1 { 
peer-as 64510; 


} 
group To-ASBR2 { 
type external; 
family inet { 
labeled-unicast { 
protection; 


} 

export To-ASBR2; 

neighbor 26.26.26.1 { 
peer-as 64510; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface fe-1/2/2.0; 
interface 100.0 { 
passive; 
} 
interface fe-1/2/1.0; 


user@ASBR3# show policy-options 
policy-statement To-ASBR1 { 
term 1 { 
from { 
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route-filter 7.7.7.7/32 exact; 
} 
then accept; 
} 
term 2 { 
then reject; 


} 
policy-statement To-ASBR2 { 
term 1 { 
from { 
route-filter 7.7.7.7/32 exact; 
} 
then accept; 
} 
term 2 { 
then reject; 


} 


policy-statement next-hop-self { 
then { 
next-hop self; 


user@ASBR3# show routing-options 
autonomous-system 64511; 


If you are done configuring the devices, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


@ = Checking the BGP Neighbor Sessions | 300 
@ ~~ Checking the Routes | 303 


Confirm that the configuration is working properly. 


Checking the BGP Neighbor Sessions 


Purpose 


300 
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Verify that BGP protection is enabled. 


Action 


user@ASBR3# show bgp neighbor 21.21.21.1 


Ree~eg 21 Zl pA slr S329) NS OS) moeeils 21,21 Ao Arik yy) INS alsyil i 





Type: External State: Established Flags: <ImportEval Sync> 














Last State: OpenConfirm Last Event: RecvKeepAliv 


ast Error: None 











Epgoowies || MWO-ASIRUL || 
Options: <Preference AddressFamily PeerAS Refresh> 


Options: <Protection> 





Address families configured: inet-labeled-unicast 

Holdtime: 90 Preference: 170 

NLRI configured with protection: inet-labeled-unicast 

Number of flaps: 0 

Peer ID: 4.4.4.4 ileal IDS 39.559 Active Holdtime: 90 
Keepalive Interval: 30 Group index: 4 Peer index: 0 

BFD: disabled, down 

Local Interface: fe-1/2/0.0 





NLRI for restart configured on peer: inet-labeled-unicast 


NLRI advertised by peer: inet-labeled-unicast 





NLRI for this session: inet-labeled-unicast 
Peer supports Refresh capability (2) 

Stale routes from peer are kept for: 300 

Peer does not support Restarter functionality 


NLRI that restart is negotiated for: inet-labeled-unicast 





NLRI of received end-of-rib markers: inet-—labeled-unicast 








NLRI of all end-of-rib markers sent: inet-—labeled-unicast 





Peer supports 4 byte AS extension (peer-as 64510) 





Peer does not support Addpath 
Table inet.0 Bit: 10001 

RIB State: BGP restart is complete 
Send state: in sync 
Active prefixes: 


Received prefixes: 





Accepted prefixes: 


Suppressed due to damping: 


PF OrR FN 


Advertised prefixes: 





Last traffic (seconds): Received 7 Sent 20 Checked 32 
Input messages: Total 170 Updates 2 Refreshes 0 Octets 3326 
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Output messages: Total 167 Updates 1 Refreshes 0 Octets 3288 


Output Queue[0]: 0 


user@ASBR3# show bgp neighbor 26.26.26.1 


PEER 26.20.26. InHolO72 INS GHSIN0 ineecls 26.26.2052: 7s) NS) GAS ili 
Type: External State: Established Flags: <ImportEval Sync> 
Last State: OpenConfirm Last Event: RecvKeepAliv 








ast Error: None 











Eegoor~es || MorASIBIR || 


Options: <Preference AddressFamily PeerAS Refresh> 





Options: <Protection> 





Address families configured: inet-labeled-unicast 


























Holdtime: 90 Preference: 170 
NLRI configured with protection: inet-labeled-unicast 
Number of flaps: 0 
Voor De 9.9.9.9 iocal 1D, 5.5.5.5 Active Holdtime: 90 
Keepalive Interval: 30 Group index: 5 Peer index: 0 
BFD: disabled, down 
Local Interface: fe-1/2/1.0 
NLRI for restart configured on peer: inet-labeled-unicast 
NLRI advertised by peer: inet-labeled-unicast 
NLRI for this session: inet-labeled-unicast 
Peer supports Refresh capability (2) 
Stale routes from peer are kept for: 300 
Peer does not support Restarter functionality 
NLRI that restart is negotiated for: inet-labeled-unicast 
NLRI of received end-of-rib markers: inet-labeled-unicast 
NLRI of all end-of-rib markers sent: inet-labeled-unicast 
Peer supports 4 byte AS extension (peer-as 64510) 
Peer does not support Addpath 
Table inet.0 Bit: 10002 
RIB State: BGP restart is complete 
Send state: in sync 
Active prefixes: al 
Received prefixes: al 
Accepted prefixes: il 
Suppressed due to damping: 0 
Advertised prefixes: dL 
Last traffic (seconds): Received 21 Sent 9 Checked 42 
Input messages: Total 170 Updates 2 Refreshes 0 Octets 3326 
Output messages: Total 168 Updates 1 Refreshes 0 Octets 3307 





Output Queue[0]: 0 
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Meaning 


The output shows that the Protection option is enabled for the EBGP peers, Device ASBR1 and Device 
ASBR2. 


This is also shown with the NLRI configured with protection: inet-labeled-unicast screen output. 


Checking the Routes 


Purpose 


Make sure that the backup path is installed in the routing table. 


Action 


user@ASBR3> show route 2.2.2.2 








inet.0: 12 destinations, 14 routes (12 active, 0 holddown, O hidden) 
+ = Active Route, Last Active, * = Both 
2 Dp Dc Bif BE “PXES/L7O]) Olesos25, Min) 2, jbewalhoresie i100) 





AS path: 64510 I, validation-state: unverified 
> to 21.21.21.1 via fe-1/2/0.0, Push 299824 

to 26.26.26.1 via fe-1/2/1.0, Push 299808 
[SGP AO) Oilssi632 5) MEDEZ e ocallprer sO) 

AS path: 64510 I, validation-state: unverified 
2 Om Z6rAGmZ6n baveloueko = 27 lenO pe Push 29981018 











Meaning 


The show route command displays active as well as backup paths to Device PE1. 


SEE ALSO 


Understanding MPLS Inter-AS Link Protection | 284 
Example: Preventing BGP Session Resets 


Examples: Configuring BGP Flap Damping 
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Configuring Egress Protection Service Mirroring for BGP Signaled Layer 2 Services 


Starting in Junos OS Release 14.2, Junos OS supports the restoration of egress traffic when there is a link 
or node failure in the egress PE node. If there is a link or node failure in the core network, a protection 
mechanism such as MPLS fast reroute can be triggered on the transport LSPs between the PE routers to 
repair the connection within tens of milliseconds. An egress protection LSP addresses the problem of a 
node-link failure at the edge of the network (for example, a failure of a PE router). 


Figure 1 shows a simplified topology of the use case that explains this feature. 


Figure 15: Egress Protection LSP Configured from Router PE1 to Router PE2 


100.0 10.255.183.58 
Pp 


o ¢ 
G 


CE 1 CE2 
192.0.2.4 100.0 10.255.183.61 192.0.2.3 


@ 


PE? P 
100.0 10.255.183.57 


042264 


<— Traffic direction 


CE1 is multihomed to PE1 and PE2. There are two paths connecting CE1 and CE2. The working path is 
CE2-PE3-P-PE1-CE1, via pseudowire PW21. The protecting path is CE2-PE3-P-PE2-CE1, via pseudowire 
PW 22 Traffic is flowing through the working path under normal circumstances. When the end-to-end 
OAM between CE1 and CE2 detects failure on the working path, traffic will be switched from the working 
path to the protecting path. The end-to-end failure detection and recovery relies on control plane hence 
should be relatively slow. To achieve faster protection, local repair mechanisms similar to those used by 
MPLS fast reroute should be used. In Figure 1 above, if link or node failed in the core network (like link 
failure on P-PE1, P-PE3, or node failure on P), the MPLS fast reroute will happen on the transport LSPs 
between PE1 and PES. The failure could be locally repaired within tens of milliseconds. However, if link 
or node failure happens at the edge (like link failure on PE3-CE2 or node failure on PE3), there is no local 
repair currently so we have to rely on the CE1-CE2 end-to-end protection to repair the failure. 


e Device CE2—Traffic origin 

e Router PES—Ingress PE router 

e Router PE1— (Primary) Egress PE router 
e Router PE2—Protector PE router 


e Device CE1—Traffic destination 
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When the link between CE1- PE1 goes downs, PE1 will briefly redirect that traffic towards CE1, to PE2. 
PE2 forwards it to CE1 until ingress router PE3 recalculates to forward the traffic to PE2. 


Initially the traffic direction was; CE2 - PES - P - PE1 - CE1. 


When the link between CE1- PE1 goes down, the traffic will be; CE2 - PE3 - P - PE1 - PE2 -CE1. PE3 
then recalculates the path; CE2 - PE3 - P - PE2 - CE1. 


1. Configure RSVP on PE1, PE2, and PE3. 


[edit protocols] 

user@PE1# set interface all 
user@PE2# set interface all 
user@PE3# set interface all 


2. Configure MPLS. 


[edit protocols mpls] 

user@PE1# set interface all 
user@PE2# set interface all 
user@PE3# set interface all 


3. Set PE1 as primary and PE2 as protector nodes. 


[edit protocols mpls] 
user@PE1# set egress-protection context-identifier address primary 
user@PE2# set egress-protection context-identifier address protector 


4. Enable egress-protection on PE1 and PE2. 


[edit protocols bgp] 
user@PE1# set group ibgp family I2vpn egress-protection 
user@PE2# set group ibgp family I2vpn egress-protection 


5. Configure LDP and ISIS on PE1, PE2, and PE3. 


[edit protocols Idp] 

user@PE1# set interface all 
user@PE2# set interface all 
user@PE3# set interface all 
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[edit protocols isis] 

user@PE11# set interface all point-to-point 
user@PE2# set interface all point-to-point 
user@PE3# set interface all point-to-point 


6. Configure a load balancing policy at PE1, PE2, and PE3. 


[edit] 

user@PE1# set policy-options policy-statement Ib then load-balance per-packet 
user@PE2# set policy-options policy-statement Ib then load-balance per-packet 
user@PE3# set policy-options policy-statement Ib then load-balance per-packet 


7. Configure the routing options at PE1, PE2, and PE3, to export routes based on the load balancing policy. 


[edit] 

user@PE1# set routing-options traceoptions file ro.log 
user@PE1# set routing-options traceoptions flag normal 
user@PE1# set routing-options traceoptions flag route 
user@PE1# set routing-options autonomous-system 100 
user@PE1# set routing-options forwarding-table export Ib 


[edit] 

user@PE2# set routing-options traceoptions file ro.log 
user@PE2# set routing-options traceoptions flag normal 
user@PE2# set routing-options traceoptions flag route 
user@PE2# set routing-options autonomous-system 100 
user@PE2# set routing-options forwarding-table export Ib 


[edit] 

user@PE3# set routing-options traceoptions file ro.log 
user@PE3# set routing-options traceoptions flag normal 
user@PE3# set routing-options traceoptions flag route 
user@PE3# set routing-options autonomous-system 100 
user@PE3# set routing-options forwarding-table export Ib 


8. Configure BGP at PE1 to advertise nrli from the routing instance with context-ID as next-hop. 


[edit] 
user@PE1# set routing-instances foo egress-protection context-identifier context-identifier 


9. Configure I2vpn at PE1, PE2, and PE3 


At PE1: 


[edit routing-instances] 
foo { 
instance-type |2vpn; 
egress-protection { 
context-identifier { 
198.51.100.0; 


} 
interface ge-2/0/2.0; 
route-distinguisher 10.255.183.58:1; 
vrf-target target:9000:1; 
protocols { 
I2vpn { 
encapsulation-type ethernet-vian; 
site foo { 
site-identifier 1; 
multi-homing; 
site-preference primary; 
interface ge-2/0/2.0 { 
remote-site-id 2; 


At PE2: 


[edit routing-instances] 
foo { 
instance-type |2vpn; 
egress-protection { 
protector; 
} 
interface ge-2/0/2.0; 
route-distinguisher 10.255.183.57:1; 
vrf-target target:9000:1; 
protocols { 
I2vpn { 
encapsulation-type ethernet-vlan; 
site foo{ 
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site-identifier 1; 
multi-homing; 
site-preference backup; 
interface ge-2/0/2.0 { 
remote-site-id 2; 


At PE3: 


[edit routing-instances] 
foo { 
instance-type |2vpn; 
interface ge-2/1/2.0; 
route-distinguisher 10.255.183.61:1; 
vrf-target target:9000:1; 
protocols { 
I2vpn { 
encapsulation-type ethernet-vlan; 
site foo { 
site-identifier 2; 
interface ge-2/1/2.0; 


Example: Configuring MPLS Egress Protection Service Mirroring for BGP Signaled Layer 2 


Services 
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Starting in Junos OS Release 14.2, Junos OS supports the restoration of egress traffic when there is a link 
or node failure in the egress PE node. If there is a link or node failure in the core network, a protection 
mechanism such as MPLS fast reroute can be triggered on the transport LSPs between the PE routers to 
repair the connection within tens of milliseconds. An egress protection LSP addresses the problem of a 
node-link failure at the edge of the network (for example, a failure of a PE router). 


This example shows how to configure link protection for BGP signaled Layer 2 services. 


Requirements 


MX Series Routers running Junos OS Release 14.2 or later. 


Overview 


If there is a link or node failure in the core network, a protection mechanism such as MPLS fast reroute 
can be triggered on the transport LSPs between the PE routers to repair the connection within tens of 
milliseconds. An egress protection LSP addresses the problem of a node-link failure at the edge of the 
network (for example, a failure of a PE router). 


This example includes the following configuration concepts and statements that are unique to the 
configuration of an egress protection LSP: 


context-identifier—Specifies an IPv4 or IPv6 address used to define the pair of PE routers participating 
in the egress protection LSP. It is assigned to each ordered pair of primary PE and the protector to 
facilitate protection establishment. This address is globally unique, or unique in the address space of the 
network where the primary PE and the protector reside. 


egress-protection—Configures the protector information for the protected Layer 2 circuit and configures 
the protector Layer 2 circuit at the [edit protocols mpls] hierarchy level. Configures an LSP as an egress 
protection LSP at the [edit protocols mpls] hierarchy level. 


protector—Configures the creation of standby pseudowires on the backup PE for link or node protection 
for the instance. 
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Figure 16: Egress Protection LSP Configured from Router PE1 to Router PE2 
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<—_ Traffic direction 


In the event of a failure of the egress PE Router PE1, traffic is switched to the egress protection LSP 
configured between Router PE1 and Router PE2 (the protector PE router): 


e Device CE2—Traffic origin 

e Router PE3—Ingress PE router 

e Router PE1— (Primary) Egress PE router 
e Router PE2—Protector PE router 

e Device CE1—Traffic destination 


When the link between CE1- PE1 goes downs, PE1 will briefly redirect that traffic toward CE1, to PE2. 
PE2 forwards it to CE1 until ingress router PE3 recalculates to forward the traffic to PE2. 


Initially the traffic direction was: CE2 - PE3 - P - PE1 - CE1. 


When the link between CE1- PE1 goes down, the traffic will be: CE2 - PE3 - P - PE1 - PE2 -CE1. PE3 
then recalculates the path: CE2 - PE3 - P - PE2 - CE1. 


This example shows how to configure routers PE1, PE2, and PE3. 


Configuration 


IN THIS SECTION 


@ Step-by-Step Procedure | 313 
@ Results | 319 


CLI Quick Configuration 
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To quickly configure an egress protection LSP, copy the following commands, paste them into a text file, 
remove any line breaks, change any details necessary to match your network configurations, copy and 
then paste the commands into the CLI and enter commit from configuration mode. 


PE1 


set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols mpls egress-protection context-identifier 198.51.100.3 primary 
set protocols mpls egress-protection context-identifier 198.51.100.3 advertise-mode stub-alias 
set protocols mpls egress-protection traceoptions file ep size 100m 

set protocols mpls egress-protection traceoptions flag all 

set protocols bgp traceoptions file bgp.log world-readable 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp local-address 10.255.183.58 

set protocols bgp group ibgp family inet unicast 

set protocols bgp group ibgp family I2vpn signaling egress-protection 

set protocols bgp group ibgp neighbor 192.0.2.3 

set protocols bgp group ibgp neighbor 192.0.2.4 

set protocols isis traceoptions file isis-edge size 10m world-readable 

set protocols isis traceoptions flag error 

set protocols isis level 1 disable 

set protocols isis level 2 wide-metrics-only 

set protocols isis interface all point-to-point 

set protocols isis interface all level 2 metric 10 

set protocols isis interface fxp0.0 disable 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set policy-options policy-statement Ib then load-balance per-packet 

set routing-options traceoptions file ro.log 

set routing-options traceoptions flag all 

set routing-options traceoptions flag route 

set routing-options autonomous-system 100 

set routing-options forwarding-table export Ib 

set routing-instances foo instance-type I2vpn 

set routing-instances foo egress-protection context-identifier 198.51.100.3 
set routing-instances foo interface ge-2/0/2.0 

set routing-instances foo route-distinguisher 10.255.183.58:1 

set routing-instances foo vrf-target target:9000:1 

set routing-instances foo protocols I2vpn encapsulation-type ethernet-vian 
set routing-instances foo protocols |2vpn site foo site-identifier 1 

set routing-instances foo protocols |2vpn site foo site-preference primary 
set routing-instances foo protocols |2vpn site foo interface ge-2/0/2.0 remote-site-id 2 


PE2 


PE3 


set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols mpls egress-protection context-identifier 198.51.100.3 protector 
set protocols mpls egress-protection context-identifier 198.51.100.3 advertise-mode stub-alias 
set protocols mpls egress-protection traceoptions file ep size 100m 

set protocols mpls egress-protection traceoptions flag all 

set protocols bgp traceoptions file bgp.log world-readable 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp local-address 10.255.183.57 

set protocols bgp group ibgp family inet unicast 

set protocols bgp group ibgp family I2vpn signaling egress-protection 

set protocols bgp group ibgp neighbor 192.0.2.3 

set protocols bgp group ibgp neighbor 192.0.2.4 

set protocols isis traceoptions file isis-edge size 10m world-readable 

set protocols isis traceoptions flag error 

set protocols isis level 1 disable 

set protocols isis level 2 wide-metrics-only 

set protocols isis interface all point-to-point 

set protocols isis interface all level 2 metric 10 

set protocols isis interface fxp0.0 disable 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set policy-options policy-statement Ib then load-balance per-packet 

set routing-options traceoptions file ro.log 

set routing-options traceoptions flag normal 

set routing-options traceoptions flag route 

set routing-options autonomous-system 100 

set routing-options forwarding-table export Ib 

set routing-instances foo instance-type I2vpn 

set routing-instances foo egress-protection protector 

set routing-instances foo interface ge-2/0/2.0 

set routing-instances foo route-distinguisher 10.255.183.57:1 

set routing-instances foo vrf-target target:9000:1 

set routing-instances foo protocols I2vpn encapsulation-type ethernet-vian 
set routing-instances foo protocols I2vpn site foo hot-standby 

set routing-instances foo protocols I2vpn site foo site-identifier 1 

set routing-instances foo protocols I2vpn site foo site-preference backup 
set routing-instances foo protocols |2vpn site foo interface ge-2/0/2.0 remote-site-id 2 
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set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp traceoptions file bgp.log world-readable 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp local-address 10.255.183.61 

set protocols bgp group ibgp family inet unicast 

set protocols bgp group ibgp family I2vpn signaling 

set protocols bgp group ibgp neighbor 192.0.2.3 

set protocols bgp group ibgp neighbor 192.0.2.4 

set protocols isis traceoptions file isis-edge size 10m world-readable 
set protocols isis traceoptions flag error 

set protocols isis level 1 disable 

set protocols isis level 2 wide-metrics-only 

set protocols isis interface all point-to-point 

set protocols isis interface all level 2 metric 10 

set protocols isis interface fxp0.0 disable 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set policy-options policy-statement Ib then load-balance per-packet 
set routing-options traceoptions file ro.log 

set routing-options traceoptions flag normal 

set routing-options traceoptions flag route 

set routing-options autonomous-system 100 

set routing-options forwarding-table export Ib 

set routing-instances foo instance-type I2vpn 

set routing-instances foo interface ge-2/1/2.0 

set routing-instances foo route-distinguisher 10.255.183.61:1 

set routing-instances foo vrf-target target:9000:1 

set routing-instances foo protocols I2vpn encapsulation-type ethernet-vian 
set routing-instances foo protocols I2vpn site foo site-identifier 2 
set routing-instances foo protocols |2vpn site foo interface ge-2/1/2.0 remote-site-id 1 


Step-by-Step Procedure 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode. 


To configure an egress protection LSP for router PE1: 


1. Configure RSVP. 


[edit protocols rsvp] 
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user@PE1# set interface all 
user@PE1# set interface fxp0.0 disable 


2. Configure MPLS to use the egress protection LSP to protect against a link failure to Device CE1. 


[edit protocols mpls] 

user@PE1# set interface all 

user@PE1# set interface fxp0.0 disable 

user@PE1# set egress-protection context-identifier 198.51.100.3 primary 

user@PE1# set egress-protection context-identifier 198.51.100.3 advertise-mode stub-alias 
user@PE1# set egress-protection traceoptions file ep size 100m 

user@PE1# set egress-protection traceoptions flag all 


3. Configure BGP. 


[edit protocols bgp] 

user@PE1# set traceoptions file bgp.log world-readable 
user@PE1# set group ibgp type internal 

user@PE1# set group ibgp local-address 10.255.183.58 
user@PE1# set group ibgp family inet unicast 

user@PE1# set group ibgp family I2vpn signaling egress-protection 
user@PE1# set group ibgp neighbor 192.0.2.3 

user@PE1# set group ibgp neighbor 192.0.2.4 


4. Configure IS-IS. 


[edit protocols isis] 

user@PE1# set traceoptions file isis-edge size 10m world-readable 
user@PE1# set traceoptions flag error 

user@PE1# set level 1 disable 

user@PE1# set level 2 wide-metrics-only 

user@PE11# set interface all point-to-point 

user@PE1# set interface all level 2 metric 10 

user@PE1# set interface fxp0.0 disable 


5. Configure LDP. 


[edit protocols Idp] 
user@PE1# set interface all 
user@PE1# set interface fxp0.0 disable 
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6. Configure a load-balancing policy. 


[edit] 
user@PE1# set policy-options policy-statement Ib then load-balance per-packet 


7. Configure the routing options to export routes based on the load-balancing policy. 


[edit routing-options] 

user@PE1# set traceoptions file ro.log 
user@PE1# set traceoptions flag all 
user@PE1# set autonomous-system 100 
user@PE1# set forwarding-table export Ib 


8. Configure BGP to advertise nrli from the routing instance with context-ID as next-hop. 


[edit routing-instances] 

user@PE1# set foo instance-type I2vpn 

user@PE1# set foo egress-protection context-identifier 198.51.100.3 
user@PE1# set foo interface ge-2/0/2.0 

user@PE1# set foo route-distinguisher 10.255.183.58:1 

user@PE1# set foo vrf-target target:9000:1 


9. Configure I2vpn instance to use the egress LSP configured. 


[edit routing-instances] 

user@PE1# set foo protocols I2vpn encapsulation-type ethernet-vlan 

user@PE1# set foo protocols I2vpn site foo site-identifier 1 

user@PE1# set foo protocols I2vpn site foo site-preference primary 

user@PE1# set foo protocols I2vpn site foo interface ge-2/0/2.0 remote-site-id 2 


10. If you are done configuring the device, enter commit from configuration mode. 


Step-by-Step Procedure 


To configure an egress protection LSP for Router PE2: 


1. Configure RSVP. 


[edit protocols rsvp] 
user@PE2# set interface all 
user@PE2# set interface fxp0.0 disable 
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2. Configure MPLS and the LSP that acts as the egress protection LSP. 


[edit protocols mpls] 

user@PE2# set interface all 

user@PE2# set interface fxp0.0 disable 

user@PE2# set egress-protection context-identifier 198.51.100.3 protector 

user@PE2# set egress-protection context-identifier 198.51.100.3 advertise-mode stub-alias 
user@PE2# set egress-protection traceoptions file ep size 100m 

user@PE2# set egress-protection traceoptions flag all 


3. Configure BGP. 


[edit protocols bgp] 

user@PE2# set traceoptions file bgp.log world-readable 
user@PE2# set group ibgp type internal 

user@PE2# set group ibgp local-address 10.255.183.57 
user@PE2# set group ibgp family inet unicast 

user@PE2# set group ibgp family I2vpn signaling 
user@PE2# set group ibgp family I2vpn egress-protection 
user@PE2# set group ibgp neighbor 192.0.2.3 
user@PE2# set group ibgp neighbor 192.0.2.4 


4. Configure IS-IS. 


[edit protocols isis] 

user@PE2# set traceoptions file isis-edge size 10m world-readable 
user@PE2# set traceoptions flag error 

user@PE2# set level 1 disable 

user@PE2# set level 2 wide-metrics-only 

user@PE2# set interface all point-to-point 

user@PE2# set interface all level 2 metric 10 

user@PE2# set interface fxp0.0 disable 


5. Configure LDP. 


[edit protocols Idp] 
user@PE2# set interface all 
user@PE2# set interface fxp0.0 disable 


6. Configure a load-balancing policy. 
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[edit] 
user@PE2# set policy-options policy-statement Ib then load-balance per-packet 


7. Configure the routing options to export routes based on the load-balancing policy. 


[edit routing-options] 

user@PE2# set traceoptions file ro.log 
user@PE2# set traceoptions flag all 
user@PE2# set autonomous-system 100 
user@PE2# set forwarding-table export Ib 


8. Configure BGP to advertise nrli from the routing instance with context-ID as next-hop. 


[edit routing-instances] 

user@PE2# set foo instance-type I2vpn 

user@PE2# set foo egress-protection protector 
user@PE2# set foo interface ge-2/0/2.0 

user@PE2# set foo route-distinguisher 10.255.183.57:1 
user@PE2# set foo vrf-target target:9000:1 


9. Configure I2vpn instance to use the egress LSP configured. 


[edit routing-instances] 

user@PE2# set foo protocols I2vpn encapsulation-type ethernet-vlan 

user@PE2# set foo protocols I2vpn site foo hot-standby 

user@PE2# set foo protocols I2vpn site foo site-identifier 1 

user@PE2# set foo protocols I2vpn site foo site-preference backup 

user@PE2# set foo protocols I2vpn site foo interface ge-2/0/2.0 remote-site-id 2 


10. If you are done configuring the device, enter commit from configuration mode. 


Step-by-Step Procedure 


To configure an egress protection LSP for Router PE3: 


1. Configure RSVP. 


[edit protocols rsvp] 
user@PE3# set interface all 
user@PE3# set interface fxp0.0 disable 
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2. Configure MPLS. 


[edit protocols mpls] 
user@PE3# set interface all 
user@PE3# set interface fxp0.0 disable 


3. Configure BGP. 


[edit protocols bgp] 

user@PE3# set traceoptions file bgp.log world-readable 
user@PE3# set group ibgp type internal 

user@PE3# set group ibgp local-address 10.255.183.61 
user@PE3# set group ibgp family inet unicast 
user@PE3# set group ibgp family I2vpn signaling 
user@PE3# set group ibgp neighbor 192.0.2.3 
user@PE3# set group ibgp neighbor 192.0.2.4 


4. Configure IS-IS. 


[edit protocols isis] 

user@PE3# set traceoptions file isis-edge size 10m world-readable 
user@PE3# set traceoptions flag error 

user@PE3# set level 1 disable 

user@PE3# set level 2 wide-metrics-only 

user@PE3# set protocols isis interface all point-to-point 

[edit protocols isis] 

user@PE3# set protocols isis interface all level 2 metric 10 

[edit protocols isis] 

user@PE3# set protocols isis interface fxp0.0 disable 


5. Configure LDP. 
[edit protocols Idp] 


user@PE3# set interface all 
user@PE3# set interface fxp0.0 disable 


6. Configure a load-balancing policy. 


[edit] 
user@PE3# set policy-options policy-statement Ib then load-balance per-packet 
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7. Configure the routing options to export routes based on the load-balancing policy. 


[edit routing-options] 

user@PE3# set traceoptions file ro.log 
user@PE3# set traceoptions flag normal 
user@PE3# set traceoptions flag route 
user@PE3# set autonomous-system 100 
user@PE3# set forwarding-table export Ib 


8. Configure BGP to advertise nlri from the routing instance with context-ID as next-hop. 


[edit] 

user@PE3# set routing-instances foo instance-type I2vpn 

user@PE3# set routing-instances foo interface ge-2/1/2.0 

user@PE3# set routing-instances foo route-distinguisher 10.255.183.61:1 
user@PE3# set routing-instances foo vrf-target target:9000:1 


9. Configure |2vpn to specify the interface that connects to the site and the remote interface to which 


you want the specified interface to connect. 


[edit routing-instances] 

user@PE3# set foo protocols I2vpn encapsulation-type ethernet-vlan 

user@PE3# set foo protocols I2vpn site foo site-identifier 2 

user@PE3# set foo protocols I2vpn site foo interface ge-2/1/2.0 remote-site-id 1 


10. If you are done configuring the device, enter commit from configuration. 


Results 


From configuration mode, confirm your configuration on Router PE1 by entering the show protocols, 
show policy-options, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


[edit] 
user@PE1# show protocols 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 


mpls { 
interface all; 
interface fxp0.0 { 
disable; 
} 
egress-protection { 
context-identifier 198.51.100.3 { 
primary; 
advertise-mode stub-alias; 
} 
traceoptions { 
file ep size 100m; 
flag all; 


} 
bgp { 
traceoptions { 
file bgp.log world-readable; 
} 
group ibgp { 
type internal; 
local-address 10.255.183.58; 
family inet { 
unicast; 
} 
family |2vpn { 
signaling { 
egress-protection; 


} 
neighbor 192.0.2.3; 
neighbor 192.0.2.4; 


} 
isis { 
traceoptions { 
file isis-edge size 10m world-readable; 
flag error; 
} 
level 1 disable; 
level 2 wide-metrics-only; 
interface all { 
point-to-point; 
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level 2 metric 10; 
} 
interface fxp0.0 { 
disable; 


} 
Idp { 
interface all; 
interface fxp0.0 { 
disable; 


[edit] 
user@PE1# show policy-options 
policy-statement lb { 
then { 
load-balance per-packet; 


} 
[edit] 
user@PE1# show routing-options 
traceoptions { 
file ro.log; 
flag all; 
} 
autonomous-system 100; 
forwarding-table { 
export lb; 


[edit] 
user@PE1# show routing-instances 
foo { 
instance-type |2vpn; 
egress-protection { 
context-identifier { 
198.51.100.3; 


} 

interface ge-2/0/2.0; 
route-distinguisher 10.255.183.58:1; 
vrf-target target:9000:1; 

protocols { 
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I2vpn { 
encapsulation-type ethernet-vlan; 
site foo { 
site-identifier 1; 
site-preference primary; 
interface ge-2/0/2.0 { 
remote-site-id 2; 


From configuration mode, confirm your configuration on Router PE2 by entering the show protocols, 
show policy-options, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


[edit] 
user@PE2# show protocols 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 


} 
mpls { 
interface all; 
interface fxp0.0 { 
disable; 
} 
egress-protection { 
context-identifier 198.51.100.3 { 
protector; 
advertise-mode stub-alias; 
} 
traceoptions { 
file ep size 100m; 
flag all; 


} 
bgp { 
traceoptions { 
file bgp.log world-readable; 
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} 
group ibgp { 
type internal; 
local-address 10.255.183.57; 
family inet { 
unicast; 
} 
family I2vpn { 
signaling { 
egress-protection; 


} 
neighbor 192.0.2.3; 
neighbor 192.0.2.4; 


} 
isis { 
traceoptions { 
file isis-edge size 10m world-readable; 
flag error; 
} 
level 1 disable; 
level 2 wide-metrics-only; 
interface all { 
point-to-point; 
level 2 metric 10; 
} 
interface fxp0.0 { 
disable; 


} 
Idp { 
interface all; 
interface fxp0.0 { 
disable; 


[edit] 
user@PE2# show policy-options 
policy-statement lb { 
then { 
load-balance per-packet; 
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[edit] 
user@PE2# show routing-options 
traceoptions { 

file ro.log; 

flag normal; 

flag route; 
} 
autonomous-system 100; 
forwarding-table { 

export Ib; 


[edit] 
user@PE2# show routing-instances 
foo { 
instance-type |2vpn; 
egress-protection { 
protector; 
} 
interface ge-2/0/2.0; 
route-distinguisher 10.255.183.57:1; 
vrf-target target:9000:1; 
protocols { 
I2vpn { 
encapsulation-type ethernet-vlan; 
site foo { 
hot-standby; 
site-identifier 1; 
site-preference backup; 
interface ge-2/0/2.0 { 
remote-site-id 2; 


From configuration mode, confirm your configuration on Router PE3 by entering the show protocols, 
show policy-options, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


[edit] 


user@PE3# show protocols 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 


} 
mpls { 
interface all; 
interface fxp0.0 { 
disable; 


} 
bgp { 
traceoptions { 
file bgp.log world-readable; 
} 
group ibgp { 
type internal; 
local-address 10.255.183.61; 
family inet { 
unicast; 
} 
family |2vpn { 
signaling; 
} 
neighbor 192.0.2.3; 
neighbor 192.0.2.4; 


} 
isis { 
traceoptions { 
file isis-edge size 10m world-readable; 
flag error; 
} 
level 1 disable; 
level 2 wide-metrics-only; 
interface all { 
point-to-point; 
level 2 metric 10; 
} 
interface fxp0.0 { 
disable; 
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} 
Idp { 
interface all; 
interface fxp0.0 { 
disable; 


[edit] 
user@PE3# show policy-options 
policy-statement lb { 
then { 
load-balance per-packet; 


[edit] 
user@PE3# show routing-options 
traceoptions { 

file ro.log; 

flag normal; 

flag route; 
} 
autonomous-system 100; 
forwarding-table { 

export Ib; 


[edit] 
user@PE3# show routing-instances 
foo { 
instance-type |2vpn; 
interface ge-2/1/2.0; 
route-distinguisher 10.255.183.61:1; 
vrf-target target:9000:1; 
protocols { 
I2vpn { 
encapsulation-type ethernet-vlan; 
site foo { 
site-identifier 2; 
interface ge-2/1/2.0 { 
remote-site-id 1; 
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Verification 


IN THIS SECTION 


Verifying the L2VPN Configuration | 327 
Verifying the Routing Instance Details | 328 
Verifying the IS-IS Configuration | 329 


Verifying the MPLS Configuration | 329 


Confirm that the configuration is working properly. 


Verifying the L2VPN Configuration 


Purpose 


Verify that LSP is protected by the connection protection logic. 


Action 


From operational mode, run the show I2vpn connections extensive command. 


user@PE2> show I2vpn connections extensive 


Layer-2 VPN connections: 


Legend for connection status (St) 


interfac ncapsulation not CCC/TCC/VPLS 

















EI -- encapsulation invalid NC 

EM -- encapsulation mismatch tis == 
WESDia == Walicictiell walieemalic Clon Ne == 
CM -- control-word mismatch -> -- 
CNRS ee eC EeaenotmorcOvesekomec go == 
OR -- out of range Us == 
OL -- no outgoing label Dim == 
LD -—- local site signaled down Ce == 
RD remote site signaled down SC -—- 
LN -—- local site not designated LM —- 
RN remote site not designated RM 








interface and instance encaps not same 
interface hardware not present 

only outbound connection is up 

only inbound connection is up 
operational 

down 

call admission control failure 

local and remote site ID collision 


local site ID not minimum designated 





remote site ID not minimum designated 
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XX -—- unknown connection status IL no incoming label 
—-— MTU mismatch MI Mesh-Group ID not available 
BK -- Backup connection Sav Standby connection 
PE -—- Profile parse failure PB Profile busy 
RS remote site standby SN Static Neighbor 
1s} == ieeell sSalice imeie lossie—gabe RB Remote site not best-sit 
VM -- VLAN ID mismatch 
Legend for interface status 
Up -- operational 
Dn -—- down 
Instance: £00 
IWOSAIL SGalicSe ioe (il) 
connection-site Type Time last up # Up trans 
2 rmt UPR AUG as OO OSs Aae20)Os 1 
Local cCHeewiies GSe-—2/O0/2.0, Stacuss Uo 
Remote PH: 192.0.2.3 
Incoming label: 32769, Outgoing label: 32768 
Egress Protection: Yes 
Time Event Interface/Lb1/PE 
Aug 3 00:08:14 2001 PE route up 
Aug 3 00:08:14 2001 Out lbl Update 32768 
Aug 3 00:08:14 2001 In 1bl Update 32769 
Aug 3 00:08:14 2001 ckt0O up fe-0/0/0.0 
Meaning 


The Egress Protection: Yes output shows that the given PVC is protected by connection protection logic. 


Verifying the Routing Instance Details 


Purpose 


Verify the routing instance information and the context identifier configured on the primary, which is used 


as the next-hop address in case of node-link failure. 


Action 


From operational mode, run the show route foo detail command. 


user@PE2> show route foo detail 


© 


Oo: 


Inorbie~ese ICID) S 


ORORIO RO 


Type: l2vpn non-forwarding State: Active 


Interfaces: 


Le=1/2/0.. 56 


Route-distinguisher 


Wrer—imoomts [| — wieit 
Wikc—Erqooiees || — wei 
Vrf-import-target: 
Vrf-export-target: 


§ MO 255 52555 dite i 





import-—foo-internal_ ] 





SO © late OO a rleinits yrs Incl aan 
[ target:100:200 ] 
[ target:100:200 ] 


Fast-reroute-priority: 


low 
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Vso tie 10 K0 [Tol ON AL) OA 10) UO) 0 leas 0 Ir Sc; rato ra 0) O PG) 
Tables: 
foo.12vpn.0 5 routes (3 active, 0 holddown, O hidden) 
BOOnmeZstclen”) 6 routes (2 active, 0 holddown, O hidden) 
Meaning 


The context-id is set to 198.51.100.3 and the Vrf-import: [ __vrf-import-foo-internal__] in the output 
mentions the policy used for rewriting the next-hop address. 


Verifying the IS-IS Configuration 


Purpose 


Verify the IS-IS context identifier information. 


Action 


From operational mode, run the show isis context-identifier detail command. 


user@PE2> show isis context-identifier detail 


IS-IS context database: 


Context L Owner Role Metric 
199.51. 100.3 2 MPLS 
Advertiser prol7-b, Router ID 10.255.107.49, 


RewiEe~ IND) 10,255 4255. ili, 


Primary 
PROLeCtOr jorolyoo=lkeRl 


Level 2, tlv protector 


Advertiser prol7-b-l1r-Rl, Metric 1, Level 2, tlv prefix 


Meaning 


Router PE2 is the protector and the configured context identifier is in use for the MPLS protocol. 


Verifying the MPLS Configuration 


Purpose 


Verify the context identifier details on the primary and protector PEs. 


Action 


From operational mode, run the show mpls context-identifier detail command. 


user@PE1> show mpls context-identifier detail 


ids 198.51 ,.100. 3 
Type: primary, Metric: 1, Mode: alias 


Total 1, Primary 1, Protector 0 


user@PE2> show mpls context-identifier detail 


Wg IS, 5, LOO .3 
Type: protector, Metric: 16777215, Mode: alias 


Context tabille:) e983 ol 002 sees mpilss0, Habel out: 


user@PE2> show mpls egress-protection detail 


instance Type Protection-Type 


foo local-l2vpn Protector 


Route Target 100:200 


Meaning 


ZO IIE 


Context-id is 198.51.100.3, advertise-mode is alias, the MPLS table created for egress protection is 
__198.51.100.3__.mpls.0, and the egress instance name is foo, which is of type local-I2vpn. 


Example: Configuring Layer 3 VPN Egress Protection with PLR as Protector 


IN THIS SECTION 


Requirements | 331 
Overview | 331 
Configuration | 332 


Verification | 354 
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This example shows how to configure fast service restoration at the egress of a Layer 3 VPN when the 
customer is multihomed to the service provider. 


Starting in Junos OS Release 15.1, the enhanced point of local repair (PLR) functionality addresses a special 
scenario of egress node protection, where the PLR and the protector are co-located as one router. In this 
case, there is no need to have a bypass LSP reroute traffic during local repair. Instead, the PLR or the 
protector can send the traffic directly to the target CE (in Co-located protector model where the PLR or 
the protector is also the backup PE that is directly connected to the CE) or to the backup PE (in Centralized 
protector model where the backup PE is a separate router). 


Requirements 


No special configuration beyond device initialization is required before configuring this example. 


This example requires Junos OS Release 15.1 or later. 


Overview 


As a special scenario of egress node protection, if a router is both a Protector and a PLR, it installs backup 
next hops to protect the transport LSP. In particular, it does not need a bypass LSP for local repair. 


In the Co-located protector model, the PLR or the Protector is directly connected to the CE via a backup 
AC, while in the Centralized protector model, the PLR or the protector has an MPLS tunnel to the backup 
PE. In either case, the PLR or the Protector will install a backup next hop with a label followed by a lookup 
in a context label table, i.e. __ context__.mpls.0. When the egress node fails, the PLR or the Protector will 
switch traffic to this backup next hop in PFE. The outer label (the transport LSP label) of packets is popped, 
and the inner label (the layer 3 VPN label allocated by the egress node) is looked up in __context__.mpls.0, 
which results in forwarding the packets directly to the CE (in Collocated protector model) or the backup 

PE (in Centralized protector model). 


Topology 


Figure 17 on page 331 shows the sample network. 


Figure 17: Co-located PLR and protector in collocated protector model 


PE] P PE2 
ge-0/0/1 ge-0/0/1 ge-0/0/0 ge-0/0/0 ge-0/0/2 
al 10.10.10/30 2 2 10,10.11/30 l al 10.10.30/30 
.1) ge-0/0/0 ge-0/0/1 | .1 
10.10.20/30 
.2| ge-0/0/0 ge-0/0/2}.2 
10.10.12/30 
CE2 
CEl ge-0/0/0 |.2 
ge-0/0/1 | .2 
‘ll 10.10.40/30 
ge-0/0/0 
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Configuration 


IN THIS SECTION 


Configuring Device CE1 | 337 
Configuring Device PE1 | 337 
Configuring Device P | 339 
Configuring Device PE2 | 340 
Configuring Device PE3 | 343 
Configuring Device CE2 | 345 
Results | 345 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 


line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


Device CE1 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.20.2/30 
set interfaces loO unit O family inet address 10.255.162.87/32 


Device PE1 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.20.1/30 

set interfaces ge-0/0/1 unit 0 family inet address 10.10.10.1/30 

set interfaces ge-0/0/1 unit 0 family inet6 

set interfaces ge-0/0/1 unit 0 family iso 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 127.0.0.1/32 

set interfaces loO unit O family inet address 10.255.162.84/32 primary 

set interfaces loO unit O family inet6 address abcd::10:255:162:84/128 primary 

set interfaces loO unit O family iso address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2084.00 
set policy-options policy-statement vpn-exp term 1 from protocol direct 

set policy-options policy-statement vpn-exp term 1 from route filter 10.10.20.0/24 exact 
set policy-options policy-statement vpn-exp term 1 then community add vpn 
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set policy-options policy-statement vpn-exp term 1 then accept 

set policy-options policy-statement vpn-imp term 1 from community vpn 
set policy-options policy-statement vpn-imp term 1 then accept 

set policy-options policy-statement vpn-imp term 2 then reject 

set policy-options community vpn members traget:1:1 

set routing-options autonomous-system 65000 

set protocols rsvp interface all link-protection 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp vpn-apply-export 

set protocols bgp group vpn type internal 

set protocols bgp group vpn local-address 10.255.162.84 

set protocols bgp group vpn family inet-vpn unicast 

set protocols bgp group vpn neighbor 10.255.162.91 

set protocols bgp group vpn neighbor 10.255.162.89 

set protocols isis interface all 

set protocols isis interface fxp0.0 disable 

set protocols isis interface lo0.0 passive 

set routing-instances vpn instance-type vrf 

set routing-instances vpn interface ge-1/0/0.0 

set routing-instances vpn route-distinguisher 100:100 

set routing-instances vpn vrf-import vpn-imp 

set routing-instances vpn vrf-export vpn-exp 

set routing-instances vpn vrf-table-label 

set routing-instances vpn protocols bgp group vpn type external 

set routing-instances vpn protocols bgp group vpn family inet unicast 
set routing-instances vpn protocols bgp group vpn family inet6 unicast 
set routing-instances vpn protocols bgp group vpn peer-as 65001 

set routing-instances vpn protocols bgp group vpn as-override 

set routing-instances vpn protocols bgp group vpn neighbor 10.10.20.2 


Device P 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.11.2/30 
set interfaces ge-0/0/0 unit 0 family inet6 

set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 10.10.10.2/30 
set interfaces ge-0/0/1 unit 0 family inet6 
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set interfaces ge-0/0/1 unit 0 family iso 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 127.0.0.1/32 

set interfaces loO unit O family inet address 10.255.162.86/32 primary 

set interfaces loO unit O family inet6 address abcd::10:255:162:86/128 primary 
set interfaces loO unit O family iso address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2086.00 
set protocols rsvp interface all link-protection 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols isis interface all 

set protocols isis interface fxp0.0 disable 


Device PE2 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.11.1/30 

set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family inet6 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 10.10.12.1/30 

set interfaces ge-0/0/1 unit 0 family iso 

set interfaces ge-0/0/1 unit 0 family inet6 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 10.10.30.1/30 

set interfaces loO unit O family inet address 127.0.0.1/32 

set interfaces loO unit O family inet address 10.255.162.91/32 primary 

set interfaces loO unit O family iso address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2091.00 
set interfaces loO unit O family inet6 address abcd::10:255:162:91/128 primary 
set routing-options graceful-restart 

set routing-options autonomous-system 65000 

set routing-options forwarding-table export pplb 

set protocols rsvp interface all link-protection 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls label-switched-path to_PE1 to 10.255.162.84 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols mpls egress-protection context-identifier 1.1.1.1 protector 

set protocols mpls egress-protection context-identifier 1.1.1.1 advertise-mode stub-alias 
set protocols bgp vpn-apply-export 

set protocols bgp group vpn type internal 
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set protocols bgp group vpn local-address 10.255.162.91 

set protocols bgp group vpn family inet-vpn unicast egress-protection 
set protocols bgp group vpn neighbor 10.255.162.84 

set protocols bgp group vpn neighbor 10.255.162.89 

set protocols isis traceoptions file isis.log 

set protocols isis traceoptions flag all detail 

set protocols isis level 2 disable 

set protocols isis interface all 

set protocols isis interface fxp0.0 disable 

set protocols isis interface lo0.0 passive 

set policy-options policy-statement pplb term 1 then load-balance per-packet 
set policy-options policy-statement vpn-exp term 1 from protocol bgp 
set policy-options policy-statement vpn-exp term 1 then community add vpn 
set policy-options policy-statement vpn-exp term 1 then accept 

set policy-options policy-statement vpn-imp term 1 from community vpn 
set policy-options policy-statement vpn-imp term 1 then accept 

set policy-options policy-statement vpn-imp term 2 then reject 

set policy-options community vpn members target:1:1 

set routing-instances vpn instance-type vrf 

set routing-instances vpn interface ge-3/2/4.0 

set routing-instances vpn route-distinguisher 100:100 

set routing-instances vpn vrf-import vpn-imp 

set routing-instances vpn vrf-export vpn-exp 

set routing-instances vpn vrf-table-label 

set routing-instances vpn protocols bgp group vpn type external 

set routing-instances vpn protocols bgp group vpn family inet unicast 
set routing-instances vpn protocols bgp group vpn family inet6 unicast 
set routing-instances vpn protocols bgp group vpn peer-as 65001 

set routing-instances vpn protocols bgp group vpn as-override 

set routing-instances vpn protocols bgp group vpn neighbor 10.10.30.2 


Device PE3 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.40.1/30 

set interfaces ge-0/0/1 unit 0 family inet address 10.10.12.2/30 

set interfaces ge-0/0/1 unit 0 family iso 

set interfaces ge-0/0/1 unit 0 family inet6 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 127.0.0.1/32 

set interfaces loO unit O family inet address 10.255.162.89/32 primary 
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set interfaces loO unit O family iso address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2089.00 
set interfaces loO unit O family inet6 address abcd::10:255:162:89/128 primary 
set routing-options graceful-restart 

set routing-options autonomous-system 65000 

set routing-options forwarding-table export pplb 

set protocols rsvp interface all link-protection 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls label-switched-path to_PE2 to 10.255.162.91 

set protocols mpls label-switched-path to_PE1 to 10.255.162.84 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols mpls egress-protection context-identifier 1.1.1.1 primary 
set protocols mpls egress-protection context-identifier 1.1.1.1 advertise-mode stub-alias 
set protocols bgp vpn-apply-export 

set protocols bgp group vpn type internal 

set protocols bgp group vpn local-address 10.255.162.89 

set protocols bgp group vpn family inet-vpn unicast 

set protocols bgp group vpn neighbor 10.255.162.84 local-preference 300 
set protocols bgp group vpn neighbor 10.255.162.91 

set protocols isis level 2 disable 

set protocols isis interface all 

set protocols isis interface fxp0.0 disable 

set protocols isis interface lo0.0 passive 

set routing-instances vpn instance-type vrf 

set routing-instances vpn egress-protection context-identifier 1.1.1.1 

set routing-instances vpn interface ge-1/1/0.0 

set routing-instances vpn route-distinguisher 100:100 

set routing-instances vpn vrf-import vpn-imp 

set routing-instances vpn vrf-export vpn-exp 

set routing-instances vpn vrf-table-label 

set routing-instances vpn protocols bgp group vpn type external 

set routing-instances vpn protocols bgp group vpn family inet unicast 

set routing-instances vpn protocols bgp group vpn family inet6 unicast 
set routing-instances vpn protocols bgp group vpn peer-as 65001 

set routing-instances vpn protocols bgp group vpn as-override 

set routing-instances vpn protocols bgp group vpn neighbor 10.10.40.2 


Device CE2 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.40.2/30 
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set interfaces ge-0/0/2 unit 0 family inet address 10.10.30.2/30 

set interfaces loO unit O family inet address 127.0.0.1/32 

set interfaces loO unit O family inet address 10.255.162.88/32 primary 

set interfaces loO unit O family iso address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2088.00 
set interfaces loO unit O family inet6 address abcd::10:255:162:88/128 primary 


Configuring Device CE1 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


1. Configure interfaces. 


[edit interfaces] 
user@CE1# set ge-0/0/0 unit 0 family inet address 10.10.20.2/30 
user@CE1# set loO unit 0 family inet address 10.255.162.87/32 


Configuring Device PE1 


Step-by-Step Procedure 


1. Configure the interfaces. 


[edit interfaces] 

user@PE1# set ge-0/0/0 unit 0 family inet address 10.10.20.1/30 

user@PE1# set ge-0/0/1 unit 0 family inet address 10.10.10.1/30 

user@PE1# set ge-0/0/1 unit 0 family iso 

user@PE1# set ge-0/0/1 unit O family inet6 

user@PE1# set ge-0/0/1 unit O family mpls 

user@PE1# set loO unit O family inet address 127.0.0.1/32 

user@PE1# set loO unit O family inet address 10.255.162.84/32 primary 

user@PE1# set loO unit O family iso address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2084.00 
user@PE1# set loO unit O family inet6 address abcd::10:255:162:84/128 primary 


2. Configure the autonomous system (AS) number. 


[edit routing-options] 
user@PE1# set autonomous-system 65000 
user@PE1# set forwarding-table export pplb 
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3. Configure RSVP. 


[edit protocols rsvp] 
user@PE1# set interface all link-protection 
user@PE1# set interface fxp0.0 disable 


4. Enable MPLS. 


[edit protocols mpls] 
user@PE1# set interface all 
user@PE1# set interface fxp0.0 disable 


5. Configure BGP. 


[edit protocols bgp] 

user@PE1# set group vpn type internal 

user@PE1# set group vpn local-address 10.255.162.84 
user@PE1# set group vpn family inet-vpn unicast 
user@PE1# set group vpn neighbor 10.255.162.91 
user@PE1# set group vpn neighbor 10.255.162.89 
user@PE1# set vpn-apply-export 


6. Enable IS-IS. 


[edit protocols isis] 

user@PE1# set interface all 
user@PE1# set interface fxp0.0 disable 
user@PE1# set interface lo0.0 passive 


7. (Optional) Configure OSPF 


[edit protocols ospf] 

user@PE1# set area 0.0.0.0 interface all 
user@PE1# set area 0.0.0.0 interface fxp0.0 disable 
user@PE1# set area 0.0.0.0 interface 100.0 passive 
user@PE1# set traffic-engineering 


8. Configure the routing instance. 
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[edit routing-instances] 

user@PE1# set vpn instance-type vrf 

user@PE1# set vpn interface ge-1/0/0.0 

user@PE1# set vpn route-distinguisher 100:100 

user@PE1# set vpn vrf-import vpn-imp 

user@PE1# set vpn vrf-export vpn-exp 

user@PE1# set vpn vrf-table-label 

user@PE1# set vpn protocols bgp group vpn type external 
user@PE1# set vpn protocols bgp group vpn family inet unicast 
user@PE1# set vpn protocols bgp group vpn family inet6 unicast 
user@PE1# set vpn protocols bgp group vpn peer-as 65001 
user@PE1# set vpn protocols bgp group vpn as-override 
user@PE1# set vpn protocols bgp group vpn neighbor 10.10.20.2 


9. Configure the routing policy. 


[edit] 

user@PE1# set policy-options policy-statement vpn-exp term 1 from protocol direct 

user@PE1# set policy-options policy-statement vpn-exp term 1 from route filter 10.10.20.0/24 exact 
user@PE1# set policy-options policy-statement vpn-exp term 1 then community add vpn 

user@PE1# set policy-options policy-statement vpn-exp term 1 then accept 

user@PE11# set policy-options policy-statement vpn-imp term 1 from community vpn 

user@PE1# set policy-options policy-statement vpn-imp term 1 then accept 

user@PE11# set policy-options policy-statement vpn-imp term 2 then reject 

user@PE1# set policy-options community vpn members traget:1:1 


Configuring Device P 


Step-by-Step Procedure 


1. Configure the device interfaces. 


[edit interfaces] 

user@P# set ge-0/0/0 unit 0 family inet address 10.10.11.2/30 
user@P# set ge-0/0/0 unit 0 family inet6 

user@P# set ge-0/0/0 unit 0 family iso 

user@P# set ge-0/0/0 unit 0 family mpls 

user@P# set ge-0/0/1 unit O family inet address 10.10.10.2/30 
user@P# set ge-0/0/1 unit 0 family inet6 

user@P# set ge-0/0/1 unit 0 family iso 

user@P# set ge-0/0/1 unit O family mpls 

user@P# set loO unit O family inet address 127.0.0.1/32 
user@P# set loO unit O family inet address 10.255.162.86/32 primary 


user@P# set loO unit O family inet6 address abcd::10:255:162:86/128 primary 
user@P# set loO unit O family iso address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2086.00 


2. Enable IS-IS. 


[edit protocols isis] 
user@P# set interface all 
user@P# set interface fxp0.0 disable 


3. Enable MPLS. 


[edit protocols mpls ] 
user@P# set interface all 
user@P# set interface fxp0.0 disable 


4. Configure RSVP. 


[edit protocols rsvp] 
user@P# set interface all link-protection 
user@P# set interface fxp0.0 disable 


5. (Optional) Configure OSPF. 


[edit protocols ospf] 

user@P# set area 0.0.0.0 interface all 

user@P# set area 0.0.0.0 interface fxp0.0 disable 
user@P# set area 0.0.0.0 interface lo0.0 passive 
user@P# set traffic-engineering 


Configuring Device PE2 


Step-by-Step Procedure 


1. Configure the interfaces. 


[edit interfaces] 

user@PE2# set ge-0/0/0 unit O family inet address 10.10.11.1/30 
user@PE2# set ge-0/0/0 unit O family iso 

user@PE2# set ge-0/0/0 unit O family inet6 

user@PE2# set ge-0/0/0 unit O family mpls 


340 


341 


user@PE2# set ge-0/0/1 unit 0 family inet address 10.10.12.1/30 

user@PE2# set ge-0/0/1 unit 0 family iso 

user@PE2# set ge-0/0/1 unit 0 family inet6 

user@PE2# set ge-0/0/1 unit O family mpls 

user@PE2# set ge-0/0/2 unit 0 family inet address 10.10.30.1/30 

user@PE2# set loO unit O family inet address 127.0.0.1/32 

user@PE2# set loO unit O family inet address 10.255.162.91/32 primary 

user@PE2# set loO unit O family iso address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2091.00 
user@PE2# set loO unit O family inet6 address abcd::10:255:162:91/128 primary 


2. Configure autonomous number(AS). 


[edit routing-options] 
user@PE2# set autonomous-system 65000 
user@PE2# set forwarding-table export pplb 


3. Configure RSVP. 


[edit protocols rsvp] 
user@PE2# set interface all link-protection 
user@PE2# set interface fxp0.0 disable 


4. Configure MPLS. 


[edit protocols mpls] 

user@PE2# set label-switched-path to_PE1 to 10.255.162.84 

user@PE2# set interface all 

user@PE2# set interface fxp0.0 disable 

user@PE2# set egress-protection context-identifier 1.1.1.1 protector 

user@PE2# set egress-protection context-identifier 1.1.1.1 advertise-mode stub-alias 


5. Configure BGP. 


[edit protocols bgp] 

user@PE2# set group vpn family inet-vpn unicast egress-protection 
user@PE2# set group vpn local-address 10.255.162.91 

user@PE2# set group vpn neighbor 10.255.162.84 

user@PE2# set group vpn neighbor 10.255.162.89 

user@PE2# set group vpn type internal 

user@PE2# set vpn-apply-export 
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6. Configure IS-IS. 


[edit protocols isis] 

user@PE2# set interface all 

user@PE2# set interface fxp0.0 disable 
user@PE2# set interface lo0.0 passive 
user@PE2# set level 2 disable 
user@PE2# set traceoptions file isis.log 
user@PE2# set traceoptions flag all detail 


7. (Optional) Configure OSPF. 


[edit protocols ospf] 

user@PE2# set area 0.0.0.0 interface all 
user@PE2# set area 0.0.0.0 interface fxp0.0 disable 
user@PE2# set area 0.0.0.0 interface lo0.0 passive 
user@PE2# set traffic-engineering 


8. Configure the routing policy. 


[edit policy-options] 

user@PE2# set community vpn members target:1:1 

user@PE2# set policy-statement pplb term 1 then load-balance per-packet 
user@PE2# set policy-statement vpn-exp term 1 from protocol bgp 
user@PE2# set policy-statement vpn-exp term 1 then community add vpn 
user@PE2# set policy-statement vpn-exp term 1 then accept 

user@PE2# set policy-statement vpn-imp term 1 from community vpn 
user@PE2# set policy-statement vpn-imp term 1 then accept 

user@PE2# set policy-statement vpn-imp term 2 then reject 


9. Configure the routing instance. 


[edit routing-instances] 

user@PE2# set vpn instance-type vrf 

user@PE2# set vpn interface ge-3/2/4.0 

user@PE2# set vpn route-distinguisher 100:100 

user@PE2# set vpn vrf-import vpn-imp 

user@PE2# set vpn vrf-export vpn-exp 

user@PE2# set vpn vrf-table-label 

user@PE2# set vpn protocols bgp group vpn type external 
user@PE2# set vpn protocols bgp group vpn family inet unicast 
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user@PE2# set vpn protocols bgp group vpn family inet6 unicast 
user@PE2# set vpn protocols bgp group vpn peer-as 65001 
user@PE2# set vpn protocols bgp group vpn as-override 
user@PE2# set vpn protocols bgp group vpn neighbor 10.10.30.2 


Configuring Device PE3 


Step-by-Step Procedure 


1. Configure the interfaces. 


[edit interfaces] 

user@PE3# set ge-0/0/0 unit 0 family inet address 10.10.40.1/30 

user@PE3# set ge-0/0/1 unit O family inet address 10.10.12.2/30 

user@PE3# set ge-0/0/1 unit 0 family iso 

user@PE3# set ge-0/0/1 unit O family inet6 

user@PE3# set ge-0/0/1 unit O family mpls 

user@PE3# set loO unit O family inet address 127.0.0.1/32 

user@PE3# set loO unit O family inet address 10.255.162.89/32 primary 

user@PE3# set loO unit O family iso address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2089.00 
user@PE3# set loO unit O family inet6 address abcd::10:255:162:89/128 primary 


2. Configure the autonomous number (AS). 


[edit routing-options] 
user@PE3# set autonomous-system 65000 
user@PE3# set forwarding-table export pplb 


3. Configure RSVP. 


[edit protocols rsvp] 
user@PE3# set interface all link-protection 
user@PE3# set interface fxp0.0 disable 


4. Configure MPLS. 


[edit protocols mpls] 

user@PE3# set interface all 

user@PE3# set interface fxp0.0 disable 

user@PE3# set egress-protection context-identifier 1.1.1.1 primary 

user@PE3# set egress-protection context-identifier 1.1.1.1 advertise-mode stub-alias 
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user@PE3# set label-switched-path to_PE2 to 10.255.162.91 
user@PE3# set label-switched-path to_PE1 to 10.255.162.84 


5. Configure BGP. 


[edit protocols bgp] 

user@PE3# set group vpn type internal 

user@PE3# set group vpn local-address 10.255.162.89 

user@PE3# set group vpn family inet-vpn unicast 

user@PE3# set group vpn neighbor 10.255.162.84 local-preference 300 
user@PE3# set group vpn neighbor 10.255.162.91 

user@PE3# set vpn-apply-export 


6. Configure IS-IS. 


[edit protocols isis] 

user@PE3# set interface all 
user@PE3# set interface fxp0.0 disable 
user@PE3# set interface |o0.0 passive 
user@PE3# set level 2 disable 


7. (Optional) Configure OSPF. 


[edit protocols ospf] 

user@PE3# set area 0.0.0.0 interface all 
user@PE3# set area 0.0.0.0 interface fxp0.0 disable 
user@PE3# set area 0.0.0.0 interface lo0.0 passive 
user@PE3# set traffic-engineering 


8. Configure the routing instance. 


[edit routing-instances] 

user@PE3# set vpn egress-protection context-identifier 1.1.1.1 
user@PE3# set vpn instance-type vrf 

user@PE3# set vpn interface ge-1/1/0.0 

user@PE3# set vpn protocols bgp group vpn type external 
user@PE3# set vpn protocols bgp group vpn family inet unicast 
user@PE3# set vpn protocols bgp group vpn family inet6 unicast 
user@PE3# set vpn protocols bgp group vpn peer-as 65001 
user@PE3# set vpn protocols bgp group vpn as-override 
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user@PE3# set vpn protocols bgp group vpn neighbor 10.10.40.2 
user@PE3# set vpn route-distinguisher 100:100 

user@PE3# set vpn vrf-export vpn-exp 

user@PE3# set vpn vrf-import vpn-imp 

user@PE3# set vpn vrf-table-label 


Configuring Device CE2 


Step-by-Step Procedure 


1. Configure the interfaces. 


[edit interfaces] 

user@CE2# set ge-0/0/0 unit O family inet address 10.10.40.2/30 

user@CE2# set ge-0/0/2 unit 0 family inet address 10.10.30.2/30 

user@CE2# set loO unit O family inet address 127.0.0.1/32 

user@CE2# set loO unit O family inet address 10.255.162.88/32 primary 

user@CE2# set loO unit O family iso address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2088.00 
user@CE2# set loO unit 0 family inet6 address abcd::10:255:162:88/128 primary 


Results 


From configuration mode, confirm your configuration by entering the show interfaces and show protocols 
commands. If the output does not display the intended configuration, repeat the instructions in this example 
to correct the configuration. 


Device CE1 


user@CE1# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 10.10.20.2/30; 


Device PE1 


user@PE1# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 10.10.20.1/30; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 10.10.10.1/30; 
} 
family iso; 
family inet6; 
family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 127.0.0.1/32; 
address 10.255.162.84/32 { 


primary; 


} 
family iso { 
address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2084.00; 
} 
family ineté { 
address abcd::10:255:162:84/128 { 
primary; 


user@PE1# show protocols 
rsvp { 
interface all { 
link-protection; 
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} 
interface fxp0.0 { 


disable; 


} 
mpls { 
interface all; 
interface fxp0.0 { 
disable; 


} 
bgp { 
vpn-apply-export; 
group vpn { 
type internal; 
local-address 10.255.162.84; 
family inet-vpn { 
unicast; 
} 
neighbor 10.255.162.91; 
neighbor 10.255.162.89; 


} 
isis { 
interface all; 
interface fxp0.0 { 
disable; 
} 
interface 100.0 { 


passive; 


Device P 


user@P# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 10.10.11.2/30; 
} 


family iso; 
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family inet6; 
family mpls; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 10.10.10.2/30; 
} 
family iso; 
family inet6; 
family mpls; 


} 
1o0 { 
unit O { 
family inet { 
address 127.0.0.1/32; 
address 10.255.162.86/32 { 
primary; 


} 
family iso { 
address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2086.00; 
} 
family ineté { 
address abcd::10:255:162:86/128 { 
primary; 


user@P# show protocols 
rsvp { 
interface all { 
link-protection; 
} 
interface fxp0.0 { 
disable; 


} 
mpls { 
interface all; 
interface fxp0.0 { 
disable; 


} 
isis { 
interface all; 
interface fxp0.0 { 
disable; 


Device PE2 


user@PE2# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 10.10.11.1/30; 

} 

family iso; 

family inet6; 

family mpls; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 10.10.12.1/30; 
} 
family iso; 
family inet6; 
family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 10.10.30.1/30; 
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} 
loO { 
unit O { 
family inet { 
address 127.0.0.1/32; 
address 10.255.162.91/32 { 
primary; 


} 
family iso { 
address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2091.00; 
} 
family ineté { 
address abcd::10:255:162:91/128 { 
primary; 


user@PE2# show protocols 
rsvp { 
interface all { 
link-protection; 
} 
interface fxp0.0 { 
disable; 


} 
mpls { 
label-switched-path to_PE1 { 
to 10.255.162.84,; 
} 
interface all; 
interface fxp0.0 { 
disable; 
} 
egress-protection { 
context-identifier 1.1.1.1 { 
protector; 
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advertise-mode stub-alias; 


} 
bgp { 
vpn-apply-export; 
group vpn { 
type internal; 
local-address 10.255.162.91; 
family inet-vpn { 
unicast { 
egress-protection; 


} 
neighbor 10.255.162.84; 
neighbor 10.255.162.89; 


} 
isis { 
traceoptions { 
file isis.log; 
flag all detail; 
} 
level 2 disable; 
interface all; 
interface fxp0.0 { 
disable; 
} 
interface 100.0 { 
passive; 


Device PE3 


user@PE3# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 10.10.40.1/30; 
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} 
ge-0/0/1 { 
unit O { 
family inet { 
address 10.10.12.2/30; 
} 
family iso; 
family ineté6; 
family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 127.0.0.1/32; 
address 10.255.162.89/32 { 
primary; 


} 
family iso { 
address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2089.00; 
} 
family ineté { 
address abcd::10:255:162:89/128 { 
primary; 


user@PE3# show protocols 
rsvp { 
interface all { 
link-protection; 
} 
interface fxp0.0 { 
disable; 


} 
mpls { 
label-switched-path to_PE2 { 
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to 10.255.162.91; 
} 
label-switched-path to_PE1 { 
to 10.255.162.84; 
} 
interface all; 
interface fxp0.0 { 
disable; 
} 
egress-protection { 
context-identifier 1.1.1.1 { 
primary; 
advertise-mode stub-alias; 


} 
bgp { 
vpn-apply-export; 
group vpn { 
type internal; 
local-address 10.255.162.89; 
family inet-vpn { 
unicast; 
} 
neighbor 10.255.162.84 { 
local-preference 300; 
} 
neighbor 10.255.162.91; 


} 
isis { 
level 2 disable; 
interface all; 
interface fxp0.0 { 
disable; 
} 
interface 100.0 { 
passive; 


Device CE2 


user@CE2# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 10.10.40.2/30; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 10.10.30.2/30; 


} 
loO { 
unit O { 
family inet { 
address 127.0.0.1/32; 
address 10.255.162.88/32 { 
primary; 


} 
family iso { 
address 47.0005.80ff.f800.0000.0108.0001.0102.5516.2088.00; 


} 
family ineté { 


address abcd::10:255:162:88/128 { 
primary; 


Verification 


IN THIS SECTION 


@ Verifying the Routing Instance | 355 
@ ~~ Checking the Context Identifier Route | 363 


354 


355 


Verifying the Routing Instance 


Purpose 


Check the routes in the routing table. 


Action 





user@PE1> show route 10.10.50 table vpn.inet.0 


vpn.inet.0: 6 destinations, 7 routes (6 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


10,1050 0/24 





“[RE2/LVO] OOsOile26, iko@alljowex 100, iceom 10,255,162, 96 
AS path: 65001 I, validation-state: unverified 





PTO LO lOn lO Remit amGe = 0/2 10a cus e6) sts nes UO0G4 (iro) 
[SEPy AN ONMOOMO G22 aeLocaliore tr 5 0; bom lOm2 Sonekocm oir 





AS path: 65001 I, validation-state: unverified 





> co LO ,lO 10.2 wila ge=—2/0/2.0, Pusin 17, Pusin 2E9920 (ices) 


user@PE1>show route 10.10.50 extensive table vpn.inet.0 


vpn.inet.0: 6 
NORPRO RS OR Oy 24 
WSS 
KRT in-kernel 
Page 0 idx 1, 
Advertised 
Nexthop: 
AS path: 


destinations, 7 routes (6 active, 0 holddown, O hidden) 


(2 entries, 1 announced) 


10.10.50.0/24 —> {indirect (1048575) } 





(group vpn type External) Type 1 val 0x9e33490 (adv_entry) 


MUNCIE OSS 
Self 
[65000] 65000 I 


Communities: target:1:1 


Peele, IL), 110), S10). 


“BGP 


© rieom 10,255,162, 96 Wectox ieim 4, Welle i 
Preference: 170/-101 
Route Distinguisher: 200:100 





Next hop type: Indirect, Next hop index: 0 
Address: 0x9db63f0 

Next-hop reference count: 6 

SoMmeSse NO 25S 6 152. 96 

Next hop type: Router, Next hop index: 635 
Next hop) LOmLOR NOR Ze valage=2/10/ 20), scillected 
Label operation: Push 16, Push 300064 (top) 








ILGIQES IL WEIL QCEULOMS JORG SCE, joo o—ticll (ite) 
Load balance label: Label 16: None; Label 300064: None; 
Label element ptr: 0x9dbé6é0e0 
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Label parent element ptr: 0x9db5e40 





Label element references: 1 

Label element child references: 0 
Label element lsp id: 0 

Session Id: 0x146 

TeOEOCOl mexic Inejre ili. i.d 

Label operation: Push 16 


Label TTL action: prop-ttl 








Load balance label: Label 16: None; 
Indirect next hop: 0x9e55440 1048575 INH Session ID: 0x14d 








State: < Secondary Active Int Ext ProtectionCand > 
hocal AS: 65000) Peer AS: 650100 

Age: 1:28 Metric2: 1 

Validation State: unverified 

Iaisleg WEP _GS000,10 255.162. 96 

Announcement bits (2): O-KRT 1-BGP_RT_Background 
MS jOsrclas SOO i 

Communities: target:1:1 

Import Accepted 

VPN Label: 16 

Localpref: 100 

RemEsr IDS 10), 255.5 162.96 

Primary Routing Table bgp.13vpn.0 

Indirect next hops: 1 

LOCOCOL mexce ines L,l 1.1 Metrdesg I 
Label operation: Push 16 


InGgSil WIL) BGILoMe jowe~e—icie ll 





Load balance label: Label 16: None; 
Indirect next hop: 0x9e55440 1048575 INH Session ID: 0x14d 


Indirect path forwarding next hops: 1 
Next hop type: Router 
NESE Ines 10.10 ,10,2 wie cia—-2/0/2.0 
Session Id: 0x146 
Toi. ,l/ 32 Oreakepiingicaiae IRIEe slinete 5 SI 
MaicieiLes: IL Node path count: 1 
Forwarding nexthops: 1 
Nexthopr LO} M0SL0n 2 vara ge=27/10)/ 250 
BGP Preference: 170/-51 
Route Distinguisher: 100:100 
Next hop type: Indirect, Next hop index: 0 
Address: 0x9db6390 





Next-hop reference count: 5 
Souweees 10,255,162. 91 


Next hop type: Router, Next hop index: 636 
Next hop: 10.10.10.2 via ge-2/0/2.0, selected 
Label operation: Push 17, Push 299920 (top) 
InGlSl WW ESELSMs jorRCe-ciblL, joeco—icicll (ite) 


Label element ptr: 0x9db62c0 
Label parent element ptr: 0x9dc0d00 





Label element references: 1 





Label element child references: 0 





Label element lsp id: 0 

Session Id: 0x146 

TEOEOCOl mexic Imejos ILO ,255, 162 4 QL 
Label operation: Push 17 


Label TTL action: prop-ttl 








Load balance label: Label 17: None; 





Indirect next hop: 0x9e55580 1048574 INH Session ID: 





State: < Secondary Int Ext ProtectionCand > 
Inactive reason: Local Preference 

hocalAS OSU 00N Ree VAS: 650100 

Age: 6:24 Metric2: 1 

Validation State: unverified 

Tasks WEP_GSOO0,10.255. 162, 9 

AS path: 65001 I 

Communities: target:1:1 

Import Accepted 

VPN Label: 17 

Localpref: 50 

Reweesr IDs LO. 255.,162.492 

Primary Routing Table bgp.13vpn.0 

Indirect next hops: 1 

PEOCOCOL mex Ines 10,255,162. Si Meiries i 
Label operation: Push 17 


Label TTL action: prop-ttl 





Load balance label: Label 17: None; 


Load balance label: Label 17: None; Label 299920: None; 


Oxl4c 


Indirect next hop: 0x9e55580 1048574 INH Session ID: 0x14c 


Indirect path forwarding next hops: 1 
Next hop type: Router 
Next enorme On lOn Om uaveramce 21/10), 2510) 
Session Id: 0x146 


10,255,162. 91/32 Oicsloaiimaie sinc IIe slievete, . 3} 


Metric: 


al 


Node path count: 1 
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Forwarding nexthops: 1 


Nexthop: 





user@PE2> show route table mpls.0 


mpls.0: 15 destinations, 15 routes 








+ = Activ 


2 (S=0) 


ALS} 


ole 


299856 (S=0) 


299904 


299904 (S=0) 


2999210 


300016 


300016 (S=0) 


300048 


300048 (S=0) 


Rout 


, 

















Last Active, 

















PMSy0) OO zs 
to table ine 
PIES /OilO O23 
to table mpl 
PES / Oil On2 3 
Receive 
PES/ 0) m0 O23 
to table ine 
PESO OOR2 
to table mpl 
PES OilmOOR2 3 
Receive 
PN/On COR 23 
to table vpn 
PIES / ONO Or22 
EOmtal:lic ial 
IDP/S)] WOs@ls 
EO LO, 10), ia. 
EDE/ OOO One: 
EO: IO), 10), tal 
inDIP/S)]| WOs@ils 
EO IO), 10), tal 
InDIP/S)]] WOs@ils 
EO 10510. 2. 
to table _ 1 
DP/9] 00:01: 
56 10,10. 12. 
to table __ 1 
IDP/S}] WOs@ls 
EO: IO), 0), 2 
LDP/9] 00:01: 
EO LO, 10,12 








10.10.10.2 via ge-2/0/2.0 


(15 active, 0 holddown, O hidden) 
i mel 


= Both 


CAS, miieieie: IL 
ee) 
SAS, mlsieiesle: AL 
S50 


BAS, isieieake: AL 





C85, iaeicicaye iL 
EGo€ 

E33, meieiesle i 
Sind) 

233, mSierske iL 
33 

-inet.0, Pop 
333 


cla. il ijolls.. 0) 
BO, mveieiese 1 
2 via xe-8/2/5.0, 


SO, mecieiLe I 


-2 via xe—-8/2/5.0, 


SO, mercies IL 


-2 via xe-8/2/5.0, 


50, metric 1 
il Wile ce—3/0/2.0, 
sod. heinous.) 

fo] 0 Fame (ton anon hl 
I Wila ce—3/0/2 0, 
cil, dl. iL cies, ©) 

SO, mveieieste@ 1 
1 Wie ge-3/0/2.0, 
SO, mereiesc 1 
1 via ge-3/0/2.0, 





Pop 


Pop 


Swap 299904 


Pop 


Pop 


Pop 


Pop 
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user@PE2> show route table _1.1.1.1__.mpls.0 


__1.1.1.1__.mpls.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


16 * 





Egress-—Protection/170] 00:22:57 
tO ieGlole — ii, i, il-woo__, mee © 





user@PE2> show route table _1.1.1.1__.mpls.0 extensive 


ee emp lsh Oa lanclesieninicie tons ae aerouisS Sun cae Eine, mOmnoledown,mlOmn=rkclclem) 
16 (1 entry, 1 announced) 
State: < CalcForwarding > 
ISL 
KRT in-kernel 16 /52 -> {Table} 





*Egress-Protection Preference: 170 

INERE ieéloles i .il,1,il-yom__, 1imSie . 0 
Next-hop index: 649 

Address: 0x9dc2690 





Next-hop reference count: 2 








State: < Active NoReadvrt ForwardingOnly Int Ext > 
Local AS: 65000 
Ages 22759 





Validation State: unverified 
Task: Protection 
Announcement bits (1): O-KRT 
INS jOeuclg IL 


Protecting 2 routes 





user@PE2> show route table __1.1.1.1-vpn__.inet.0 


__1.1.1.1-vpn__.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


NORE SOR SOR Oy. 214 * [Egress—Protection/170] 00:02:11 





to table vpn.inet.0 


10510). 50 0/24 








* [Egress—Protection/170] 00:02:11 
> co 1O,10,.30.2 wie Ge—3/2/4.0 


user@PE2> show route table __1.1.1.1-vpn__.inet.0 extensive 


__1.1.1.1-vpn__.inet.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 


10.10.30.0/24 


State: 


ISI 2 


(1 entry, 1 announced) 


< CalcForwarding > 


KRTIT in-kernel 10.10.30.0/24 -> {Table} 





MOPS OR ORO Aza 


State: 


ISI 8 


*Egress-Protection Preference: 170 


Next table: vpn.inet.0 
Next-hop index: 592 
Address: 0x9dc2630 





Next-hop reference count: 2 





State: < Active NoReadvrt ForwardingOnly Int Ext > 
Local AS: 65000 
Age: 2:13 








Validation State: unverified 

Task: Protection 

Announcement bits (1): O-KRT 

AMS jOeNclAg I 

Backup route 10.10.30.0 table vpn.inet.0 


(1 entry, 1 announced) 


< CalcForwarding > 


KRG keene lee KORN OR SO OV/i24 a= se MOR On SORA 





*Egress-—Protection Preference: 170 


Next hop type: Router, Next hop index: 630 
Address: 0x9dc1d90 





Next-hop reference count: 7 
Next hop: 10.10.30.2 via ge-3/2/4.0, selected 
Session Id: 0x147 





State: < Active NoReadvrt ForwardingOnly Int Ext > 
Local AS: 65000 
Age: 2:13 





Validation State: unverified 
Task: Protection 


Announcement bits (1): O-KRT 
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MS joRiclag I 
Backup route 10.10.50.0 table vpn.inet.0 





user@PE2> show route table mpls.0 label 17 


mpls.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) 
+ = Active Route, Last Active, * = Both 








7 VEN ON OO 51016 
to table vpn.inet.0, Pop 





user@PE2> show route table mpls.0 label 17 extensive 


mpls.0: 15 destinations, 15 routes (15 active, 0 holddown, 0 hidden) 
ay (1 entry, O announced) 
*VPN Preference: 0 
Next table: vpn.inet.0 
Next—-hop index: 0 
Label operation: Pop 
Load balance label: None; 
Label element ptr: 0x9db3920 
Label parent element ptr: 0x0 





Label element references: 1 





Label element child references: 0 








Label element lsp id: 0 


Address: 0x9db3990 








Next-hop reference count: 1 
State: < Active NotInstall Int Ext > 
Age: 25:30 





Validation State: unverified 
WaASIeg RUE 
ASO ate hties 





user@PE3> show route table mpls.0 


mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) 
+ = Active Route, Last Active, * = Both 








0 (MPS / Ol O02 4-186 ee meieaasteul 
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to table inet.0 



































0 (S=0) *[MPLS/0] 00:24:16, metric 1 
to table mpls.0 
iL = (MPLS / Ol) OOS 24silG, imsiereaye iL 
Receive 
2 eo MPEGS Olle Os 24 sla memeieranounl 
to table inet6.0 
2 (S=0) MES /0]] MOGZHteikG, imneiereae: il 
to table mpls.0 
ales a ME SY/Ol|MmOlOiseAl- ler mericitesrainounel 
Receive 
16 *[VPN/0] 00:24:15 
to table vpn.inet.0, Pop 
300096 (wi /S] OOsO2Z835, wei 1 
> co 10,10,12.2 wie ge-l/1l/4.0, Sivas 299920 
SOOtZ “(De /2] OWsO2833,, mercieie 1 
> to 10,10,12.2 wila ge-1/1/4.0, Sivas 299904 
300128 =| D2/S)]| WOsOZS3S mereiee 1 
> to 10,10,12.2 wla ge-1/1/4.0, Pop 
300128 (S=0) *[LDP/9] 00:02:33, metric 1 
> ico I0,10,12.2 wila ge-l/l/4.0, Poo 














user@PE3> show route table mpls.0 label 16 


mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


16 *[VPN/0] 00:24:22 
to table vpn.inet.0, Pop 





user@PE3> show route table mpls.0 label 16 extensive 


mpls.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) 
6 (1 entry, O announced) 
*VPN Preference: 0 
Next table: vpn.inet.0 
Next—-hop index: 0 


Label operation: Pop 





Load balance label: None; 
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Label element ptr: 0x31ldlec0 





Label parent element ptr: 0x0 





Label element references: 1 

Label element child references: 0 
Label element lsp id: 0 

Address: 0x31d1£30 








Next-hop reference count: 1 
State: < Active NotInstall Int Ext > 
Age: 24:24 





Validation State: unverified 
ieishee IRE 
INS jOenelag IL 


Checking the Context Identifier Route 


Purpose 


Examine the information about the context identifier (1.1.1.1). 


Action 





user@PE1> show route 1.1.1.1 


inet.0: 47 destinations, 47 routes (46 active, 0 holddown, 1 hidden) 
+ = Active Route, Last Active, * = Both 








ei, lyse = TILS=1S/15)]| OOSO4sOS, mereseske Sil 
S tO 10,10,10.2 wile oe—2/0/2.0 


inet.3: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 


+ = Active Route, Last Active, * = Both 








eis. ly/3e2 IND /S)]| OOSOL208, ireicieske IL 
Sco 1O,10,10,2 wila cS-—2/0/2.0, Pusin SOOOGA 


inet.5: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 


+ = Active Route, Last Active, * = Both 








oi Lily 32 = [IS=16/15)]| OUS04SO08, m~ercreske Sil, aeicwsie@2 il 
S cO 1O,10.10,2 wile Ga=-2/0/2.0, Pusin 2IOIS6, Pusia Z2SIIIZO (eejo)) 


user@PE2> show route 1.1.1.1 
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inet.0: 48 destinations, 49 routes (47 active, 0 holddown, 1 hidden) 








+ = Active Route, Last Active, * = Both 
ed oil ly 32 “<(MPLS/2] OOs26cOO, mecirie L6E7/7215 
Receive 
[S=$1S/LS]) OOSOAs 7. mrercsese Lil 
> cO 10,1012.) wla @e—3/0/2.0 





inet.3: 4 destinations, 4 routes (4 active, 0 holddown, O hidden) 


+ = Active Route, Last Active, * = Both 








Lei, ,l/fge [De / S| OOsO4s17, meitciese I 
> iO 10,10.12.,1 wie oS-3/0/2.0 





user@PE2> show mpls context-identifier 


ID Type Metric ContextTable 
ste ale ee eal protector Ley eT T2s — I... .imeils. © 
roca i, wWrimeicy O, wieecectcoir iI 





user@PE2> show mpls context-identifier detail 


Wis L,t,d, i 
Type: protector, Metric: 16777215, Mode: alias 
Comeexc weloleg — ili.  nimols.0, weloal obieg BIG 


eral i, Primacy O, wirotector 1 





user@PE3> show route 1.1.1.1 


inet.0: 47 destinations, 47 routes (46 active, 0 holddown, 1 hidden) 








+ = Active Route, Last Active, * = Both 
eral alee}! *([MPLS/1] 00:26:09, metric 1 
Receive 


inet.3: 4 destinations, 4 routes (4 active, 0 holddown, O hidden) 


+ = Active Route, Last Active, * = Both 








eid, ly 32 *(MPLS/1] 00:26:09, metric 1 
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Receive 


inet.5: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 
+ = Active Rout 








, Last Active, * = Both 


l,i, i. ly/32 (ISS /L5)]| OOS04s27, mercresye i, mrerermsle2 Al 
> cO 1O,10,12,2 wha ge-1/1/4.0, Pusin 299856 





user@PE3> show mpls context-identifier 


ID Type Metric ContextTable 
allesele sel leyelh primary il 


Total 1, Primary 1, Protector 0 





user@PE3> show mpls context-identifier detail 


ID) el essaly cell eal 


Type: primary, Metric: 1, Mode: alias 


Weal i, wWieamacy i, Piciecror O 
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Understanding MPLS and Path Protection on EX Series Switches 


Junos OS MPLS for Juniper Networks EX Series Ethernet Switches provides path protection to protect 
your MPLS network from label switched path (LSP) failures. 


By default, an LSP routes itself hop-by-hop from the ingress provider edge switch through the provider 
switches toward the egress provider edge switch. The LSP generally follows the shortest path as dictated 
by the local routing table, usually taking the same path as destination-based, best-effort traffic. These 
paths are “soft” in nature because they automatically reroute themselves whenever a change occurs ina 
routing table or in the status of a node or link. 


Typically, when an LSP fails, the switch immediately upstream from the failure signals the outage to the 
ingress provider edge switch. The ingress provider edge switch calculates a new path to the egress provider 
edge switch, establishes the new LSP, and then directs traffic from the failed path to the new path. This 
rerouting process can be time-consuming and prone to failure. For example, the outage signals to the 
ingress switch might get lost or the new path might take too long to come up, resulting in significant packet 
drops. 


You can configure path protection by configuring primary and secondary paths on the ingress switch. If 
the primary path fails, the ingress switch immediately reroutes traffic from the failed path to the standby 
path, eliminating the need for the ingress switch to calculate a new route and signal a new path. For 
information about configuring standby LSPs, see “Configuring Path Protection in an MPLS Network (CLI 
Procedure)” on page 280. 


Verifying Path Protection in an MPLS Network 


To verify that path protection is working correctly on EX Series switches, perform the following tasks: 


1. Verifying the Primary Path | 366 
2; Verifying the RSVP-Enabled Interfaces | 368 
3. Verifying a Secondary Path | 368 


Verifying the Primary Path 


Purpose 


Verify that the primary path is operational. 


Action 


user@switch> show mpls Isp extensive ingress 


Ingress LSP: 2 sessions 
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127 513848 
From: 127.1.9.9, State: Up, ActiveRoute: 0, LSPname: lsp_to_240 
ActivePath: primary_path_lsp_to_240 (primary) 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


= 





Primary primary_path_lsp_to_240 State: Up 
Priorities: 7 0 


SmartOptimizeTimer: 180 





Bieseuliticl sms Cl 

Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2) 
LO.SsS54 S 1Os3.4648 & 

Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPr 








20=Node-ID): 
IN Basin 2 IOs sio4 2 
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mpt 


6 Mar 11 23:58:01.684 Selected as active path: due to 'primary' 

& Mere Ii 23357800, 750 Record Rowmces ILOoSsSo2 10.3.4.2 

AL Mewe ii 23357300, 750 Us 

3 Mar di 23357800 .595 OrigimactSs Calli 

2 Weve Ii 23ea7eO00,595 CSPis Golipmcacion mesullic acesscec I10.3eg62 10,.3.4.2 
1 Maree ZS 5G: Sie Se CSP Sealed nomnrouce toward Ono) 22))2om termes 


Standby secondary_path_lsp_to_240 State: Up 
Standby secondary_path_lsp_to_240 State: Up 

Pirile@wilriess 7 0 

SmartOptimizeTimer: 180 

Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 1) 
10535552 § 

Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPr 








20=Node-ID): 











LO 535552 

7 Mar 11 23:58:01.684 Deselected as active: due to 'primary' 

6 Mar 11 23:46:17.298 Selected as active path 

& Weve di 23346c17 295 Racore INowies 5.5.5.2 

Al Weve Il ZisseAee i. 2issy Wie) 

5 Mateus see Zr Alor Gnw ic Ol @xelc ibniciacme allel 

2 Mar 11 23:46:16.760 CSPF: computation result accepted 10.3.5.2 

1 Mar 11 23:45:48.095 CSPF failed: no route toward 10.5.5.5[2 times] 
Created: Wed Mar 11 23:44:37 2009 





[Output truncated] 


Meaning 


As indicated by the ActivePath in the output, the LSP primary_path_Isp_to_240 is active. 
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Verifying the RSVP-Enabled Interfaces 


Purpose 
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Verify the status of Resource Reservation Protocol (RSVP)-enabled interfaces and packet statistics. 


Action 


user@switch> show rsvp interfaces 


RSVP interface: 1 active 
Active Subscr- Static Available 
Interface State resv iption BW BW 
ge-0/0/20.0 Up 2 100% 1000Mbps 1000Mbps 
Meaning 


Reserved Highwater 
BW mark 
Obps Obps 


This output verifies that RSVP is enabled and operational on interface ge-0/0/20.0. 


Verifying a Secondary Path 


Purpose 


Verify that a secondary path is established. 


Action 


Deactivate a switch that is critical to the primary path and then issue the following command: 


user@switch> show mpls Isp extensive 


Ingress LSP: 1 sessions 


127 050.8 
From: 127.0.0.1, State: Up, ActiveRoute: 0, LSPname: 
ActivePath: secondary_path_lsp_to_240 (secondary) 
LoadBalance: Random 
Encoding type: Packet, Switching type: Packet, GPID: 
Primary primary_path_lsp_to_240 State: Dn 





7 0 


SmartOptimizeTimer: 


IDieaLOeslic ales; 
180 





Exclude: red 


De 


Will be enqueued for recomputation in 8 second(s 


Oil We 8 I2s2siesil.,268 Siew tasdikecls in@ mMouleS tone! 
SO Wer A ISss5e25.610 Clear Calis CSE" comemeairiom 
AQ Mar V4 1523525. 610 CSPES link down, deleted: 


lsp_to_240 


IPv4 


Ae OPO re sae sO Resiemcisa 
failed 


L237 6 O.O5,4 (127 .O505180) (127 50.0. 1) <= 
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147 560,0,20 127 60.0 ,.40 


NOmGOut Cm cOwaECusl zy Or Ors sll i/ecames)| 


failed 


L270 .05.40 127.0040 


ime sreoultices cowed 1270.0, L1[1Sa2 cums] 


failed 


ORVOR OR OnE en O Py Ore-Oh 50) RAN ORO r740)) 
48 Mar 4 15:35:25.576 Deselected as active 
AW Wee 4 ISgsae25,550 No Reus icone closic 
ANS ewe 4 ISss5e25 550 P2222 
AS Waxes A 1Sss5e25.549 127.0,.0,122 Dexia 
44 Mar 4 15:33:29.839 Selected as active path 
as Mere 4 ISssse29.837 mRecowc Roures I127.0.0.20 127.0.0.40 
AD Weve A ISssse29.835 Us 
Mil Were 4 ISess3s29,756 Oricgimerce. Calli 
40 Mar 4 15:33:29.756 CSPF: computation result accepted 
39 Mare 4 LSss3s@0. 395 CSE itadibecls 
38 Mar 4 15:30:31.412 Clear Call: CSPF computation 
37 Mar 4 15:30:31.412 CSPF: link down/deleted: 
127.0 50.2(1275.0,.0.180) (127 .0.0.1) 
ORO OR On GUase 0:10) Clee OR O21 0)) 
36 Mar 4 15:30:31.379 Deselected as active 
So Maree Orley SOONG RROULC  EOwarcd™ desis 
oa Wee 4 lessOs sil, 350 Pee 22 
Ss Mee 4 ISss@ssil, sa 127.0.0.128 Devin 
32 Mar 4 15:29:05.802 Selected as active path 
31 Mer 4 ISs29s05. i301 neeorme ineweSss 127.0.0.20 127.0.0.40 
SOR Mar AS29210 sc Olli 
A) Mew A ISssZ29s05.686 OricgiinactS Cail 
28 Mar 4 15:29:05.686 CSPF: computation result accepted 
Zl) Weve “ZN Wap Ae iS) at3a2 (Sela eel ikeyels 
AS Mew A Wéseocil2 ls Cleare Calle CSPH Conpucaciom 
25 Mar 4 14:25:12.113 CSPF: link down/deleted: 
050,00 (127,050 ,2030) (12750,0.20) <> 
O50.0,0 (10.10.10 1080) (10,10.510. 10) 
*Standby secondary_path_lsp_to_240 State: Up 
Piedorilictes: 7 (0) 
SmartOptimizeTimer: 180 
Computed ERO (S [L] denotes strict [loose] hops): 


[Output truncated] 


Meaning 


(GSIPE mee rsater als) 


As indicated by the ActivePath in the output, the LSP secondary_path_Isp_to_240 is active. 
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Release History Table 
Release Description 
15.1 Starting in Junos OS Release 15.1, the enhanced point of local repair (PLR) functionality addresses 


a special scenario of egress node protection, where the PLR and the protector are co-located as 
one router. In this case, there is no need to have a bypass LSP reroute traffic during local repair. 


14.2 Starting in Junos OS Release 14.2, Junos OS supports the restoration of egress traffic when there 
is a link or node failure in the egress PE node. 


14.2 Starting in Junos OS Release 14.2, Junos OS supports the restoration of egress traffic when there 
is a link or node failure in the egress PE node. 


RELATED DOCUMENTATION 


| Basic MPLS Configuration | 37 


| Link Protection for MPLS LSPs 


IN THIS SECTION 


Link Protection | 370 

Multiple Bypass LSPs for Link Protection | 371 

Node Protection | 372 

Fast Reroute, Node Protection, and Link Protection | 373 
Configuring Link Protection on Interfaces Used by LSPs | 377 


Configuring Node Protection or Link Protection for LSPs | 385 


Configuring Inter-AS Node and Link Protection | 386 


Link Protection 


Link protection helps to ensure that traffic going over a specific interface to a neighboring router or switch 
can continue to reach this router (switch) if that interface fails. When link protection is configured for an 
interface and an LSP that traverses this interface, a bypass LSP is created that will handle this traffic if the 
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interface fails. The bypass LSP uses a different interface and path to reach the same destination. The path 
used can be configured explicitly, or you can rely on CSPF. The RSVP metric for the bypass LSP is set in 
the range of 20,000 through 29,999 (this value is not user configurable). 


If a link-protected interface fails, traffic is quickly switched to the bypass LSP. Note that a bypass LSP 
cannot share the same egress interface with the LSPs it monitors. 


In Figure 18 on page 371, link protection is enabled on Interface B between Router 1 and Router 2. It is 
also enabled on LSP A, an LSP that traverses the link between Router 1 and Router 2. If the link between 
Router 1 and Router 2 fails, traffic from LSP A is quickly switched to the bypass LSP generated by link 
protection. 


Figure 18: Link Protection Creating a Bypass LSP for the Protected Interface 


Bypass LSP for Interface B 





9017082 | 


Although LSPs traversing an interface can be configured to take advantage of link protection, it is important 
to note that it is specifically the interface that benefits from link protection. If link protection is enabled 
on an interface but not ona particular LSP traversing that interface, then if the interface fails, that LSP will 
also fail. 


NOTE: Link protection does not work on unnumbered interfaces. 


To protect traffic over the entire route taken by an LSP, you should configure fast reroute. For more 
information, see “Configuring Fast Reroute” on page 474. 


Multiple Bypass LSPs for Link Protection 


By default, link protection relies on a single bypass LSP to provide path protection for an interface. However, 
you can also specify multiple bypass LSPs to provide link protection for an interface. You can individually 
configure each of these bypass LSPs or create a single configuration for all of the bypass LSPs. If you do 
not configure the bypass LSPs individually, they all share the same path and bandwidth constraints. 


The following algorithm describes how and when an additional bypass LSP is activated for an LSP: 


1. If any currently active bypass can satisfy the requirements of the LSP (bandwidth, link protection, or 
node-link protection), the traffic is directed to that bypass. 
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2. If no active bypass LSP is available, scan through the manual bypass LSPs in first-in, first-out (FIFO) 
order, skipping those that are already active (each manual bypass can only be activated once). The first 
inactive manual bypass that can satisfy the requirements is activated and traffic is directed to that bypass. 


3. If no manual bypass LSPs are available and if the max-bypasses statement activates multiple bypass 
LSPs for link protection, determine whether an automatically configured bypass LSP can satisfy the 
requirements. If an automatically configured bypass LSP is available and if the total number of active 
automatically configured bypass LSPs does not exceed the maximum bypass LSP limit (configured with 
the max-bypasses statement), activate another bypass LSP. 


For information about how to configure multiple bypass LSPs for link protection, see “Configuring Bypass 
LSPs” on page 379. 


Node Protection 


Node protection extends the capabilities of link protection. Link protection helps to ensure that traffic 
going over a specific interface to a neighboring router can continue to reach this router if that interface 
fails. Node protection ensures that traffic from an LSP traversing a neighboring router can continue to 
reach its destination even if the neighboring router fails. 


When you enable node protection for an LSP, you must also enable link protection. Once enabled, node 
protection and link protection establish the following types of bypass LSPs: 


Next-hop bypass LSP—Provides an alternate route for an LSP to reach a neighboring router. This type 
of bypass LSP is established when you enable either node protection or link protection. 


Next-next-hop bypass LSP—Provides an alternate route for an LSP to get around a neighboring router 
en route to the destination router. This type of bypass LSP is established exclusively when node protection 
is configured. If a next-next-hop bypass LSP cannot be created, an attempt is made to signal a next-hop 
bypass LSP. 


In Figure 19 on page 372, node protection is enabled on Interface B on Router 1. Node protection is also 
enabled on LSP A, an LSP that traverses the link transiting Router 1, Router 2, and Router 3. If Router 2 
suffers a hardware or software failure, traffic from LSP A is switched to the next-next-hop bypass LSP 
generated by node protection. 


Figure 19: Node Protection Creating a Next-Next-Hop Bypass LSP 






Interface B 





Next-Next-Hop Bypass LSP for Interface B 


g017083 
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The time needed by node protection to switch traffic to a next-next-hop bypass LSP can be significantly 
longer than the time needed by link protection to switch traffic to a next-hop bypass LSP. Link protection 
relies on a hardware mechanism to detect a link failure, allowing it to quickly switch traffic to a next-hop 
bypass LSP. 


Node failures are often due to software problems on the node router. Node protection relies on the receipt 
of hello messages from a neighboring router to determine whether it is still functioning. The time it takes 
node protection to divert traffic partly depends on how often the node router sends hello messages and 
how long it takes the node-protected router to react to having not received a hello message. However, 
once the failure is detected, traffic can be quickly diverted to the next-next-hop bypass LSP. 


NOTE: 


Node protection provides traffic protection in the event of an error or interruption of the physical 
link between two routers. It does not provide protection in the event of control plane errors. 
The following provides an example of a control plane error: 


e Atransit router changes the label of a packet due to a control plane error. 


e When the ingress router receives the packet, it considers the label change to be a catastrophic 
event and deletes both the primary LSP and the associated bypass LSP. 


Fast Reroute, Node Protection, and Link Protection 


IN THIS SECTION 


LSP Protection Overview | 373 
LSP Protection Types Comparison | 374 


One-to-One Backup Implementation | 374 


Facility Backup Implementation | 375 


This document discusses the following sections: 


LSP Protection Overview 


RSVP-TE extensions establish backup label-switched path (LSP) tunnels for local repair of LSP tunnels. 
These mechanisms enable immediate re-direction of traffic onto backup LSP tunnels, in the event of a 
failure. 
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RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels, describes two different types of traffic 
protection for RSVP-signaled LSPs: 


e One-to-one backup—In this method, detour LSPs for each protected LSP is created at each potential 
point of local repair. 


e Facility backup—In this method, a bypass tunnel is created to protect a set of LSPs that have similar 
backup constraints at a potential failure point, by taking advantage of the MPLS label stacking. 


The one-to-one backup and the facility backup methods protect links and nodes during network failure, 
and can co-exist in a mixed network. 


LSP Protection Types Comparison 


In the Junos OS, the one-to-one backup of traffic protection is provided by fast reroute. Each LSP requires 
a protecting LSP to be signaled at each hop except the egress router. This method of LSP protection cannot 
be shared. 


In the facillity backup method, the LSP traffic protection is provided on the node and link. Unlike fast 
reroute, this protecting LSP can be shared by other LSPs. 


Table 11 on page 374 summarizes the traffic protection types. 


Table 11: One-to-One Backup Compared with Facility Backup 


Comparison One-to-One Backup Facility Backup 

Name of the protecting LSP Detour LSP Bypass LSP 

Sharing of the protecting LSP | Cannot be shared Can be shared by multiple 
LSPs 

Junos configuration fast-reroute node-link-protection and 

statements link-protection 


One-to-One Backup Implementation 


In the one-to-one backup method, the points of local repair maintain separate backup paths for each LSP 
passing through a facility. The backup path terminates by merging back with the primary path at a node 
called the merge point. In this approach, the merge point can be any node downstream from the protected 
facility. 


In the one-to-one backup method, an LSP is established that intersects the original LSP downstream of 
the point of link or node failure. A separate backup LSP is established for each LSP that is backed up. 


One-to-one backup is appropriate under the following circumstances: 


e Protection of a small number of LSPs relative to the total number of LSPs. 


e Path selection criteria, such as bandwidth, priority, and link coloring for detour paths is critical. 
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e Control of individual LSPs is important. 


In Figure 20 on page 375, Routers R1 and R5 are the ingress and egress routers, respectively. A protected 
LSP is established between the two routers transiting Routers R2, R3, and R4. Router R2 provides user 
traffic protection by creating a partial backup LSP that merges with the protected LSP at Router R4. This 
partial one-to-one backup LSP is called a detour. Detours are always calculated to avoid the immediate 
downstream link and node, providing against both link and node failure. 


Figure 20: One-to-One Backup 


Ingress Egress 
R1 R2 R3 R4 RS 
R6 R7 R8 | RQ 

Upstream Downstream 

— —_—> 


—— Protected LSP 
Detour 


g042701 





In the example, the protected LSP is R1-R2-R3-R4-R5, and the following detours are established: 


e Router R1—R1-R6-R7-R8-R3 
e Router R2—R2-R7-R8-R4 

e Router R3—R3-R8-R9-R5 

e Router R4A—R4-R9-R5 


To protect an LSP that traverses N nodes fully, there can be as many as (N - 1) detours. The point of local 
repair sends periodic refresh messages to maintain each backup path, as a result maintaining state 
information for backup paths protecting individual LSPs is a significant resource burden for the point of 
local repair. To minimize the number of LSPs in the network, it is desirable to merge a detour back to its 
protected LSP, when feasible. When a detour LSP intersects its protected LSP at an LSR with the same 
outgoing interface, it is merged. 


Facility Backup Implementation 


In the facility backup approach, a point of local repair maintains a single backup path to protect a set of 
primary LSPs traversing the point of local repair, the facility, and the merge point. The facility backup is 
based on interface rather than on LSP. While fast reroute protects interfaces or nodes along the entire 


path of a LSP, the facility backup protection can be applied on interfaces as needed. As a result, fewer 
states need to be maintained and refreshed which results in a scalable solution. The facility backup method 
is also called many-to-one backup. 


The facility backup method takes advantage of the MPLS label stack. Instead of creating a separate LSP 
for every backed-up LSP, a single LSP is created that serves to back up a set of LSPs. Such an LSP tunnel 
is called a bypass tunnel. In this method, a router immediately upstream from a link failure uses an alternate 
interface to forward traffic to its downstream neighbor, and the merge point should be the node immediately 
downstream to the facility. This is accomplished by preestablishing a bypass path that is shared by all 
protected LSPs traversing the failed link. A single bypass path can safeguard a set of protected LSPs. When 
an outage occurs, the router immediately upstream from the link outage switches protected traffic to the 
bypass link, then signals the link failure to the ingress router. 


The bypass tunnel must intersect the path of the original LSP(s) somewhere downstream of the point of 

local repair. This constrains the set of LSPs being backed up through that bypass tunnel to those that pass 
through some common downstream nodes. All LSPs that pass through the point of local repair and through 
this common node, and that do not also use the facilities involved in the bypass tunnel are candidates for 
this set of LSPs. 


The facility backup method is appropriate in the following situations: 


e The number of LSPs to be protected is large. 
e Satisfying path selection criteria (priority, bandwidth, and link coloring) for bypass paths is less critical. 


e Control at the granularity of individual LSPs is not required. 


In Figure 21 on page 377, Routers R1 and R5 are the ingress and egress routers, respectively. Router R2 
has established a bypass tunnel that protects against the failure of Router R2-R3 link and Router R3 node. 
A bypass tunnel is established between Routers R6 and R7. There are three different protected LSPs that 
are using the same bypass tunnel for protection. 
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Figure 21: Facility Backup 
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The facility backup method provides a scalability improvement, wherein the same bypass tunnel is also 
used to protect LSPs from any of RoutersR1, R2, or R8 to any of Routers R4, R5, or RY. 


Configuring Link Protection on Interfaces Used by LSPs 
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When you configure node protection or link protection on a router for LSPs as described in “Configuring 
Node Protection or Link Protection for LSPs” on page 385, you also must configure the link-protection 
statement on the RSVP interfaces used by the LSPs. 


To configure link protection on the interfaces used by the LSPs, include the link-protection statement: 


link-protection { 
disable; 
admin-group 
exclude group-names; 
include-all group-names; 
include-any group-names; 
} 
bandwidth bps; 
bypass bypass-name { 
bandwidth bps; 
description text; 
hop-limit number; 
no-cspf; 
path address <strict | loose>; 
priority setup-priority reservation-priority; 
to address; 
} 
class-of-service cos-value; 
hop-limit number; 
max-bypasses number; 
no-cspf; 
no-node-protection; 
optimize-timer seconds; 
path address <strict | loose>; 
priority setup-priority reservation-priority; 
subscription percent { 
ctO percent; 
ct1 percent; 
ct2 percent; 
ct3 percent; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp interface interface-name] 
e [edit logical-systems logical-system-name protocols rsvp interface interface-name] 


All the statements under link-protection are optional. 


The following sections describe how to configure link protection: 


Configuring Bypass LSPs 


You can configure specific bandwidth and path constraints for a bypass LSP. Each manual bypass LSP on 
a router should have a unique “to” IP address. You can also individually configure each bypass LSP generated 
when you enable multiple bypass LSPs. If you do not configure the bypass LSPs individually, they all share 
the same path and bandwidth constraints (if any). 


If you specify the bandwidth, hop-limit, and path statements for the bypass LSP, these values take 
precedence over the values configured at the [edit protocols rsvp interface interface-name link-protection] 
hierarchy level. The other attributes (subscription, no-node-protection, and optimize-timer) are inherited 
from the general constraints. 


To configure a bypass LSP, specify a name for the bypass LSP using the bypass statement. The name can 
be up to 64 characters in length. 


bypass bypass-name { 
bandwidth bps; 
description text; 
class-of-service cos-value; 
hop-limit number; 
no-cspf; 
path address <strict | loose>; 
priority setup-priority reservation-priority; 
to address; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp interface interface-name link-protection] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection] 


Configuring the Next-Hop or Next-Next-Hop Node Address for Bypass LSPs 


If you configure a bypass LSP, you must also configure the to statement. The to statement specifies the 
address for the interface of the immediate next-hop node (for link protection) or the next-next-hop node 
(for node-link protection). The address specified determines whether this is a link protection bypass or a 
node-link protection bypass. On multiaccess networks (for example, a LAN), this address is also used to 
specify which next-hop node is being protected. 


Configuring Administrative Groups for Bypass LSPs 


Administrative groups, also known as link coloring or resource class, are manually assigned attributes that 
describe the “color” of links, such that links with the same color conceptually belong to the same class. 
You can use administrative groups to implement a variety of policy-based LSP setups. You can configure 
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administrative groups for bypass LSPs. For more information about configuring administrative groups, see 
“Configuring Administrative Groups for LSPs” on page 503. 


To configure administrative groups for bypass LSPs, include the admin-group statement: 
admin-group { 
exclude group-names; 


include-all group-names; 
include-any group-names; 


To configure an administrative group for all of the bypass LSPs, include the admin-group statement at the 
following hierarchy levels: 


e [edit protocols rsvp interface interface-name link-protection] 
e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection] 


To configure an administrative groups for a specific bypass LSP, include the admin-group statement at 
the following hierarchy levels: 


e [edit protocols rsvp interface interface-name link-protection bypass bypass-name] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass 
bypass-name] 


Configuring the Bandwidth for Bypass LSPs 


You can specify the amount of bandwidth allocated for automatically generated bypass LSPs or you can 
individually specify the amount of bandwidth allocated for each LSP. 


If you have enabled multiple bypass LSPs, this statement is required. 


To specify the bandwidth allocation, include the bandwidth statement: 


bandwidth bps; 
For automatically generated bypass LSPs, include the bandwidth statement at the following hierarchy 
levels: 
e [edit protocols rsvp interface interface-name link-protection] 
e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection] 
For individually configured bypass LSPs, include the bandwidth statement at the following hierarchy levels: 


e [edit protocols rsvp interface interface-name link-protection bypass bypass-name] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass 
bypass-name] 


Configuring Class of Service for Bypass LSPs 


You can specify the class-of-service value for bypass LSPs by including the class-of-service statement: 


class-of-service cos-value; 


To apply a class-of-service value to all the automatically generated bypass LSPs, include the class-of-service 
statement at the following hierarchy levels: 


e [edit protocols rsvp interface interface-name link-protection] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection] 


To configure a class-of-service value for a specific bypass LSPs, include the class-of-service statement at 
the following hierarchy levels: 


e [edit protocols rsvp interface interface-name link-protection bypass bypass-name] 
e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass 


bypass-name] 


Configuring the Hop Limit for Bypass LSPs 


You can specify the maximum number of hops a bypass can traverse. By default, each bypass can traverse 
a maximum of 255 hops (the ingress and egress routers count as one hop each, so the minimum hop limit 
is two). 


To configure the hop limit for bypass LSPs, include the hop-limit statement: 


hop-limit number; 


For automatically generated bypass LSPs, include the hop-limit statement at the following hierarchy levels: 


e [edit protocols rsvp interface interface-name link-protection] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection] 
For individually configured bypass LSPs, include the hop-limit statement at the following hierarchy levels: 


e [edit protocols rsvp interface interface-name link-protection bypass bypass-name] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass 
bypass-name] 


Configuring the Maximum Number of Bypass LSPs 


You can specify the maximum number of dynamic bypass LSPs permitted for protecting an interface using 
the max-bypasses statement at the [edit protocols rsvp interface interface-name link-protection] hierarchy 
level. When this statement is configured, multiple bypasses for link protection are enabled. Call admission 
control (CAC) is also enabled. 
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By default, this option is disabled and only one bypass is enabled for each interface. You can configure a 
value of between 0 through 99 for the max-bypasses statement. Configuring a value of O prevents the 

creation of any dynamic bypass LSPs for the interface. If you configure a value of O for the max-bypasses 
statement, you need to configure one or more static bypass LSPs to enable link protection on the interface. 


If you configure the max-bypasses statement, you must also configure the bandwidth statement (discussed 
in “Configuring the Bandwidth for Bypass LSPs” on page 380). 


To configure the maximum number of bypass LSPs for a protected interface, include the max-bypasses 


statement: 


max-bypasses number, 


You can include this statement at the following hierarchy levels: 
e [edit protocols rsvp interface interface-name link-protection] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection] 


Disabling CSPF for Bypass LSPs 


Under certain circumstances, you might need to disable CSPF computation for bypass LSPs and use the 
configured Explicit Route Object (ERO) if available. For example, a bypass LSP might need to traverse 
multiple OSPF areas or IS-IS levels, preventing the CSPF computation from working. To ensure that link 
and node protection function properly in this case, you have to disable CSPF computation for the bypass 
LSP. 


You can disable CSPF computation for all bypass LSPs or for specific bypass LSPs. 


To disable CSPF computation for bypass LSPs, include the no-cspf statement: 


no-cspf; 


For a list of hierarchy levels where you can include this statement, see the statement summary for this 
statement. 


Disabling Node Protection for Bypass LSPs 


You can disable node protection on the RSVP interface. Link protection remains active. When this option 
is configured, the router can only initiate a next-hop bypass, not a next-next-hop bypass. 


To disable node protection for bypass LSPs, include the no-node-protection statement: 


no-node-protection; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp interface interface-name link-protection] 
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e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection] 


Configuring the Optimization Interval for Bypass LSPs 


You can configure an optimization interval for bypass LSPs using the optimize-timer statement. At the 
end of this interval, an optimization process is initiated that attempts to either minimize the number of 
bypasses currently in use, minimize the total amount of bandwidth reserved for all of the bypasses, or 

both. You can configure an optimization interval from 1 through 65,535 seconds. A default value of O 

disables bypass LSP optimization. 


When you configure the optimize-timer statement, bypass LSPs are reoptimized automatically when you 
configure or change the configuration of any of the following: 


e Administrative group for a bypass LSP—The configuration for an administrative group has been changed 
ona link along the path used by the bypass LSP. Configure an administrative group using the admin-group 
statement at the [edit protocols rsvp interface interface-name link-protection] hierarchy level. 


Fate sharing group—The configuration for a fate sharing group has been changed. Configure a fate 
sharing group using the group statement at the [edit routing-options fate-sharing] hierarchy level. 


IS-IS overload—The configuration for IS-IS overload has been changed on a router along the path used 
by the bypass LSP. Configure IS-IS overload using the overload statement at the [edit protocols isis] 
hierarchy level. 


e IGP metric—The IGP metric has been changed on a link along the path used by the bypass LSP. 


To configure the optimization interval for bypass LSPs, include the optimize-timer statement: 


optimize-timer seconds; 


You can include this statement at the following hierarchy levels: 
e [edit protocols rsvp interface interface-name link-protection] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection] 


Configuring an Explicit Path for Bypass LSPs 


By default, when you establish a bypass LSP to an adjacent neighbor, CSPF is used to discover the least-cost 
path. The path statement allows you to configure an explicit path (a sequence of strict or loose routes), 
giving you control over where and how the bypass LSP is established. To configure an explicit path, include 
the path statement: 


path address <strict | loose>; 


For automatically generated bypass LSPs, include the path statement at the following hierarchy levels: 


e [edit protocols rsvp interface interface-name link-protection] 
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e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection] 
For individually configured bypass LSPs, include the path statement at the following hierarchy levels: 


e [edit protocols rsvp interface interface-name link-protection bypass bypass-name] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass 
bypass-name] 


Configuring the Amount of Bandwidth Subscribed for Bypass LSPs 


You can configure the amount of bandwidth subscribed to bypass LSPs. You can configure the bandwidth 
subscription for the whole bypass LSP or for each class type that might traverse the bypass LSP. You can 
configure any value between 1 percent and 65,535 percent. By configuring a value less than 100 percent, 
you are undersubscribing the bypass LSPs. By configuring a value greater than 100 percent, you are 
oversubscribing the bypass LSPs. 


The ability to oversubscribe the bandwidth for the bypass LSPs makes it possible to more efficiently use 
network resources. You can configure the bandwidth for the bypass LSPs based on the average network 
load as opposed to the peak load. 


To configure the amount of bandwidth subscribed for bypass LSPs, include the subscription statement: 
subscription percentage { 
ctO percentage; 
ct1 percentage; 


ct2 percentage; 
ct3 percentage; 


You can include this statement at the following hierarchy levels: 
e [edit protocols rsvp interface interface-name link-protection] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection] 


Configuring Priority and Preemption for Bypass LSPs 


When there is insufficient bandwidth to establish a more important LSP, you might want to tear down a 
less important existing LSP to release the bandwidth. You do this by preempting the existing LSP. 


For more detailed information on configuring setup priority and reservation priority for LSPs, see 
“Configuring Priority and Preemption for LSPs” on page 502. 


To configure the bypass LSP’s priority and preemption properties, include the priority statement: 


priority setup-priority reservation-priority; 
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For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Configuring Node Protection or Link Protection for LSPs 


When you configure node protection or link protection on a router or switch, bypass LSPs are created to 
the next-hop or next-next-hop routers (switches) for the LSPs traversing the router (switch). You must 

configure node protection or link protection for each LSP that you want protected. To extend protection 
along the entire path used by an LSP, you must configure protection on each router that the LSP traverses. 


You can configure node protection or link protection for both static and dynamic LSPs. 


To configure node protection on a router for a specified LSP, include the node-link-protection statement: 


node-link-protection; 


You can include this statement at the following hierarchy levels: 
e [edit protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


To configure link protection on a router for a specified LSP, include the link-protection statement: 


link-protection; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


NOTE: To complete the configuration of node or link protection, you must also configure link 
protection on all unidirectional RSVP interfaces that the LSPs traverse, as described in “Configuring 
Link Protection on Interfaces Used by LSPs” on page 377. 
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Configuring Inter-AS Node and Link Protection 


To interoperate with other vendors’ equipment, the Junos OS supports the record route object (RRO) node 
ID subobject for use in inter-AS link and node protection configurations. The RRO node ID subobject is 
defined in RFC 4561, Definition of a Record Route Object (RRO) Node-Id Sub-Object. This functionality is 
enabled by default in Junos OS Release 9.4 and later. 


If you have Juniper Networks routers running Junos OS Release 9.4 and later releases in the same MPLS-TE 
network as routers running Junos OS Release 8.4 and earlier releases, you might need to disable the RRO 
node ID subobject by configuring the no-node-id-subobject statement: 


no-node-id-subobject; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 
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Configuring MPLS to Gather Statistics 


You can configure MPLS so that it periodically gathers traffic statistics about all MPLS sessions, including 
transit sessions, by configuring the statistics statement. You must configure the statistics statement if you 
want to collect MPLS traffic statistics using SNMP polling of MPLS Management Information Bases (MIBs). 


To enable or disable MPLS statistics collection, include the statistics statement: 


statistics { 
auto-bandwidth (MPLS Statistics); 
file filename <files number> <size size> <world-readable | no-world-readable>; 
interval seconds; 
no-transit-statistics; 


transit-statistics-polling; 


You can configure these statements at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


The default interval is 300 seconds. 


If you configure the file option, the statistics are placed in a file, with one entry per LSP. During the specified 


interval, the following information is recorded in this file: 


e Thenumber of packets, number of bytes, packets per second, and bytes per second transmitted by each 
LSP. Feature parity for the display of packet and byte statistics for sub-LSPs of a point-to-multipoint 
LSP on the Junos Trio chipset is supported in Junos OS Releases 11.1R2, 11.2R2, and 11.4. 


e The percent of bandwidth transmitted over a given LSP in relation to the bandwidth percentage configured 
for that LSP. If no bandwidth is configured for an LSP, O percent is recorded in the percentage column. 


At the end of each periodic report, a summary shows the current time, total number of sessions, number 
of sessions read, number of sessions ignored, and read errors, if any. Ignored sessions are typically those 
not in the up state or those with a reserved (0 through 15) incoming label (typically the egress point of an 
LSP). The reason for a read error appears on the same line as the entry for the LSP on which the error 

occurred. Gathering statistics is an unreliable process; occasional read errors might affect their accuracy. 


Sample output follows: 
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This topic describes methods for measuring packet loss, delay, and throughput for point-to-point ultimate 
hop popping (UHP) label-switched paths (LSPs) in MPLS networks to enable monitoring of network 
performance. 


Importance of Measuring Packet Loss and Delay 


The rise of bandwidth-consuming applications, such as IPTV and mobile video, coupled with the pressure 
to minimize the cost per bit and maximize the value per bit, is forcing carriers to transition their transport 
networks from circuit-based technologies to packet-based technologies. MPLS is a widely successful, 

connection-oriented packet transport technology that is ideally suited for packet-based transport networks. 


With the emergence of new applications on data networks, it is becoming increasingly important for service 
providers to accurately predict the impact of new application rollouts. Understanding and modelling network 
performance in the network is especially relevant for deployment of new-world applications to ensure 
successful implementations. In packet networks, packet loss and delay are two of the most fundamental 
measures of performance. Their role is even more central when it comes to end-to-end measurements. 


The traffic belonging to most of the end-to-end user applications is either loss sensitive (file transfer), 
delay sensitive (voice or video applications), or both (interactive computing applications). The service-level 
agreements (SLAs) of service providers depend on the ability to measure and monitor these network 
performance metrics, as the SLAs are directly or indirectly dependent on the loss and delay the customer 
traffic experiences in the service provider network. 


To ensure compliance to the SLA, service providers need tools to measure and monitor the performance 
metrics for packet loss, one-way delay and two-way delay, and related metrics, such as delay variation 
and channel throughput. This measurement capability provides service providers with greater visibility 
into the performance characteristics of their networks, thereby facilitating planning, troubleshooting, and 
network performance evaluation. 


Defining Packet Loss, Delay, and Throughput 


In packet networks, packet loss and delay are two of the most fundamental measures of performance. 


e Loss—Packet loss is the failure of one or more transmitted packets to arrive at their destination. Packet 
loss refers to the packets of data that are dropped by the network to manage congestion. 
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Data applications are very tolerant to packet loss, as they are generally not time sensitive and can 
retransmit the packets that were dropped. However, in video conference environments and pure audio 
communications, such as VoIP, packet loss can create jitter. 


Delay—Packet delay (also called latency) is the amount of time it takes for a packet of data to get from 
one designated point to another, depending on the speed of the transmission medium, such as copper 


wire, optical fiber, or radio waves, and the delays in transmission by devices along the way, such as 
routers and modems. 


A low latency indicates a high network efficiency. 


Throughput—Packet delay measures the amount of time between the start of an action and its completion, 
whereas throughput is the total number of such actions that occur in a given amount of time. 


Packet Loss and Delay Measurement Mechanisms 


Packet delay and loss are two fundamental measures of network performance. Junos OS provides an 
on-demand mechanism to measure packet loss and delay over associated bidirectional MPLS ultimate hop 
popping (UHP) label-switched paths (LSPs). 


The on-demand delay and packet loss measurement mechanism is initiated using the following CLI 
commands: 


e monitor mpls loss rsvp—Performs an on-demand loss measurement for associated bidirectional UHP 
LSPs. 


e monitor mpls delay rsvp—Performs an on-demand delay measurement for associated bidirectional UHP 
LSPs. 


e monitor mpls loss-delay rsvp—Performs an on-demand combined loss and delay measurement for 
associated bidirectional UHP LSPs. 


For initiating the delay and packet loss measuring mechanism, the desired parameters for measurement, 
such as the type of measurement and LSP name, need to be entered. On receiving the parameters, a 
summary of the performance monitoring data is displayed and the mechanism is terminated. 


Packet Loss and Delay Metrics 

The following performance metrics are measured using the on-demand packet loss and delay mechanisms: 
e Loss measurement (packet and octet) 

e Throughput measurement (packet and octet) 

e Two-way channel delay 

e Round-trip delay 

e Inter-packet delay variation (IPDV) 


The monitor mpls loss rsvp command performs the loss and throughput measurement, and the monitor 
mpls delay rsvp command performs the two-way channel delay, round-trip delay, and IPDV measurements. 


The monitor mpls loss-delay rsvp command performs a combined loss and delay measurement and measures 
all of the above-mentioned performance metrics simultaneously. 


Packet Loss and Delay Measurement Concepts 
The following concepts help to better understand the functionality of packet loss and delay: 


e Querier—A querier is the ingress provider edge (PE) router, which originates the query message for loss 
or delay measurement. 


e Responder—A responder is the egress PE router, which receives and responds to the query messages 
from a querier. 


e Associated bidirectional LSP—An associated bidirectional LSP consists of two unidirectional LSPs that 
are tied together (or associated with each other) through configuration on both of the LSP end points. 


The on-demand loss and delay measurement can be carried out only on associated bidirectional UHP 
LSPs. 


e Generic associated channel (G-Ach)—The performance monitoring messages for the on-demand loss 
and delay measurement flow over the MPLS G-Ach. This type of channel supports only in-band responses, 
and does not provide support for out-of-band or no-response modes. 


e Measurement point (MP)—MP is the location at which a condition is described for the measurement. 


The MP for packet loss on the transmit side is between the switching fabric and the transmit interface. 
The counter value is stamped in the loss measurement message in the hardware before it is queued for 
transmission. 


The MP for packet loss on the receive side is between the receive interface and the switching fabric. 
The MP is distributed on the receive side. Furthermore, when the transmit interface is an aggregate 
interface, the MP is distributed as well. 


Query rate—Query rate is the interval between two queries sent for loss and delay measurement. 


Because the loss and delay measurement messages originate from the Routing Engine, a high query rate 
for multiple channels puts a heavy burden on the Routing Engine. The minimum query interval supported 
is 1 second. 


The query rate should be high for 32-bit counters, because the counters might wrap quickly when data 
traffic rate is very high. The query rate can be low when 64-bit counters are in use at all the four 
measurement point locations involved in loss measurement. Junos OS supports only 64-bit counters. 


Traffic class—By default, loss measurement is supported for the whole channel. Junos OS also supports 


traffic class scoped packet loss measurement, where counters that maintain data traffic statistics per 
traffic class have to be created. 


Per traffic class counters are not created by default. To configure traffic class scoped loss measurement, 
include the traffic-class-statistics statement at the [edit protocols mpls statistics] hierarchy level. 


When traffic-class-statistics is configured, control packets flowing over the G-Ach are not counted in 
the transmit and receive counters. 
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NOTE: Enabling and disabling of traffic class statistics results in the resetting of all counters 
(aggregate counter and per-class counters) for the LSPs. 


Loss measurement mode—Junos OS supports the direct-mode of on-demand loss measurement, and 
does not provide support for the inferred-mode. 


Direct loss measurement requires data traffic statistics to be maintained at the ingress and egress of 
two unidirectional LSPs of the associated bidirectional LSP. When an MX Series router is using only 
MPCs and MICs, counters to maintain data traffic statistics are created by default at the ingress of all 
types of LSPs and egress of UHP LSPs. 


However, the direct-mode of loss measurement is not fully accurate due to the following reasons: 


Parallel forwarding nature of the hardware. 


Presence of equal cost multipath (ECMP) in the network, such as aggregated Ethernet interfaces, 


which can result in re-ordering of data packets relative to the loss measurement messages. 


Control packets that do not flow over G-Ach are not counted at the LSP ingress, but are counted at 
the LSP egress. 


Data traffic re-ordering relative to the loss measurement message when a Diffserv is implemented in 


the MPLS network and loss measurement scope is the complete channel and not traffic class scoped. 


To overcome this limitation, perform traffic class scoped loss measurement when a Diffserv is 
implemented. 


NOTE: Direct mode loss measurement is vulnerable to disruption when the ingress or egress 
interface associated with the LSP changes. 


Loss measurement synchronization—The synchronization conditions specified in section 2.9.8 of RFC 
6374 do not hold true in the absolute sense. However, as the loss measurement counters are stamped 
in hardware, the errors introduced due to not satisfying the synchronization conditions are relatively 
small. These errors need to be quantified. 


When the transmit or receive interface of the LSP is an aggregate interface, more errors are introduced 
as compared to when the interfaces are non-aggregate interfaces. In any case, the loss measurement 
counters are stamped in hardware, and the error needs to be quantified. 


Delay measurement accuracy—When the transmit and receive interfaces reside on different Packet 
Forwarding Engines, the clock must be synchronized on these Packet Forwarding Engines for two-way 
delay measurements. This condition holds true for the platform on which the on-demand delay 
measurement feature is implemented. 


When there are aggregate interfaces or ECMP, the delay is measured for only one of the potential paths. 


When a combined loss and delay message is used for delay calculation, the accuracy of delay is lower 
compared to when the delay measurement message is used in some cases, such as when the transmit 
or receive interface is an aggregate interface. 


Delay measurement is always performed on a per-traffic-class basis, and the accuracy of the measurement 
needs to be quantified after testing. 


e Timestamp format—Junos OS supports only the IEEE 1588 Precision Time Protocol (PTP) [IEEE1588] 
format for recording delay measurement messages. Network Time Format (NTP) is not supported. 


e Operations, administration, and maintenance (OAM)—To indicate that all the OAM messages for MPLS 
LSPs flow over the MPLS G-Ach, and to enable the MPLS performance monitoring messages to be carried 
over the MPLS G-Ach, the oam mpls-tp-mode statement must be included at the [edit protocols mpls 
label-switched-path Isp-name] hierarchy level. 


Packet Loss and Delay Measurement Functionality 


Figure 22 on page 393 illustrates the basic methods used for the bidirectional measurement of packet loss 
and delay. A bidirectional channel exists between the two routers, Router A and Router B. The temporal 
reference points - T1, T2, T3, and T4 - are associated with a measurement operation that takes place at 
Router A. The operation consists of Router A sending a query message to Router B, and Router B sending 
back a response. Each reference point indicates the point of time at which either the query or the response 
message is transmitted or received over the channel. 


Figure 22: Basic Bidirectional Measurement 
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In Figure 22 on page 393, Router A can arrange to measure the packet loss over the channel in the forward 
and reverse directions by sending loss measurement query messages to Router B. Each of the forward 
and reverse messages contain the count of packets transmitted prior to time T1 over the channel to Router 
B (A_TxP). 


When the message reaches Router B, two values are appended to the message and the message is reflected 
back to Router A. The two values are the count of packets received prior to time T2 over the channel from 
Router A (B_RxP) and the count of packets transmitted prior to time T3 over the channel to Router A 
(B_TxP). 


When the response reaches Router A, a fourth value is appended to the message - the count of packets 
received prior to time T4 over the channel from Router B (A_RxP). 


These four counter values - (A_TxP), (B_RxP), (B_TxP), and (A_RxP) - enable Router A to compute the 
desired loss statistics. Because the transmit count at Router A and the receive count at Router B (and vice 
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versa) might not be synchronized at the time of the first message, and to limit the effects of counter wrap, 
the loss is computed in the form of a delta between the messages. 


The transmit loss (A_TxLoss[n-1,n]) and receive loss (A_RxLoss[n-1,n]) within the measurement interval 
marked by the messages LM[n-1] and LM[n] are computed by Router A as follows: 


A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1]) 
A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1]) 
The arithmetic is modulo the counter size. 


To measure at Router A the delay over the channel to Router B, a delay measurement query message is 
sent from Router A to Router B containing a timestamp recording the instant at which it is transmitted. In 
Figure 22 on page 393, the timestamp is recorded in T1. 


When the message reaches Router B, a timestamp is added, recording the instant at which it is received 
(T2). The message can now be reflected from Router B to Router A, with Router B adding its transmit 
timestamp (T3) and Router A adding its receive timestamp (T4). 


These four timestamps - T1, T2, T3, and T4 - enable Router A to compute the one-way delay in each 
direction, as well as the two-way delay for the channel. The one-way delay computations require that the 
clocks of Routers A and B be synchronized. 


At this point, Router A can compute the two-way channel delay and round-trip delay associated with the 
channel as follows: 


Two-way channel delay = (T4 - T1) - (T3 - T2) 
Round-trip delay = T4 - T1 


Packet Loss and Delay Features 


Supported Features of Packet Loss and Delay 
Junos OS supports the following features with on-demand loss and delay measurement: 


e Performance monitoring for associated bidirectional MPLS point-to-point UHP LSPs only 
e Loss measurement 

e Throughput measurement 

e Two-way delay measurement (channel delay and round-trip delay) 

e Inter-packet delay variation (IPDV) 

e Direct-mode loss measurement 

e Aggregated Ethernet and aggregated SONET interfaces 

e Multichassis support 


e 64-bit compatible 
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Unsupported Features of Packet Loss and Delay 
Junos OS does not support the following on-demand loss and delay measurement functionality: 


Loss and delay measurement for pseudowires (section 2.9.1 of RFC 6374) 


Unidirectional measurement (section 2.6 of RFC 6374) 


e Dyadic measurement (section 2.7 of RFC 6374) 


Loss and delay measurement in loopback mode (section 2.8 of RFC 6374) 


Loss and delay measurement to an intermediate node from an LSP endpoint (section 2.9.5 of RFC 6374) 


External post-processing (section 2.9.7 of RFC 6374) 


Inferred-mode loss measurement (section 2.9.8 of RFC 6374) 


Pro-active mode 


Logical systems 


e SNMP 


Example: Configuring On-Demand Loss and Delay Measurement 


IN THIS SECTION 


Requirements | 395 
Overview | 396 
Configuration | 396 


Verification | 401 


This example shows how to enable on-demand loss and delay measurement for point-to-point ultimate 
hop popping (UHP) label-switched paths (LSPs) in MPLS networks to monitor network performance. 


Requirements 


This example uses the following hardware and software components: 


e Two Mx Series 5G Universal Routing Platforms that contain MPC/MICs only 


e Junos OS Release 14.2 or later running on all the routers 
Before you begin: 


1. Configure the device interfaces. 
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2. Configure the autonomous system numbers and router IDs for the devices. 
3. Configure the following protocols: 

e RSVP 

e MPLS 

e OSPF 


Overview 


Starting with Junos OS Release 14.2, an on-demand tool to monitor and measure packet loss, packet delay, 
or both for associated bidirectional MPLS ultimate hop popping (UHP) point-to-point label-switched paths 
(LSPs) is introduced. The tool can be enabled using the following CLI commands - monitor mpls loss rsvp, 
monitor mpls delay rsvp, and monitor mpls loss-delay rsvp. 


These commands provide an on-demand summary of performance metrics for direct mode packet loss, 
two-way packet delay, and related metrics, such as inter-packet delay variation and channel throughput 
measurement. 


This functionality provides real-time visibility into network performance, thereby facilitating network 
performance planning, troubleshooting, and evaluation. 


Topology 


Figure 23 on page 396 illustrates the on-demand loss and delay measurement using a simple two-router 
topology. 


Figure 23: Configuring On-Demand Loss and Delay Measurement 


R1 R2 
ge-0/0/0 ge-0/0/0 
1.1.1.1/30 1.1.1.2/30 & 
m 
+ 
loO0=10.0.0.1/32 lo0=20.0.0.1/32 & 


In this example, an associated bidirectional LSP is configured between Routers R1 and R2, for which the 
performance metrics is measured. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


R1 


R2 


set chassis fpc O pic 3 tunnel-services bandwidth 1g 

set chassis network-services enhanced-ip 

set interfaces ge-0/0/0 unit 0 family inet address 1.1.1.1/30 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces loO unit O family inet address 10.0.0.1/32 

set interfaces loO unit O family mpls 

set routing-options router-id 10.0.0.1 

set protocols rsvp interface ge-0/0/0.0 

set protocols rsvp interface lo0.0 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls statistics traffic-class-statistics 

set protocols mpls label-switched-path R1-R2 to 20.0.0.1 

set protocols mpls label-switched-path R1-R2 oam mpls-tp-mode 
set protocols mpls label-switched-path R1-R2 ultimate-hop-popping 
set protocols mpls label-switched-path R1-R2 associate-Isp R2-R1 
set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface lo0.0 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


set chassis fpc O pic 3 tunnel-services bandwidth 1g 

set chassis network-services enhanced-ip 

set interfaces ge-0/0/0 unit 0 family inet address 1.1.1.2/30 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces loO unit O family inet address 20.0.0.1/32 

set interfaces loO unit O family mpls 

set routing-options router-id 20.0.0.1 

set protocols rsvp interface ge-0/0/0.0 

set protocols rsvp interface lo0.0 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls statistics traffic-class-statistics 

set protocols mpls label-switched-path R2-R1 to 10.0.0.1 

set protocols mpls label-switched-path R2-R1 oam mpls-tp-mode 
set protocols mpls label-switched-path R2-R1 ultimate-hop-popping 
set protocols mpls label-switched-path R2-R1 associate-Isp R1-R2 
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set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface lo0.0 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 
set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0.interface fxp0.0 disable 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Router R1: 


1. Enable the chassis with tunnel services and enhanced IP network services configuration. 


[edit chassis] 
user@R1# set fpc 0 pic 3 tunnel-services bandwidth 1g 
user@R1# set network-services enhanced-ip 


2. Configure the interfaces for Router R1. 


[edit interfaces] 

user@R1# set ge-0/0/0 unit 0 family inet address 1.1.1.1/30 
user@R1# set ge-0/0/0 unit 0 family mpls 

user@R1# set loO unit O family inet address 10.0.0.1/32 
user@R1# set loO unit 0 family mpls 


3. Configure the router ID for Router R1. 


[edit routing-options] 
user@R1# set router-id 10.0.0.1 


4. Enable RSVP on all the interfaces of Router R1, excluding the management interface. 


[edit protocols] 
user@R1# set rsvp interface ge-0/0/0.0 
user@R1# set rsvp interface lo0.0 
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user@R1# set rsvp interface fxp0.0 disable 


5. Enable MPLS on all the interfaces of Router R1, excluding the management interface. 


[edit protocols] 

user@R1# set mpls interface ge-0/0/0.0 
user@R1# set mpls interface lo0.0 
user@R1# set mpls interface fxp0.0 disable 


6. Configure an associated bidirectional LSP to Router R2. 


[edit protocols] 

user@R1# set mpls label-switched-path R1-R2 to 20.0.0.1 

user@R1# set mpls label-switched-path R1-R2 oam mpls-tp-mode 
user@R1# set mpls label-switched-path R1-R2 ultimate-hop-popping 
user@R1# set mpls label-switched-path R1-R2 associate-Isp R2-R1 


7. Create traffic classes for maintaining data traffic statistics per traffic class. 


This enables traffic class scoped loss measurement. 


[edit protocols] 
user@R1# set mpls statistics traffic-class-statistics 


8. Configure OSPF with traffic engineering capabilities, and enable OSPF on all the interfaces of Router 
R1, excluding the management interface. 


[edit protocols] 

user@R1# set ospf traffic-engineering 

user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 
user@R1# set ospf area 0.0.0.0 interface lo0.0 
user@R1# set ospf interface fxp0.0 disable 


Results 


From configuration mode, confirm your configuration by entering the show chassis, show interfaces, show 
routing-options, and show protocols commands. If the output does not display the intended configuration, 
repeat the instructions in this example to correct the configuration. 


user@R1# show chassis 
fpc O { 
pic 3 { 
tunnel-services { 
bandwidth 1g; 


} 


network-services enhanced-ip; 


user@R1# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 1.1.1.1/30; 
} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 10.0.0.1/32; 
} 


family mpls; 


user@R1# show routing-options 
router-id 10.0.0.1; 


user@R1# show protocols 
rsvp { 
interface ge-0/0/0.0; 
interface 100.0; 
interface fxp0.0 { 
disable; 


} 
mpls { 
statistics { 
traffic-class-statistics; 
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} 

label-switched-path R1-R2 { 
to 20.0.0.1; 
oam mpls-tp-mode; 
ultimate-hop-popping; 
associate-Isp R2-R1; 

} 

interface ge-0/0/0.0; 

interface 100.0; 

interface fxp0.0 { 
disable; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-0/0/0.0; 
interface 100.0; 
interface fxp0.0 { 
disable; 


Verification 


IN THIS SECTION 


Verifying the LSP Status | 401 
Verifying Packet Loss Measurement | 402 


@ 
@ 
@ Verifying Packet Delay Measurement | 404 
Oo 


Verifying Packet Loss-Delay Measurement | 405 


Confirm that the configuration is working properly. 


Verifying the LSP Status 


Purpose 


Verify that the associated bidirectional LSP between Routers R1 and R2 is up. 
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Action 


From operational mode, run the show mpls Isp command. 


user@R1> show mpls Isp 


Ingress LSP: 1 sessions 
To From 
ZO OnORe 10,0.0.,1 


Total 1 displayed, Up 1, 








Egress LSP: 1 sessions 
To From 
OR Orn Oeewl: ZLOPORO Re 


Total 1 displayed, Up 1, 


Transit LSP: 0 sessions 


Total 0 displayed, Up 0, 





Meaning 


State Rt P 

Up @ 
Down 0 

State 

Up 0 
Down 0 
Down 0 


ActivePath LSPname 


R1-R2 Assoc-Bidir 


Rt Style Labelin Labelout LSPname 


Lise 299776 


The associated bidirectional LSP R1-R2 is up and active. 


Verifying Packet Loss Measurement 


Purpose 


Verify the on-demand loss measurement result. 


Action 


From operational mode, run the monitor mpls loss rsvp R1-R2 count 2 detail command. 


user@R1> monitor mpls loss rsvp R1-R2 count 2 detail 


(0) 

Response code 

Origin timestamp 
Forward transmit count 
Forward receive count 
Reverse transmit count 
Reverse receive count 


(1) 


Response code 





Origin timestamp 


Forward transmit count 


SUCCESS 

1404129082 secs, 905571890 nsecs 
83040 

83040 

83100 

83100 


Success 
1404129083 secs, 905048410 nsecs 
83841 


— R2-R1 Assoc-Bidir 
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Forward receive count 





Reverse transmit count 

Reverse receive count 

Current forward transmit count 
Current forward receive count 
Current forward loss 

Current forward loss ratio 
Current forward throughput 


Current reverse transmit count 


Current reverse receive count 





Current reverse loss 


Current reverse loss ratio 





Current reverse throughput 
(2) 

Response code 

Origin timestamp 

Forward transmit count 
Forward receive count 
Reverse transmit count 


Reverse receive count 





Current forward transmit count 
Current forward receive count 
Current forward loss 

Current forward loss ratio 
Current forward throughput 


Current reverse transmit count 


Current reverse receive count 





Current reverse loss 
Current reverse loss ratio 


Current reverse throughput 


Cumulative forward transmit count 





Cumulative forward loss 

Average forward loss ratio 
Average forward throughput 
Cumulative reverse transmit count 
Cumulative reverse loss 

Average reverse loss ratio 


Average reverse throughput 


LM queries sent 





LM responses received 


LM queries timedout 





LM responses dropped due to errors 


83841 
83904 
83904 

801 

801 

0 packets 
0.000000 
0.801 kpps 
804 

804 

0 packets 
0.000000 
0.804 kpps 


Success 
1404129084 secs, 904828715 nsecs 
84423 
84423 
84487 
84487 

582 

582 

0 packets 
0.000000 
0.582 kpps 
583 

SiS) 

0 packets 
0.000000 
0.583 lgeps 


1383 

0 packets 
0.000000 
0.692 kpps 
1387 

0 packets 
0.000000 
0.694 kpps 


o-oo Ww Ww 
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Meaning 


The packet loss measurement for two counts is displayed. 


Verifying Packet Delay Measurement 


Purpose 


Verify the on-demand delay measurement result. 
Action 
From operational mode, run the monitor mpls delay rsvp R1-R2 count 2 detail command. 


user@R1> monitor mpls delay rsvp R1-R2 count 2 detail 














(1) 

Response code Success 

Querier transmit timestamp 1404129122 secs, 479955401 nsecs 
Responder receive timestamp 1404129122 secs, 468519022 nsecs 
Responder transmit timestamp 1404129122 secs, 470255123 nsecs 
Querier receive timestamp 1404129122 secs, 481736403 nsecs 
Current two-way channel delay 44 usecs 

Current round-trip-time 1781 usecs 

(2) 

Response code Success 

Querier transmit timestamp 1404129123 secs, 480926210 nsecs 
Responder receive timestamp 1404129123 secs, 469488696 nsecs 
Responder transmit timestamp 1404129123 secs, 471130706 nsecs 
Querier receive timestamp 1404129123 secs, 482613911 nsecs 
Current two-way channel delay 45 usecs 


Current round-trip-time 


1687 usecs 


Best two-way channel delay 44 usecs 
Worst two-way channel delay 45 usecs 
Average two-way channel delay 45 usecs 


Best round-trip-time 


Worst round-trip-time 





Average round-trip-tim 








1687 usecs 
1781 usecs 


1734 usecs 


Average forward delay variation 1 usecs 
Average reverse delay variation 1 usecs 
DM queries sent 2 
DM responses received 2 
DM queries timedout 0 
DM responses dropped due to errors 0 


Meaning 


The packet delay measurement for two counts is displayed. 


Verifying Packet Loss-Delay Measurement 


Purpose 


Verify the on-demand loss and delay measurement result. 
Action 
From operational mode, run the monitor mpls loss-delay rsvp R1-R2 count 2 detail command. 


user@R1> monitor mpls loss-delay rsvp R1-R2 count 2 detail 
































(0) 

Response code Success 

Forward transmit count 142049 

Forward receive count 142049 

Reverse transmit count 142167 

Reverse receive count 142167 

Querier transmit timestamp 1404129161 secs, 554422723 nsecs 
Responder receive timestamp 1404129161 secs, 542877570 nsecs 
Responder transmit timestamp 1404129161 secs, 546004545 nsecs 
Querier receive timestamp 1404129161 secs, 557599327 nsecs 
a) 

Response code Success 

Forward transmit count 143049 

Forward receive count 143049 

Reverse transmit count 143168 

Reverse receive count 143168 

Current forward transmit count 1000 

Current forward receive count 1000 

Current forward loss 0 packets 

Current forward loss ratio 0.000000 

Current forward throughput 1.000 kpps 

Current reverse transmit count AL(@(O)AL 

Current reverse receive count L(ONO)AL 

Current reverse loss 0 packets 

Current reverse loss ratio 0.000000 

Current reverse throughput 1.001 kpps 

Querier transmit timestamp 1404129162 secs, 554465742 nsecs 
Responder receive timestamp 1404129162 secs, 542919166 nsecs 
Responder transmit timestamp 1404129162 secs, 545812736 nsecs 
Querier receive timestamp 1404129162 secs, 557409175 nsecs 
Current two-way channel delay 49 usecs 
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Current round-trip-time 
(2) 

Response code 

Forward transmit count 
Forward receive count 
Reverse transmit count 


Reverse receive count 








Current forward transmit count 
Current forward receive count 
Current forward loss 

Current forward loss ratio 
Current forward throughput 


Current reverse transmit count 


Current reverse receive count 





Current reverse loss 


Current reverse loss ratio 





Current reverse throughput 
Querier transmit timestamp 


Responder receive timestamp 





Responder transmit timestamp 


Querier receive timestamp 





Current two-way channel delay 


Current round-trip-time 


Cumulative forward transmit count 
Cumulative forward loss 

Average forward loss ratio 
Average forward throughput 
Cumulative reverse transmit count 
Cumulative reverse loss 

Average reverse loss ratio 


Average reverse throughput 


Best two-way channel delay 
Worst two-way channel delay 
Average two-way channel delay 
Best round-trip-time 


Worst round-trip-time 





Average round-trip-tim 
Average forward delay variation 


Average reverse delay variation 





LDM queries sent 





LDM responses received 





2943 usecs 


Success 
143677 
143677 
143799 
143799 

628 

628 

0 packets 
0.000000 
0.627 kpps 
631 

Sid 

0 packets 
0.000000 
0.630 kpps 
1404129163 
1404129163 
1404129163 
1404129163 
48 usecs 


1816 usecs 


1628 

0 packets 
0.000000 
0.813 kpps 
G32 

0 packets 
0.000000 
O2SiS  kpps 





48 usecs 
49 usecs 
AQ Busce's 
ihostomuseces 
SrviGmuseces 
2645 usecs 
(usces 


0 usecs 


secs, 
secs, 
secs, 


secs, 


DHOGESS 1D 
545150128 
546918408 
558515047 


NSecs 


NSecs 


nsecs 


Nnsecs 
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LDM queries timedout zg @ 
LDM responses dropped due to errors 0) 
Meaning 


The packet loss and delay measurement for two counts is displayed. 


Example: Configuring Pro-active Loss and Delay Measurements for Bidirectional MPLS LSPs 


IN THIS SECTION 


Requirements | 407 
Overview | 408 
Configuration | 408 


Verification | 414 


This example shows how to configure pro-active loss and delay measurements for point-to-point 
ultimate-hop popping label-switched paths (LSPs) in MPLS networks to monitor network performance. 


Requirements 
This example uses the following hardware and software components: 
e Two Mx Series 5G Universal Routing Platforms that contain MPC/MICs only 


e Junos OS Release 15.1 or later running on all the routers 
Before you begin: 


1. Configure the device interfaces. 
2. Configure the autonomous system numbers and router IDs for the devices. 
3. Configure the following protocols: 

a. MPLS 

b. OSPF 

c. RSVP 
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Overview 


Starting with Junos OS Release 15.1, a pro-active tool to monitor and measure packet loss, packet delay, 
or both for associated bidirectional MPLS ultimate-hop popping point-to-point label-switched paths (LSPs) 
is introduced. 


This feature provides the following performance metrics: 


e Inter-packet delay variation (IPDV) 
e Loss measurement 

e Round-trip delay (RTT) 

e Throughput measurement 


e Two-way channel delay 


This functionality provides real-time visibility into network performance, thereby facilitating network 
performance planning, troubleshooting, and evaluation. 


Topology 


Figure 24 on page 408 illustrates the pro-active loss and delay measurements using a simple two-router 
topology. 


Figure 24: Configuring Pro-Active Loss and Delay Measurements 
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In this example, an associated bidirectional LSP is configured between Routers R1 and R2, for which the 
performance metrics are measured. 


Configuration 


CLI Quick Configuration 

To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


R1 


set chassis network-services enhanced-ip 

set interfaces ge-0/0/0 unit 0 family inet address 1.1.1.1/30 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces loO unit O family inet address 10.0.0.1/32 


R2 
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set interfaces loO unit O family mpls 

set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface lo0.0 

set protocols mpls interface fxp0.0 disable 

set protocols mpls label-switched-path R1-R2 associate-Isp R2-R1 

set protocols mpls label-switched-path R1-R2 install 20.10.30.0/24 active 

set protocols mpls label-switched-path R1-R2 oam mpls-tp-mode 

set protocols mpls label-switched-path R1-R2 oam performance-monitoring querier delay traffic-class 
tc-O query-interval 1000 

set protocols mpls label-switched-path R1-R2 oam performance-monitoring querier loss traffic-class 
none query-interval 1000 

set protocols mpls label-switched-path R1-R2 oam performance-monitoring querier loss-delay 
traffic-class tc-O query-interval 1000 

set protocols mpls label-switched-path R1-R2 oam performance-monitoring responder delay 
min-query-interval 1000 

set protocols mpls label-switched-path R1-R2 oam performance-monitoring responder loss 
min-query-interval 1000 

set protocols mpls label-switched-path R1-R2 to 20.0.0.1 

set protocols mpls label-switched-path R1-R2 ultimate-hop-popping 

set protocols mpls statistics traffic-class-statistics 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols rsvp interface ge-0/0/0.0 

set protocols rsvp interface lo0.0 

set protocols rsvp interface fxp0.0 disable 

set routing-options router-id 10.0.0.1 


set chassis network-services enhanced-ip 

set interfaces ge-0/0/0 unit 0 family inet address 1.1.1.2/30 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces loO unit O family inet address 20.0.0.1/32 

set interfaces loO unit O family mpls 

set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface lo0.0 

set protocols mpls interface fxp0.0 disable 

set protocols mpls label-switched-path R2-R1 associate-Isp R1-R2 
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set protocols mpls label-switched-path R2-R1 install 10.10.20.0/24 active 

set protocols mpls label-switched-path R2-R1 oam mpls-tp-mode 

set protocols mpls label-switched-path R2-R1 oam performance-monitoring responder delay 
min-query-interval 1000 

set protocols mpls label-switched-path R2-R1 oam performance-monitoring responder loss 
min-query-interval 1000 

set protocols mpls label-switched-path R2-R1 oam performance-monitoring querier delay traffic-class 
tc-O query-interval 1000 

set protocols mpls label-switched-path R2-R1 oam performance-monitoring querier loss traffic-class 
none query-interval 1000 

set protocols mpls label-switched-path R2-R1 oam performance-monitoring querier loss-delay 
traffic-class tc-O query-interval 1000 

set protocols mpls label-switched-path R2-R1 to 10.0.0.1 

set protocols mpls label-switched-path R2-R1 ultimate-hop-popping 

set protocols mpls statistics traffic-class-statistics 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols rsvp interface ge-0/0/0.0 

set protocols rsvp interface lo0.0 

set protocols rsvp interface fxp0.0 disable 

set routing-options router-id 20.0.0.1 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Router R1: 


1. Enable the enhanced IP network services configuration. 


[edit chassis] 


user@R1# set network-services enhanced-ip 


2. Configure the interfaces for Router R1. 


[edit interfaces] 
user@R1# set ge-0/0/0 unit 0 family inet address 1.1.1.1/30 
user@R1# set ge-0/0/0 unit 0 family mpls 
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user@R1# set loO unit O family inet address 10.0.0.1/32 
user@R1# set loO unit 0 family mpls 


3. Configure the router ID for Router R1. 


[edit routing-options] 
user@R1# set router-id 10.0.0.1 


4. Enable RSVP on all the interfaces of Router R1, excluding the management interface. 


[edit protocols] 

user@R1# set rsvp interface ge-0/0/0.0 
user@R1# set rsvp interface lo0.0 
user@R1# set rsvp interface fxp0.0 disable 


5. Enable MPLS on all the interfaces of Router R1, excluding the management interface. 


[edit protocols] 

user@R1# set mpls interface ge-0/0/0.0 
user@R1# set mpls interface lo0.0 
user@R1# set mpls interface fxp0.0 disable 


6. Configure an associated bidirectional LSP to Router R2. 


[edit protocols] 

user@R1# set mpls label-switched-path R1-R2 to 20.0.0.1 

user@R1# set mpls label-switched-path R1-R2 install 20.10.30.0/24 active 
user@R1# set mpls label-switched-path R1-R2 oam mpls-tp-mode 
user@R1# set mpls label-switched-path R1-R2 ultimate-hop-popping 
user@R1# set mpls label-switched-path R1-R2 associate-Isp R2-R1 


7. Create traffic classes for maintaining data traffic statistics per traffic class. 


This enables traffic class scoped loss and delay measurement. 


[edit protocols] 
user@R1# set mpls statistics traffic-class-statistics 


8. Configure performance monitoring at the querier side. 
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[edit protocols] 

user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring querier delay traffic-class tc-O 
query-interval 1000 

user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring querier loss traffic-class none 
query-interval 1000 

user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring querier loss-delay traffic-class 
tc-O query-interval 1000 


9. Configure performance monitoring at the responder side. 


[edit protocols] 

user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring responder delay 
min-query-interval 1000 

user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring responder loss min-query-interval 
1000 


10. Configure OSPF with traffic engineering capabilities, and enable OSPF on all the interfaces of Router 
R1, excluding the management interface. 


[edit protocols] 

user@R1# set ospf traffic-engineering 

user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 
user@R1# set ospf area 0.0.0.0 interface lo0.0 
user@R1# set ospf interface fxp0.0 disable 


Results 


From configuration mode, confirm your configuration by entering the show chassis, show interfaces, show 
routing-options, and show protocols commands. If the output does not display the intended configuration, 
repeat the instructions in this example to correct the configuration. 


user@R1# show chassis 
network-services enhanced-ip; 


user@R1# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 1.1.1.1/30; 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 10.0.0.1/32; 
} 


family mpls; 


user@R1# show routing-options 
router-id 10.0.0.1; 


user@R1# show protocols 
rsvp { 
interface ge-0/0/0.0; 
interface 100.0; 
interface fxp0.0 { 
disable; 


} 
mpls { 
label-switched-path R1-R2 { 
to 20.0.0.1; 
install 20.10.30.0/24 active; 
oam { 
mpls-tp-mode; 
performance-monitoring { 
querier { 
loss { 
traffic-class none { 
query-interval 1000; 


} 
delay { 
traffic-class tc-O { 
query-interval 1000; 


} 
loss-delay { 
traffic-class none { 
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query-interval 1000; 


} 
responder { 
loss { 
min-query-interval 1000; 
} 
delay { 
min-query-interval 1000; 


} 
ultimate-hop-popping; 
associate-Isp R2-R1; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-0/0/0.0; 
interface 100.0; 
interface fxp0.0 { 
disable; 


Verification 


Verifying Loss and Delay Measurement 


Purpose 


Verify the loss and delay measurement. 


Action 


From operational mode, run the show performance-monitoring mpls Isp command. 


user@R1> show performance-monitoring mpls Isp 


Ses sno nell smu Ore omD OwincamO 


LSP name:R1-R2, PM State:Up 


Loss measurement Data: 


414 


ESP 


ESP 


Duration: 00:04:43 
Traffic-class: None 
Queries sent: 282 
Responses received: 282 
Responses dropped due to errors: 0 
Queries timeout: 0 
Forward loss measurement: 

Average packet loss: 0 

Average packet throughput: 554338 
Reverse loss measurement: 

Average packet loss: 0 

Average packet throughput: 1352077 
name:R1-R2, PM State:Up 





lay measurement Data: 
Duration: 00:04:43 
Leartic-Classs 


Queries sent: 282 





Responses received: 282 

Responses dropped due to errors: 0 

Queries timeout: 0 

Best 2-way channel delay: 72 usecs 

Worst 2-way channel delay: 365 usecs 

Best round trip time: 843 usecs 

WORSE wolimel ie came: IOSh23. wsecs 

Avg absolute fw delay variation: 1619 usecs 
Avg absolute rv delay variation: 1619 usecs 


name:R1-R2, PM State:Up 


Loss measurement Data: 


DueatetomcmOOm0 4543) 
Traffic-class: None 


Queries sent: 282 





Responses received: 282 
Responses dropped due to errors: 0 
Queries timeout: 0 
Forward loss measurement: 

Average packet loss: 0 

Average packet throughput: 553927 
Reverse loss measurement: 

Average packet loss: 0 


Average packet throughput: 1351531 





lay measurement Data: 
Best 2-way channel delay: 76 usecs 
Worst 2-way channel delay: 368 usecs 


Best round trip time: 1082 usecs 
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Worst round trip time: 126146 usecs 
Avg absolute fw delay variation: 1618 usecs 


Avg absolute rv delay variation: 1619 usecs 


Meaning 


The packet loss and delay measurement metrics for LSP are displayed. 


Configuring On-Demand Loss and Delay Measurement 


You can configure an on-demand loss and delay measurement for point-to-point ultimate hop popping 
(UHP) label-switched paths (LSPs) in MPLS networks to monitor network performance. The monitor mpls 
loss rsvp, monitor mpls delay rsvp, and monitor mpls loss-delay rsvp CLI commands provide an on-demand 
summary of performance metrics for direct mode packet loss, two-way packet delay, and related metrics, 
such as inter-packet delay variation and channel throughput measurement. 


This functionality provides real-time visibility into network performance, thereby facilitating network 
performance planning, troubleshooting, and evaluation. 


Before you begin: 


1. Configure the device interfaces. 
2. Configure the device router ID. 
3. Configure the following protocols: 
e RSVP 
e OSPF 
Enable traffic engineering capabilities. 


e MPLS 


To configure the PE device: 


1. Enable the chassis with tunnel services and enhanced IP network services configuration. 


[edit chassis] 
user@R1# set fpc fpc-slot pic pic-slot tunnel-services bandwidth bandwidth 
user@R1# set network-services enhanced-ip 


2. Configure an associated bidirectional LSP to the remote router. 


[edit protocols] 


417 


user@R1# set mpls label-switched-path Isp-name to remote-router-ip-address 
user@R1# set mpls label-switched-path Isp-name oam mpls-tp-mode 
user@R1# set mpls label-switched-path Isp-name ultimate-hop-popping 
user@R1# set mpls label-switched-path Isp-name associate-Isp Isp-name 


3. Create traffic classes for maintaining data traffic statistics per traffic class. 


This enables traffic class scoped loss measurement. 


[edit protocols] 
user@R1# set mpls statistics traffic-class-statistics 


Configuring Pro-Active Loss and Delay Measurements 


You can configure pro-active loss and delay measurements for point-to-point ultimate-hop popping 
label-switched paths (LSPs) in MPLS networks to monitor network performance. The show 
performance-monitoring mpls Isp CLI command provides a summary of performance metrics for direct 
mode packet loss, two-way packet delay, and related metrics, such as inter-packet delay variation and 
channel throughput measurement. 


This functionality provides real-time visibility into network performance, thereby facilitating network 
performance planning, troubleshooting, and evaluation. 


This feature provides the following performance metrics: 


e Inter-packet delay variation (IPDV) 
e Loss measurement 

e Round-trip delay (RTT) 

e Throughput measurement 


e Two-way channel delay 
Before you begin: 


1. Configure the device interfaces. 
2. Configure the autonomous system numbers and router IDs for the devices. 
3. Configure the following protocols: 

e MPLS 

e OSPF 

e RSVP 
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To configure pro-active loss and delay measurements on the PE device: 


1. Configure an associated bidirectional LSP to Router R2. 


[edit protocols] 

user@host# set mpls label-switched-path Isp-name to remote-router-ip-address 

user@host# set mpls label-switched-path Isp-name install destination-prefix/prefix-length active 
user@host# set mpls label-switched-path Isp-name oam mpls-tp-mode 

user@host# set mpls label-switched-path Isp-name ultimate-hop-popping 

user@host# set mpls label-switched-path Isp-name associate-Isp remote-Isp-name 


2. Create traffic classes for maintaining data traffic statistics per traffic class. 


This enables traffic class scoped loss and delay measurements. 


[edit protocols] 
user@host# set mpls statistics traffic-class-statistics 


3. Configure performance monitoring at the querier side. 


[edit protocols] 

user@host# set mpls label-switched-path Isp-name oam performance-monitoring querier delay traffic-class 
tc-value query-interval milliseconds 

user@host# set mpls label-switched-path Isp-name oam performance-monitoring querier loss traffic-class 
tc-value query-interval milliseconds 

user@host# set mpls label-switched-path Isp-name oam performance-monitoring querier loss-delay traffic-class 
tc-value query-interval milliseconds 


4. Configure performance monitoring at the responder side. 


[edit protocols] 

user@host# set mpls label-switched-path Isp-name oam performance-monitoring responder delay 
min-query-interval milliseconds 

user@host# set mpls label-switched-path Isp-name oam performance-monitoring responder loss 
min-query-interval milliseconds 
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How a Packet Travels Along an LSP 


When an IP packet enters an LSP, the ingress router examines the packet and assigns it a label based on 
its destination, placing the label in the packet's header. The label transforms the packet from one that is 
forwarded based on its IP routing information to one that is forwarded based on information associated 
with the label. 


The packet is then forwarded to the next router in the LSP. This router and all subsequent routers in the 
LSP do not examine any of the IP routing information in the labeled packet. Rather, they use the label to 
look up information in their label forwarding table. They then replace the old label with a new label and 
forward the packet to the next router in the path. 
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When the packet reaches the egress router, the label is removed, and the packet again becomes a native 
IP packet and is again forwarded based on its IP routing information. 


Types of LSPs 


There are three types of LSPs: 


Static LSPs—For static paths, you must manually assign labels on all routers involved (ingress, transit, 
and egress). No signaling protocol is needed. This procedure is similar to configuring static routes on 
individual routers. Like static routes, there is no error reporting, liveliness detection, or statistics reporting. 


LDP-signaled LSPs—See “LDP Introduction” on page 855. 


RSVP-signaled LSPs—For signaled paths, RSVP is used to set up the path and dynamically assign labels. 
(RSVP signaling messages are used to set up signaled paths.) You configure only the ingress router. The 
transit and egress routers accept signaling information from the ingress router, and they set up and 
maintain the LSP cooperatively. Any errors encountered while establishing an LSP are reported to the 
ingress router for diagnostics. For signaled LSPs to work, a version of RSVP that supports tunnel extensions 
must be enabled on all routers. 


There are two types of RSVP-signaled LSPs: 


Explicit-path LSPs—All intermediate hops of the LSP are manually configured. The intermediate hops 
can be strict, loose, or any combination of the two. Explicit path LSPs provide you with complete control 
over how the path is set up. They are similar to static LSPs but require much less configuration. 


Constrained-path LSPs—The intermediate hops of the LSP are automatically computed by the software. 
The computation takes into account information provided by the topology information from the IS-IS 
or OSPF link-state routing protocol, the current network resource utilization determined by RSVP, and 
the resource requirements and constraints of the LSP. For signaled constrained-path LSPs to work, either 
the IS-IS or OSPF protocol and the IS-IS or OSPF traffic engineering extensions must be enabled on all 
routers. 


Scope of LSPs 


For constrained-path LSPs, the LSP computation is confined to one IGP domain, and cannot cross any AS 
boundary. This prevents an AS from extending its IGP into another AS. 


Explicit-path LSPs, however, can cross as many AS boundaries as necessary. Because intermediate hops 
are manually specified, the LSP does not depend on the IGP topology or a local forwarding table. 
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MPLS Label Overview 


Packets traveling along an LSP are identified by a label—a 20-bit, unsigned integer in the range O through 
1,048,575. For push labels on ingress routers, no labels in this range are restricted. For incoming labels on 
the transit static LSP, the label value is restricted to 1,000,000 through 1,048,575. 


On MxX Series, PTX Series, and T Series routers, the value for entropy and flow labels is restricted to 16 
through 1,048,575. 


MPLS Label Allocation 


In the Junos OS, label values are allocated per router or switch—the rest of this explanation uses router 
to cover both. The display output shows only the label (for example, 01024). Labels for multicast packets 
are independent of those for unicast packets. Currently, the Junos OS does not support multicast labels. 


Labels are assigned by downstream routers relative to the flow of packets. A router receiving labeled 
packets (the next-hop router) is responsible for assigning incoming labels. A received packet containing a 
label that is unrecognized (unassigned) is dropped. For unrecognized labels, the router does not attempt 
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to unwrap the label to analyze the network layer header, nor does it generate an Internet Control Message 
Protocol (ICMP) destination unreachable message. 


A packet can carry a number of labels, organized as a last-in, first-out stack. This is referred to as a label 
stack. At a particular router, the decision about how to forward a labeled packet is based exclusively on 
the label at the top of the stack. 


Figure 25 on page 423 shows the encoding of a single label. The encoding appears after data link layer 
headers, but before any network layer header. 


Figure 25: Label Encoding 
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Figure 26 on page 423 illustrates the purpose of the class-of-service bits (also Known as the EXP or 
experimental bits). Bits 20 and 21 specify the queue number. Bit 22 is the packet loss priority (PLP) bit 
used to specify the random early detection (RED) drop profile. For more information about class of service 
and the class-of-service bits, see “Configuring Class of Service for MPLS LSPs” on page 1220. 


Figure 26: Class-of-Service Bits 
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Operations on MPLS Labels 


The router supports the following label operations: 


Push—Add a new label to the top of the packet. For IPv4 packets, the new label is the first label. The 
time-to-live (TTL) and s bits are derived from the IP packet header. The MPLS class of service (CoS) is 
derived from the queue number. If the push operation is performed on an existing MPLS packet, you 
will have a packet with two or more labels. This is called label stacking. The top label must have its s bit 
set to O, and might derive CoS and TTL from lower levels. The new top label in a label stack always 
initializes its TTL to 255, regardless of the TTL value of lower labels. 


e Pop—Remove the label from the beginning of the packet. Once the label is removed, the TTL is copied 
from the label into the IP packet header, and the underlying IP packet is forwarded as a native IP packet. 
In the case of multiple labels in a packet (label stacking), removal of the top label yields another MPLS 
packet. The new top label might derive CoS and TTL from a previous top label. The popped TTL value 
from the previous top label is not written back to the new top label. 


Swap—Replace the label at the top of the label stack with a new label. The S and CoS bits are copied 
from the previous label, and the TTL value is copied and decremented (unless the no-decrement-ttl or 


no-propagate-ttl statement is configured). A transit router supports a label stack of any depth. 


Multiple Push—Add multiple labels (up to three) on top of existing packets. This operation is equivalent 


to pushing multiple times. 


Swap and Push—Replace the existing top of the label stack with a new label, and then push another new 


label on top. 


Understanding MPLS Label Operations 
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In the traditional packet-forwarding paradigm, as a packet travels from one switch to the next, an 
independent forwarding decision is made at each hop. The IP network header is analyzed and the next 
hop is chosen based on this analysis and on the information in the routing table. In an MPLS environment, 
the analysis of the packet header is made only once, when a packet enters the MPLS tunnel (that is, the 
path used for MPLS traffic). 


When an IP packet enters a label-switched path (LSP), the ingress provider edge (PE) switch examines the 
packet and assigns it a label based on its destination, placing the label in the packet’s header. The label 
transforms the packet from one that is forwarded based on its IP routing information to one that is 
forwarded based on information associated with the label. The packet is then forwarded to the next 
provider switch in the LSP. This switch and all subsequent switches in the LSP do not examine any of the 
IP routing information in the labeled packet. Rather, they use the label to look up information in their label 
forwarding table. They then replace the old label with a new label and forward the packet to the next 
switch in the path. When the packet reaches the egress PE switch, the label is removed, and the packet 
again becomes a native IP packet and is forwarded based on its IP routing information. 


This topic describes: 


MPLS Label-Switched Paths and MPLS Labels 


When a packet enters the MPLS network, it is assigned to an LSP. Each LSP is identified by a label, which 
is a short (20-bit), fixed-length value at the front of the MPLS label (32 bits). Labels are used as lookup 
indexes for the label forwarding table. For each label, this table stores forwarding information. Because 
no additional parsing or lookup is done on the encapsulated packet, MPLS supports the transmission of 
any other protocols within the packet payload. 


Figure 27 on page 425 shows the encoding of a single label. The encoding appears after data link layer 
headers, but before any network layer header. 


Figure 27: Label Encoding 
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Reserved Labels 


Labels range from O through 1,048,575. Labels O through 999,999 are for internal use. 


Some of the reserved labels (in the range O through 15) have well-defined meanings. The following reserved 
labels are used by QFX Series and EX4600 devices: 


e 0, IPv4 Explicit Null label—This value is valid only when it is the sole label entry (no label stacking). It 
indicates that the label must be popped on receipt. Forwarding continues based on the IP version 4 
(IPv4) packet. 


e 1, Router Alert label—When a packet is received with a top label value of 1, it is delivered to the local 
software module for processing. 


e 3, Implicit Null label—This label is used in the signaling protocol (RSVP) only to request label popping by 
the downstream switch. It never actually appears in the encapsulation. Labels with a value of 3 must not 
be used in the data packet as real labels. No payload type (IPv4 or IPv6) is implied with this label. 


MPLS Label Operations 

QF&X Series and EX4600 devices support the following MPLS label operations: 
e Push 

e Pop 


e Swap 


NOTE: There is a limit with regard to the number of labels that QFX and EX4600 devices can 
affix (push operations) to the label stack or remove (pop operations) from the label stack. 


e For Push operations—As many as three labels are supported. 


e For Pop operations—As many as three labels are supported. 


The push operation affixes a new label to the top of the IP packet. For IPv4 packets, the new label is the 
first label. The time to live (TTL) field value in the packet header is derived from the IP packet header. The 
push operation cannot be applied to a packet that already has an MPLS label. 


The pop operation removes a label from the beginning of the packet. Once the label is removed, the TTL 
is copied from the label into the IP packet header, and the underlying IP packet is forwarded as a native 
IP packet 


The swap operation removes an existing MPLS label from an IP packet and replaces it with a new MPLS 
label, based on the following: 


e Incoming interface 


e Label 
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e Label forwarding table 


Figure 28 on page 427 shows an IP packet without a label arriving on the customer edge interface (ge-0/0/1) 
of the ingress PE switch. The ingress PE switch examines the packet and identifies that packet's destination 
as the egress PE switch. The ingress PE switch applies label 100 to the packet and sends the MPLS packet 
to its outgoing MPLS core interface (ge-0/0/5). The MPLS packet is transmitted on the MPLS tunnel 
through the provider switch, where it arrives at interface ge-0/0/5 with label 100. The provider switch 
swaps label 100 with label 200 and forwards the MPLS packet through its core interface (ge-0/0/7) to the 
next hop on the tunnel, which is the egress PE switch. The egress PE switch receives the MPLS packet 
through its core interface (ge-0/0/7), removes the MPLS label, and sends the IP packet out of its customer 
edge interface (ge-0/0/1) to a destination that is beyond the tunnel. 


Figure 28: MPLS Label Swapping 
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Figure 28 on page 427 shows the path of a packet as it passes in one direction from the ingress PE switch 
to the egress PE switch. However, the MPLS configuration also allows traffic to travel in the reverse 
direction. Thus, each PE switch operates as both an ingress switch and an egress switch. 


Penultimate-Hop Popping and Ultimate-Hop Popping 


The switches enable penultimate-hop popping (PHP) by default with IP over MPLS configurations. With 
PHP, the penultimate provider switch is responsible for popping the MPLS label and forwarding the traffic 
to the egress PE switch. The egress PE switch then performs an IP route lookup and forwards the traffic. 
This reduces the processing load on the egress PE switch, because it is not responsible for popping the 
MPLS label. 


e The default advertised label is label 3 (Implicit Null label). If label 3 is advertised, the penultimate-hop 
switch removes the label and sends the packet to the egress PE switch. 


e If ultimate-hop popping is enabled, label 0 (IPv4 Explicit Null label) is advertised and the egress PE switch 
of the LSP removes the label. 
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Understanding MPLS Label Manager 


MPLS label manager is used to manage different label types such as LSI, dynamic, block, and static, which 
are supported on platforms using Modular Port Concentrators (MPCs) equipped with Junos Trio chipsets. 
These line cards provide more flexibility and scalability, when the enhanced-ip command is configured on 
the device. 


The existing behavior of label-space command is retained, which is not recommended. To provide additional 
functionality such as multiple ranges for each type of label, label-range command is introduced under the 
[edit protocols mpls label usage] hierarchy, which is independent of label-space configuration. You can 
choose either style if only one range is needed for each type of label. 


The following features are optimized with the enhanced-ip command configured on the device: 


e Allows you to define the system wide global label pool to be used by segment-routing global block 
(SRGB) through IS-IS routing protocol. 


e Increases the vrf-table-label space to at least 16,000, if the platform can support the scale. 
e Allows you to specify the label value to be used by static VRF table label. 
e Allows you to specify the label value range to be used by supported label application types. 


e Allows you to change dynamically the SRGB and label type ranges. 


Special MPLS Labels 


Some of the reserved labels (in the O through 15 range) have well-defined meanings. For more complete 
details, see RFC 3032, MPLS Label Stack Encoding. 


e O, IPv4 Explicit Null label—This value is legal only when it is the sole label entry (no label stacking). It 
indicates that the label must be popped upon receipt. Forwarding continues based on the IP version 4 
(IPv4) packet. 


e 1, Router Alert label—When a packet is received with a top label value of 1, it is delivered to the local 
software module for processing. 


e 2, |Pv6 Explicit Null label—This value is legal only when it is the sole label entry (no label stacking). It 
indicates that the label must be popped on receipt. Forwarding continues based on the IP version 6 
(IPv6) packet. 


e 3, Implicit Null label—This label is used in the control protocol (LDP or RSVP) only to request label popping 
by the downstream router. It never actually appears in the encapsulation. Labels with a value of 3 should 
not be used in the data packet as real labels. No payload type (IPv4 or IPv6) is implied with this label. 


e 4 through 6—Unassigned. 


e 7, Entropy label indicator—This label is used when an Entropy label is in the label stack and precedes 
the Entropy label. 


e 8 through 15—Unassigned. 


Special labels are commonly used between the egress and penultimate routers of an LSP. If the LSP is 
configured to carry IPv4 packets only, the egress router might signal the penultimate router to use O as a 
final-hop label. If the LSP is configured to carry IPv6é packets only, the egress router might signal the 
penultimate router to use 2 as a final-hop label. 


The egress router might simply signal the penultimate router to use 3 as the final label, which is a request 
to perform penultimate-hop label popping. The egress router will not process a labeled packet; rather, it 
receives the payload (IPv4, IPvé6, or others) directly, reducing one MPLS lookup at egress. 


For label-stacked packets, the egress router receives an MPLS label packet with its top label already popped 
by the penultimate router. The egress router cannot receive label-stacked packets that use label O or 2. It 
typically requests label 3 from the penultimate router. 


Entropy Label Support in Mixed Mode Overview 


Starting with Junos OS Release 14.2, entropy label is supported in mixed mode chassis where the entropy 
label can be configured without enhanced-ip configuration. The entropy label helps transit routers 
load-balance MPLS traffic across ECMP paths or link aggregation groups. The entropy label introduces a 
load-balancing label to be used by routers to load balance traffic rather than relying on deep packet 
inspection, reducing the packet processing requirements in the forwarding plane at the expense of increased 
label stack depth. Junos OS supports the entropy label only for MX Series routers with MPCs or MICs and 
can be enabled with enhanced-ip mode. But, this leads to a packet drop if the core-facing interface has 
an entropy label configured on the MPC or MIC and the other end of this core-facing connection has a 
DPC line card. In order to avoid this, the entropy label is now supported in mixed mode where the entropy 
label can be configured without enhanced-ip configuration. This allows MX Series router DPCs to support 
a pop out entropy label. However, this does not support a flow label. 


Abstract Hops for MPLS LSPs Overview 


IN THIS SECTION 


@ Understanding Abstract Hops | 430 
@ Benefits of Using Abstract Hops | 431 
@ = Junos OS Implementation of Abstract Hops | 433 
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An abstract hop is a logical combination of the existing traffic engineering constraints, such as administrative 
groups, extended administrative groups, and Shared Risk Link Groups (SRLGs), which results in a user-defined 
group or cluster of routers that can be sequenced and used as constraints for setting up an MPLS 
label-switched path (LSP). Abstract hops overcome the limitations of existing path constraint specifications 
and provide several benefits to the traffic engineering capabilities of MPLS. 


Understanding Abstract Hops 


The path constraint for setting up of an MPLS LSP can be specified as either individual routers in the form 
of real hops or as a set of routers by way of administrative group or color specification. When a path 
constraint uses real hops (strict or loose), the LSP is set up along a specified sequence of routers (for 
example, R1, R2, ... Rn). When a path constraint uses an administrative group or color specification, a group 
of routers that meet the specified criteria is used to set up the LSP without picking a specific router, and 
unlike real-hop constraint, there is no sequence among the different groups of routers used in the constraint. 


The drawback of real-hop constraint is that in a failure scenario, if any of the router hops goes down or 
the bandwidth utilization of the attached interface gets saturated, the path goes down (or relies on local 
or end-to-end protection). Although other alternative routers might be available to recover or set up the 
LSP, the LSP remains down until the operator configures another router hop sequence as the path constraint 
to bring the path up again or to disengage the protection path. 


The administrative group or color specification constraint overcomes this limitation of a real-hop constraint 
to acertain extent. Here, when one of the routers in the group goes down or has its link capacity saturated, 
setting up of the LSP is not affected. This is because the next hop router to be used in the path constraint 
is not picked beforehand, and the LSP is set up along other routers that have the same administrative 
group or color without operator intervention. However, the drawback with router group constraints is 
that a sequence cannot be specified among the hop constraints. 


Abstract hops overcome these drawbacks by creating user-defined router groups, where each member 
router meets a user-defined constraint. The user-defined constraint is a logical combination of the existing 
traffic engineering constraints, such as administrative groups, extended administrative groups, and Shared 
Risk Link Groups (SRLGs). Ordering is achieved among the router groups by specifying a sequence of 
abstract hops used in a path constraint. As a result, abstract hops combine the ordering property of real-hop 
constraint specification and the resilience that comes with the other traffic engineering constraints. 


A path can use a combination of real and abstract hops as constraints. When using abstract hops, instead 
of specifying a sequence of routers (R1, R2, ... Rn) as with real hops, you specify an ordered set of router 
groups or abstract hops (G1, G2, ... Gn) as the path constraint. Each specified router group, Gi for example, 
consists of some user-defined set of routers—R1, R2, Rj, ... Rn. When one of the routers in the group goes 
down, say Router Rj in group Gi, another router, say Router Rk, from the same group Gi is picked up by 
path computation to replace the router that went down (that is, Router Rj). This is because the path 
constraint is sequenced and has to go through a sequence of abstract hops, instead of a sequence of 
individual routers. 
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Benefits of Using Abstract Hops 


IN THIS SECTION 


@ = Specifying a Sequence of Constraint Combinations | 431 
@ = Avoiding New Network Configuration on Transit Nodes | 431 


@ ~=Combining Centralized and Distributed Path Computation Paradigms | 432 


Abstract hops are user-defined router groups. Similar to real-hop constraints that use a sequence of 
individual routers, a sequence of abstract hops can be used for setting up a label-switched path (LSP). The 
use of abstract hops provides resiliency to sequenced path constraints. The other benefits of using abstract 
hops include: 


Specifying a Sequence of Constraint Combinations 


Currently, it is possible to specify a path that can go through links that satisfy multiple attributes. Such a 
path constraint is called a compound constraint combination; for example, a constraint (Ci) that includes 
low latency links of green color and also excludes SRLG north. 


However, there is no support for specifying a path with a sequence of compound constraint combinations. 
For example, a sequenced constraint (C1, C2, Ci, ...Cn) that includes low latency green links, no latency 
blue links, and then low latency red links. 


The need for such a sequenced compound constraint combination arises when there is a requirement to 
establish paths through a sequence of geographical regions with a different link affinity (attributes) 
requirement in each region. Abstract hops meet this requirement by allowing computing nodes to map 
each constraint combination (Ci, for example) with the user-defined group of routers—that is, the abstract 
hops. 


Avoiding New Network Configuration on Transit Nodes 


With current path constraint specification capabilities, it is possible to include or exclude links of certain 

attributes along an entire path; for example, excluding SRLG west from a path. However, there is no support 
to either conditionally exclude or include attributes, or to apply different exclude or include attributes in 

different parts of the path; for example, excluding SRLG west only when traversing red links. 


As a workaround, a new administrative group can be created to identify all such red links that do not have 
SRLG west, and configure all the relevant links appropriately with that administrative group. The drawback 
of this approach is that configuration changes are required throughout the network to reflect the new 
administrative group membership. 


Instead, by using abstract hops, the configuration changes can be contained on the ingress router only. At 
the ingress router, the constraint combination is mapped to the abstract hop, thereby meeting the 
aforementioned requirement without the need for any new configuration on the transit nodes. 
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Combining Centralized and Distributed Path Computation Paradigms 


Traffic engineering of MPLS paths can be achieved by distributed computing or with a centralized controller 
for computing paths. A combination of both the computation types is called the hybrid computation 
paradigm. The key feature of the hybrid computation approach is the ability of the centralized 
controller—referred to as a Path Computation Element (PCE)—to loosely specify the path computation 
directives, per path, to the ingress router—referred to as a Path Computation Client (PCC)—and the ability 
of the ingress router to use it as input for path computation. 


A sequence of abstract hops serves the purpose of acting as the guideline from the centralized controller. 
Abstract hops provide the flexibility to the controller to weave into the path constraint and attributes. This 
also enables the controller to build in the element of sequence in the constraint. The controller does not 
have to specify each hop the path needs to take, leaving room for the ingress router to act within the limits 
of the guideline or directive. 


Table 12 on page 432 lists the key features of the hybrid computation paradigm and provides a comparison 
of this approach with the current path computation methods. 


Table 12: Hybrid Computation for Abstract Hops 


Features Distributed Centralized Hybrid Constrained 
Constrained Shortest | Constrained Shortest | Shortest Path First 
Path First Path First 

React to frequent changes in a large Yes Yes 

network 

Sophisticated path computation with Yes Yes 

global view 

Incorporation of business logic in path Yes Yes 


computation 


Resilience (no single point of failure) Yes Yes 
Predictability Yes Yes 
React to network load in (close to) real Yes Yes 
time 


Field tested (versus early adoption) Yes Yes 
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Junos OS Implementation of Abstract Hops 


IN THIS SECTION 


Defining Abstract Hops | 433 
Using Abstract Hops in Path Constraint | 437 
Path Computation and Backtracking | 441 


Sample Backtracking | 441 


The order-aware abstract hops feature is introduced in Junos OS Release 17.1. The following sections 
describe the implementation of abstract hops in Junos OS: 


Defining Abstract Hops 


An abstract hop is a group of routers that users can define to be used in setting up a label-switched path 
(LSP). The user can control which routers to include in the group by defining a logical combination of 
heterogeneous link attributes or constraints called constituent attributes. The routers with links that satisfy 
the defined constituent attributes make it to the group of routers representing the abstract hop. 


The mapping of constituent attributes with the abstract hop is local to the computing node or the ingress 
of the LSP being setup. As a result, abstract hops do not have associated interior gateway protocol updates 
or signaling protocol extensions, and implementing abstract hops in a network does not require new 
configuration on the transit nodes. 


A constituent list enables defining of a set of constituent traffic engineering attributes, that is identified 
by auser-defined name. Constituent lists are used in an abstract hop definition by using any of the following 
configuration statements: 


include-any-list—Link satisfies the constituent-list if any of the specified constituent attributes are true 
for the link. 


include-all-list—Link satisfies the constituent-list if all the specified constituent attributes are true for 
the link. 


exclude-all-list—Link satisfies the constituent-list if none of the specified constituent attributes are true 
for the link. 


exclude-any-list—Link satisfies the constituent-list if at least one of the specified constituent attributes 


is not true for the link. 
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An abstract hop is defined as a logical combination of constituent-list references that can belong to any 
of the aforementioned categories. To achieve this, logical operators AND and OR are included in the 
abstract hop definition, and applied to the constituent list. 


e OR—At least one of the constituent-list references in the abstract hop definition must be satisfied by a 
link for the attached node to be part of the abstract hop. 


e AND-—AIll of the constituent-list references in the abstract hop definition must be satisfied by a link for 
the attached node to be part of the abstract hop. 


Sample Abstract Hop Definition 


Taking as an example, the definition of abstract hops hopA is as follows: 


Abstract hops hopA must include all routers whose emanating links satisfy the logical combination of the 
following link attributes, respectively: 


e hopA—((administrative group red && Srlg south) || (administrative group green || Srlg north)), where: 
e administrative group red and Srlg south belong to include-all constituent list (listA1, in this example). 
e administrative group green and Srlg north belong to include-any constituent list (listA2, in this example). 


e || is the OR operator. 


The configuration for abstract hops hopA is as follows: 


e hopA configuration 


[edit protocols mpls] 

Constituent-list listA1 { 
administrative-group red; 
Srlg south; 

} 

Constituent-list listA2 { 
administrative-group green; 
Srig north; 

} 

Abstract-hop hopAf 
Operator OR; 
Constituent-list listA1 include-all-list; 


Constituent-list listA2 include-any-list; 


Verifying Abstract Hop Configuration 


434 


The show mpls abstract hop membership <abstract hop name> command is used to view members of an 
abstract hop. The command output provides the abstract hop to traffic engineering database node mapping. 


user@host> show mpls abstract-hop-membership 


Abstract hop: hoplA 

Cree Callons sistas 
Neleeosss 1285102. 165,105 
Nelekeesis9g IZ, 102, 66.257) 
Address: 128.102.168.0 
Melheess se IZ} LOZ. LIS, L2s) 


Abstract hop: hopB 
Credibility: 0 
Meleheasss ILZt, LOZ, LEO 5 Bile 
Addresis 28.4 OF Ake 5). 5 
AGGizesis se SOO 6G 2S 7 
Aclkekeesey 123.102 LIS .1S7 
Addwesise eE28 OA a Zk 16 


Here, the output field Credibility indicates the credibility associated with interior gateway protocol in use. 


The output of the show ted database extensive local command provides the view captured in traffic 


engineering database. A keyword local is added to indicate that the output would include any local 


instrumentation. The command output shows the abstract hop as an attribute of links that satisfy the 


associated logical combination of link attributes. 


user@host> show ted database extensive local 


TED database: 0 ISIS nodes 8 INET nodes 
Nodembp: 128-7102 17/3723 
Type: Rtr, Age: 3098 secs, Linkin: 4, LinkOut: 3 








Protocol. Were (0l0 0.0) 


126. 102 eS. 0, tocels 1.2.0.1, Remove, 1.3.0.2 


Local interface index: 332, Remote interface index: 0 





Color: 0x2 green 
Abstract hops: hopA 


Metric: 1 

Static BW: 1000Mbps 

Reservable BW: 1000Mbps 

Available BW [priority] bps: 
[0] 970Mbps [1] 970Mbps [2] 970Mbps [3] 970Mbps 
[4] 970Mbps [5] 970Mbps [6] 970Mbps [7] 970Mbps 
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Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] 970Mbps [1] 970Mbps [2] 970Mbps 
[4] 970Mbps [5] 970Mbps [6] 970Mbps 


Toe de, 102,165,105, Local: 1.1.0.1, Remote: 1.1.0. 





[3] 
Wal 
2 


Local interface index: 330, Remote interface index: 0 


Sige So@wiels 
Abstract hops: hopB 
Metric: 1 
Static BW: 1000Mbps 
Reservable BW: 1000Mbps 
Available BW [priority] bps: 
[0] 960Mbps [1] 960Mbps [2] 960Mbps 
[4] 960Mbps [5] 960Mbps [6] 960Mbps 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] 960Mbps [1] 960Mbps [2] 960Mbps 
[4] 960Mbps [5] 960Mbps [6] 960Mbps 


Abstract hop hopA is for low latency AND SRLG west, and abstract hop hopB is for excluding SRLG west. 


Figure 29 on page 436 displays the ingress view of these abstract hops. 


Figure 29: Ingress View of Abstract Hops 





Hop A Hop B 


970Mbps 
970Mbps 


960Mbps 


960Mbps 


960Mbps 
960Mbps 
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Using Abstract Hops in Path Constraint 


The user associates a unique identifier with each abstract hop definition. This identifier is used for referring 
to the abstract hop in the path constraint. A sequence of abstract hops can be specified as the path 
constraint, similar to how real IP hops are used. The path constraint could also be a sequence of abstract 
hops interleaved by real IP hops. 


Using abstract hops or real hops in a path constraint requires more than one Constrained Shortest Path 
First pass to the destination, typically one pass per hop. When real hops are provided as the path constraint, 
the constraint computation involves as many passes as the number of hops in the path constraint, where 
each pass ends on reaching a hop in the constraint list. The starting point for each pass is the destination 
of the previous pass, with the first pass using the ingress router as the start. 


Alternatively, when path constraint uses strict or loose abstract hops, constraint computation comprises 
passes where each pass processes the subsequent abstract hop in the constraint list. In such a case, more 
than one node qualifies to be the destination for the pass. The set of nodes is called the viable router set 
for the pass. 


An abstract hop traverses member nodes by using the following: 
e Links that satisfy the logical combination of defined constituent attributes 
e Any kind of links 


The means of abstract hops traversing the member nodes is controlled by the use of the abstract hop 
qualifiers—strict, loose, and loose-link—in defining the path constraint. Taking for example, abstract hop 
hopA is processed differently with different qualifiers: 


e Strict—After the last processed hop in the constraint list, the path traverses only links or nodes having 
membership of abstract hop hopA, before reaching a node with hopA’s membership that is a feasible 
starting point for processing the next abstract hop. 


Loose—After the last processed hop in the constraint list, the path can traverse any real nodes that do 
not have abstract hop membership of hopA, before reaching a node with abstract hop membership 
hopA, which is a feasible starting point for processing the next abstract hop. 


Loose-link—After the last processed hop in the constraint list, the path can traverse any real nodes that 
do not have abstract hop membership of hopA, before reaching a node with abstract hop membership 
hopA, which is a feasible starting point for processing the next abstract hop. But the path should have 
traversed at least one link of abstract hop hopA membership in the course of the same. 


In other words, the abstract hop of type loose-link is said to be processed only if any of the viable routers 


in the constraint is reachable through a link of associated abstract hop membership. 


Sample Abstract Hops Specification 


Table 13 on page 438 provides sample use case for using abstract hops in path constraints. 
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Table 13: Using Abstract Hops in Path Constraints 


Purpose of Path 
Constraint 


Traverse nodes that 
are members of hopA 
taking only links that 
satisfy hopA. 


Traverse nodes that 
are members of hopA 
but not necessarily 
links that satisfy 
hopA 


Traverse nodes that 
are members of hopA 
by taking at least one 
link that satisfies 
hopA. 


Abstract 

Hop 

Qualifier Configuration 

Strict [edit protocols mpls] 
Path path_hopA_s { 

hopA abstract strict; 

} 

Loose [edit protocols mpls] 
Path path_hopA_l { 

hopA abstract loose; 

} 

Loose-link [edit protocols mpls] 
Path path_hopA_ll { 

NOTE: The hopA abstract 

Joppa line loose-link; 

qualifier is } 

viewed as 

loose 

followed by 

strict for the 

same abstract 

hop. In other 

words, hopA 

loose-link is 

the same as 

hopA loose 

and hopA 


strict. 


Viable Router Set 


All members of 
abstract hopA. That is, 
Al, A2...An. 


All members of 
abstract hopA. That is, 
Al, A2...An. 


In this case, there are 
two computation 
passes associated 
with hopA in the path 
constraint. The viable 
router set for both 


passes is: 


All members of 
abstract hopA. That is, 
Al, A2...An. 


NOTE: During path 
computation, a router 
is traversed only once. 
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Affinity 


hopA (pick only links 
that satisfy abstract 
hopA). 


None (any kind of 
links). 


In this case, there are 
two computation 
passes associated 
with hopA in the path 
constraint. The 
affinity for the two 
passes is: 


e Pass 1—None (any 
kind of links). 

e Pass 2—hopA (pick 
only links that 


satisfy abstract 
hopA). 


Table 13: Using Abstract Hops in Path Constraints (continued) 


Abstract 
Hop 
Qualifier 


Purpose of Path 
Constraint 
Traverse nodes that | Strict 
are members of 

hopA, taking only 

links that satisfy 

hopA, followed by 

nodes that are 

members of hopB 

taking only links that 
satisfy hopB. 


Strict and 
loose 


Traverse nodes that 
are members of hopA 
taking only links that 
satisfy hopA, 
followed by nodes 
that are members of 
hopB taking any kind 
of links. 

Traverse nodes that | Loose 
are members of hopA 

by taking any kinds 

of links, followed by 

nodes that are 

members of hopB 

taking any kind of 

links. 


Configuration 


[edit protocols mpls] 
Path path_hopA_hopB_s 
{ 
hopA abstract strict; 
hopB abstract strict; 


[edit protocols mpls] 
Path path_hopA_s_hopB_| 
{ 
hopA abstract strict; 
hopB abstract loose; 


[edit protocols mpls] 
Path path_hopA_|_hopB_| 
{ 
hopA abstract loose; 
hopB abstract loose; 


Viable Router Set 


e hopA—Intersection 
of member set of 
hopA and hopB. 


NOTE: When an 
abstract hop is 
followed by a strict 
abstract hop, the 
intersection of the 
two member sets is 
considered as 
viable router set. 


e hopB—All members 
of abstract hopB. 
That is, B1, B2...Bn. 


e hopA—All members 
of abstract hopA. 
That is, A1, A2...An. 


e hopB—All members 
of abstract hopB. 
That is, B1, B2...Bn. 


e hopA—All members 
of abstract hopA. 
That is, A1, A2...An. 


e hopB—All members 


of abstract hopB. 
That is, B1, B2...Bn. 
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Affinity 


e hopA—hopA (pick 
only links that 
satisfy abstract 
hopA). 

e hopB—hopB (pick 
only links that 
satisfy abstract 
hopB). 


e hopA—hopA (pick 
only links that 
satisfy abstract 
hopA). 

e hopB—None (pick 
any links). 


None (pick any links). 
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Table 13: Using Abstract Hops in Path Constraints (continued) 


Abstract 
Purpose of Path Hop 
Constraint Qualifier Configuration Viable Router Set Affinity 
Traverse nodes that | Loose and [edit protocols mpls] e hopA—Intersection | e hopA—None (pick 
are members of hopA | strict Path path_hopA_|_hopB_s of the members of any links). 
by taking any kinds { hopA and hopB. e hopB—hopB (pick 
of links, followed by hopA abstract loose; When an abstract only links that 
nodes that are hopB abstract strict; hop is followed by satisfy abstract 
members of hopB } a strict abstract hopB). 
taking only links that hop, the 
satisfy hopB. intersection of the 


two member sets is 
considered as 
viable router set. 


hopB—All members 
of abstract hopB. 
That is, B1, B2...Bn. 


Figure 30 on page 440 displays path constraints for abstract hops hopA, hopB, and hopC with loose, strict, 
and loose abstract hop qualifiers, respectively. 


Figure 30: Sample Path Constraints for Abstract Hops 











Ingress 
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Hop A 


The Constrained Shortest Path First passes for the abstract hops are as follows: 


e Pass 1 associated with hopA 
e Viable routers—Routers R1 and R2 (intersection of hopA and hopB, as hopB is a strict abstract hop). 


e Affinity—None (as hopA is loose). 


e Pass 2 associated with hopB 
e Viable routers—Routers R1, R2, R3, and R4 


e Affinity—Pick only hopB-compliant links (as hopB is a strict abstract hop). 


e Pass 3 associated with hopC 
e Viable routers—Routers R5, R6, R7, and the egress router. 


e Affinity—None (as hopC is a loose abstract hop). 


Path Computation and Backtracking 


In each Constrained Shortest Path First pass, when the nearest router from a viable router set is reached 
using links satisfying the affinity figured for the pass, the abstract hop associated with the pass is said to 
be processed. The viable router thus reached serves as the start for the next constraint pass. If any constraint 
pass fails, and it is not the one with the ingress router as start router, then the pass is backtracked to the 
previous pass and the process is repeated. 


Sample Backtracking 


When a Constrained Shortest Path First pass p (other than the first one) fails, the exit router of the previous 
pass (p - 1) that served as start for the current pass p is disqualified in the viable router set of the previous 
pass (p - 1). Then the previous pass (p - 1) is re-executed to find the next best exit router or destination 
for the pass p - 1 from the viable router set. 


The router thus determined serves as the new start router for the pass p. This procedure is repeated as 
long as there are failures and there are viable routers that are not explored. 


The show mpls Isp abstract-hop-computation name Isp-name command provides the various computation 
passes involved per LSP and the qualifying exit routers for each pass. The command output also gives the 
affinity per pass, and shows the current start router chosen for the pass. For each viable router, the state 
of backtracking is displayed, where it can be either valid or disqualified. 


user@host> show mpls Isp abstract-computation 


Path computation using abstract hops for LSP: lspl 
Path type: Primary, Path name: pathl 


(Ciderclosibaiey7e OW, aveieall inte; Cir (Sin jesse 4 

CSPt pass mOg 0) Stcewsc acklcass Of tle jesse 124 102. 17S. 123) 
Affinity: hopA 
CSPF pass no: 1 Start address of the pass: 0.0.0.0 
DAScaimaicshoms LAS, LOZ L72,L57, , Sieaieee Wein) 





Path type: Standby, Path name: path2 
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Credibility: 0, Total no of CSPF passes: 3 

CSPF pass no: 0 Start address of the pass: 128.102.173.123 
DESitamacioms IS IO2Z 1G6.237, -, Sieeiees WA) 

Affinity: hopA 
CSPEN Passeue le Staremaddrcs sor mene passim zGr lO Ze nG Goi) 
DSSHesineicsoms 128) 102 160,21, , Sieaieee WAIN.) 

DaKeameicsoms L268 102,165.55, , Sieeeas WANED 

Desittinat lon 2io me lO2 Gon 243i) ar, ee cicle CVE» 

DESitimsiciom?s IZ 102 172,157, , Sieeiees wi) 

DESitaimeieroms IAS MO2Z 172.196, - Sieeieeys WAwic) 

Affinity: hopB 
CSIs jas MO 2 Sieewec aclelicasis Oe ilove joes iz oil 6 72 5 LS) 
DSSiesineieaoms 12s) Oe 72157, , SieeieSs WwAI00) 





The output field Credibility indicates the credibility associated with the interior gateway protocol in use. 


Example: Configuring Abstract Hops for MPLS LSPs 
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This example shows how to configure abstract hops for MPLS label-switched paths (LSPs). Abstract hops 
combine the key features of existing traffic engineering constraints that enables the user to specify an 
order-aware and resilient path constraint for MPLS LSPs. 


Requirements 


This example uses the following hardware and software components: 


e Six devices that can be a combination of M Series Multiservice Edge Routers, MX Series 5G Universal 
Routing Platforms, T Series Core Routers, and PTX Series Packet Transport Routers. 


e Junos OS Release 17.1 or later running on all the devices. 
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Before you begin: 


e Configure the device interfaces. 

e Configure the device router ID and assign an autonomous system (AS) number. 

e Configure RSVP on all the devices. 

e Configure OSPF or any other interior gateway protocol on all the devices. 

e Configure administrative groups, extended administrative groups, and Shared Risk Link Groups (SRLGs) 


on all the devices. 


Overview 


Junos OS Release 17.1 introduces abstract hops, which are user-defined router clusters or groups. Similar 
to the sequence of real-hop constraints (strict or loose), a sequence of abstract hops can be used for setting 
up a label-switched path (LSP). A path can use a combination of real and abstract hops as constraints. 


An abstract hop is a logical combination of the existing traffic engineering constraints, such as administrative 
groups, extended administrative groups, and SRLGs, along with the ordering property of real hops. As a 
result, when a sequence of abstract hops is used in a path constraint, ordering is achieved among the 
groups of routers that meet a logical combination of link or node attributes called constituent attributes. 


To configure abstract hops: 


e Create constituent lists with constituent traffic engineering attributes by including the constituent-list 
list-name statement at the [edit protocols mpls] hierarchy level. 


e Include the constituent lists in the abstract hop definition at the [edit protocols mpls abstract-hop 
abstract-hop-name] hierarchy level. 


e Define path constraints that use abstract hops at the [edit protocols mpls path path-name] hierarchy 
level. 


Take the following guidelines under consideration when configuring abstract hops for MPLS LSPs: 


e Abstract hops are supported only in the master routing instance of a device. 
e IPvé destinations are not supported in abstract hop constraints (only IPv4 destinations work). 
e Abstract hops can be strict or loose constraints. 


e Abstract hops support in Junos OS Release 17.1 is provided only for intra-area MPLS LSPs and not for 
inter-domain, or inter-area LSPs. 


e Abstract hop constraints is enabled for regular point-to-point LSPs only. Other types of MPLS LSPs, 
such as point-to-multipoint LSPs, externally controlled bidirectional LSPs, dynamic container LSPs, RSVP 
automesh LSPs, and inter-area LSPs are not supported with abstract hops configuration. 


e Abstract hops do not enable computation of overall shortest path for LSPs. 


e An abstract hop must not be referred to more than once in the same path constraint. 


Aaa 


e Abstract hop constraint specifications do not affect the support for Graceful Routing Engine switchover 
(GRES), unified in-service software upgrade (ISSU), and nonstop routing (NSR). 


e Abstract hop constraint specifications do not affect overall network performance. However, the time 
taken for constrained shortest path first computation increases with abstract hop configuration. The 
setup time for an abstract hop LSP is more than the time taken to set up an LSP without abstract hop 
configuration. 


Topology 


Figure 31 on page 444 illustrates a sample network topology configured with abstract hops. Devices RO 
and R3 are each connected to hosts (Host 1 and Host 2). Devices R4 and R5 are each connected to Devices 
RO, R1, R2, and R3. Devices R1 and R2 are also directly connected to each other. 


Devices RO and R3 are configured under the same autonomous system—AS 64496. An MPLS LSP is 
configured from Device RO through Device R3 with one primary path and two secondary paths (standby 
and nonstandby secondary paths). 


Four constituent lists—c1, c2, c3, and c4—are created using three SRLGs (g1, g2, and g3), three administrative 
groups (green, blue, and red), and one extended administrative group (gold). Three abstract hops (ah1, ah2, 
and ah3) are defined using the configured constituent lists, and are specified as path constraints. Abstract 
hop ah1 is specified as constraint for the primary path, while abstract hops ah2 and ah3 are specified as 
constraints for the secondary standby path and the secondary nonstandby path, respectively. 


Figure 31: Configuring Abstract Hop Path Constraint 
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Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


Device RO 


set chassis network-services ip 

set interfaces ge-0/0/0 unit 0 family inet address 172.16.0.1/16 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 172.18.0.1/16 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 172.17.0.1/16 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 172.30.0.1/16 

set interfaces loO unit O family inet address 127.0.0.6/8 

set routing-options srlg g1 srlg-value 100 

set routing-options srlg g1 srlg-cost 1000 

set routing-options srlg g2 srlg-value 200 

set routing-options srlg g2 srlg-cost 2000 

set routing-options srlg g3 srlg-value 300 

set routing-options srlg g3 srlg-cost 3000 

set routing-options administrative-groups-extended-range minimum 50000 
set routing-options administrative-groups-extended-range maximum 60000 
set routing-options administrative-groups-extended gold group-value 50000 
set routing-options router-id 127.0.0.6 

set routing-options autonomous-system 64496 

set routing-options forwarding-table export test 

set protocols rsvp interface all aggregate 

set protocols rsvp interface fxp0.0 disable 

set protocols rsvp interface ge-0/0/0.0 bandwidth 80m 

set protocols rsvp interface ge-0/0/2.0 bandwidth 200m 

set protocols rsvp interface ge-0/0/1.0 bandwidth 500m 

set protocols mpls administrative-groups green 0 

set protocols mpls administrative-groups blue 1 

set protocols mpls administrative-groups red 2 

set protocols mpls label-switched-path RO-R31 to 127.0.0.3 

set protocols mpls label-switched-path RO-R31 primary prim 

set protocols mpls label-switched-path RO-R31 secondary stdby standby 
set protocols mpls label-switched-path RO-R31 secondary nonstdby 

set protocols mpls path path_primary 172.16.0.2 strict 
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set protocols mpls path path_primary 172.21.0.2 strict 

set protocols mpls path path_primary 172.24.0.2 strict 

set protocols mpls path path_ter_nonstdby 172.18.0.1 strict 

set protocols mpls path path_ter_nonstdby 172.26.0.2 strict 

set protocols mpls path path_sec_stdby 172.17.0.2 strict 

set protocols mpls path path_sec_stdby 172.23.0.2 strict 

set protocols mpls path prim ah1 abstract 

set protocols mpls path prim ah1 strict 

set protocols mpls path stdby ah2 abstract 

set protocols mpls path stdby ah2 strict 

set protocols mpls path nonstdby ah3 abstract 

set protocols mpls path nonstdby ah3 strict 

set protocols mpls constituent-list c1 srlg g1 

set protocols mpls constituent-list c1 administrative-group green 

set protocols mpls constituent-list c2 administrative-group green 

set protocols mpls constituent-list c2 administrative-group-extended gold 
set protocols mpls constituent-list c3 srlg g2 

set protocols mpls constituent-list c3 administrative-group red 

set protocols mpls constituent-list c3 administrative-group-extended gold 
set protocols mpls constituent-list c4 srlg g3 

set protocols mpls constituent-list c4 administrative-group blue 

set protocols mpls constituent-list c4 administrative-group-extended gold 
set protocols mpls abstract-hop ah1 operator AND 

set protocols mpls abstract-hop ah1 constituent-list c1 include-all-list 

set protocols mpls abstract-hop ah1 constituent-list c2 include-all-list 

set protocols mpls abstract-hop ah2 operator AND 

set protocols mpls abstract-hop ah2 constituent-list c3 include-all-list 

set protocols mpls abstract-hop ah3 operator AND 

set protocols mpls abstract-hop ah3 constituent-list c4 include-all-list 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols mpls interface ge-0/0/0.0 srlg g1 

set protocols mpls interface ge-0/0/0.0 administrative-group green 

set protocols mpls interface ge-0/0/0.0 administrative-group-extended gold 
set protocols mpls interface ge-0/0/2.0 srlg g2 

set protocols mpls interface ge-0/0/2.0 administrative-group red 

set protocols mpls interface ge-0/0/2.0 administrative-group-extended gold 
set protocols mpls interface ge-0/0/1.0 srlg g3 

set protocols mpls interface ge-0/0/1.0 administrative-group blue 

set protocols mpls interface ge-0/0/1.0 administrative-group-extended gold 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 
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set protocols ospf area 0.0.0.0 interface fxp0.0 disable 
set policy-options policy-statement test then load-balance per-packet 


Device R1 


set interfaces ge-0/0/0 unit 0 family inet address 172.16.0.2/16 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 172.21.0.1/16 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 172.20.0.1/16 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 172.19.0.1/16 

set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 127.0.0.1/8 

set routing-options srlg g1 srlg-value 100 

set routing-options srlg g1 srlg-cost 1000 

set routing-options srlg g2 srlg-value 200 

set routing-options srlg g2 srlg-cost 2000 

set routing-options srlg g3 srlg-value 300 

set routing-options srlg g3 srlg-cost 3000 

set routing-options administrative-groups-extended-range minimum 50000 
set routing-options administrative-groups-extended-range maximum 60000 
set routing-options administrative-groups-extended gold group-value 50000 
set routing-options router-id 127.0.0.1 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls administrative-groups green 0 

set protocols mpls administrative-groups blue 1 

set protocols mpls administrative-groups red 2 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols mpls interface ge-0/0/0.0 srig g1 

set protocols mpls interface ge-0/0/0.0 administrative-group green 

set protocols mpls interface ge-0/0/0.0 administrative-group-extended gold 
set protocols mpls interface ge-0/0/1.0 srlg g1 

set protocols mpls interface ge-0/0/1.0 administrative-group green 

set protocols mpls interface ge-0/0/1.0 administrative-group-extended gold 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 
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Device R2 


set interfaces ge-0/0/0 unit 0 family inet address 172.22.0.2/16 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 172.21.0.2/16 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 172.24.0.1/16 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 172.25.0.1/16 

set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 127.0.0.2/8 

set routing-options srlg g1 srlg-value 100 

set routing-options srlg g1 srlg-cost 1000 

set routing-options srlg g2 srlg-value 200 

set routing-options srlg g2 srlg-cost 2000 

set routing-options srlg g3 srlg-value 300 

set routing-options srlg g3 srlg-cost 3000 

set routing-options administrative-groups-extended-range minimum 50000 
set routing-options administrative-groups-extended-range maximum 60000 
set routing-options administrative-groups-extended gold group-value 50000 
set routing-options router-id 127.0.0.2 

set protocols rsvp interface all aggregate 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls administrative-groups green O 

set protocols mpls administrative-groups blue 1 

set protocols mpls administrative-groups red 2 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols mpls interface ge-0/0/1.0 srlg g1 

set protocols mpls interface ge-0/0/1.0 administrative-group green 

set protocols mpls interface ge-0/0/1.0 administrative-group-extended gold 
set protocols mpls interface ge-0/0/2.0 srig g1 

set protocols mpls interface ge-0/0/2.0 administrative-group green 

set protocols mpls interface ge-0/0/2.0 administrative-group-extended gold 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


Device R3 
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set interfaces ge-0/0/0 unit 0 family inet address 172.26.0.2/16 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 172.23.0.2/16 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 172.24.0.2/16 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 172.31.0.1/16 

set interfaces loO unit O family inet address 127.0.0.3/8 

set routing-options srlg g1 srlg-value 100 

set routing-options srlg g1 srlg-cost 1000 

set routing-options srlg g2 srlg-value 200 

set routing-options srlg g2 srlg-cost 2000 

set routing-options srlg g3 srlg-value 300 

set routing-options srlg g3 srlg-cost 3000 

set routing-options administrative-groups-extended-range minimum 50000 
set routing-options administrative-groups-extended-range maximum 60000 
set routing-options administrative-groups-extended gold group-value 50000 
set routing-options router-id 127.0.0.3 

set routing-options autonomous-system 64496 

set protocols rsvp interface all aggregate 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls administrative-groups green 0 

set protocols mpls administrative-groups blue 1 

set protocols mpls administrative-groups red 2 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols mpls interface ge-0/0/2.0 srig g1 

set protocols mpls interface ge-0/0/2.0 administrative-group green 

set protocols mpls interface ge-0/0/2.0 administrative-group-extended gold 
set protocols mpls interface ge-0/0/1.0 srlg g2 

set protocols mpls interface ge-0/0/1.0 administrative-group red 

set protocols mpls interface ge-0/0/1.0 administrative-group-extended gold 
set protocols mpls interface ge-0/0/0.0 srlg g3 

set protocols mpls interface ge-0/0/0.0 administrative-group blue 

set protocols mpls interface ge-0/0/0.0 administrative-group-extended gold 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


Device R4 
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set interfaces ge-0/0/0 unit 0 family inet address 172.22.0.1/16 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 172.23.0.1/16 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 172.17.0.2/16 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 172.19.0.2/16 

set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 127.0.0.4/32 

set routing-options srlg g1 srlg-value 100 

set routing-options srlg g1 srlg-cost 1000 

set routing-options srlg g2 srlg-value 200 

set routing-options srlg g2 srlg-cost 2000 

set routing-options srlg g3 srlg-value 300 

set routing-options srlg g3 srlg-cost 3000 

set routing-options administrative-groups-extended-range minimum 50000 
set routing-options administrative-groups-extended-range maximum 60000 
set routing-options administrative-groups-extended gold group-value 50000 
set routing-options router-id 127.0.0.4 

set protocols rsvp interface all aggregate 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls administrative-groups green O 

set protocols mpls administrative-groups blue 1 

set protocols mpls administrative-groups red 2 

set protocols mpls icmp-tunneling 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols mpls interface ge-0/0/2.0 srlg g2 

set protocols mpls interface ge-0/0/2.0 administrative-group red 

set protocols mpls interface ge-0/0/2.0 administrative-group-extended gold 
set protocols mpls interface ge-0/0/1.0 srlg g2 

set protocols mpls interface ge-0/0/1.0 administrative-group red 

set protocols mpls interface ge-0/0/1.0 administrative-group-extended gold 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


Device R5 


set interfaces ge-0/0/0 unit 0 family inet address 172.26.0.1/16 


set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 172.18.0.2/16 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 172.20.0.2/24 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 172.25.0.2/16 

set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 127.0.0.5/8 

set routing-options srlg g1 srlg-value 100 

set routing-options srlg g1 srlg-cost 1000 

set routing-options srlg g2 srlg-value 200 

set routing-options srlg g2 srlg-cost 2000 

set routing-options srlg g3 srlg-value 300 

set routing-options srlg g3 srlg-cost 3000 

set routing-options administrative-groups-extended-range minimum 50000 
set routing-options administrative-groups-extended-range maximum 60000 
set routing-options administrative-groups-extended gold group-value 50000 
set routing-options router-id 127.0.0.5 

set protocols rsvp interface all aggregate 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls administrative-groups green 0 

set protocols mpls administrative-groups blue 1 

set protocols mpls administrative-groups red 2 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols mpls interface ge-0/0/1.0 srlg g3 

set protocols mpls interface ge-0/0/1.0 administrative-group blue 

set protocols mpls interface ge-0/0/1.0 administrative-group-extended gold 
set protocols mpls interface ge-0/0/0.0 srlg g3 

set protocols mpls interface ge-0/0/0.0 administrative-group blue 

set protocols mpls interface ge-0/0/0.0 administrative-group-extended gold 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 


information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device RO: 


1. Enable enhanced IP network services on Device RO. 
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[edit chassis] 
user@RO# set network-services ip 


2. Configure the interfaces on Device RO, including the loopback interface. 


[edit interfaces] 

user@RO# set ge-0/0/0 unit O family inet address 172.16.0.1/16 
user@RO# set ge-0/0/0 unit 0 family mpls 

user@RO# set ge-0/0/1 unit O family inet address 172.18.0.1/16 
user@RO# set ge-0/0/1 unit 0 family mpls 

user@RO# set ge-0/0/2 unit O family inet address 172.17.0.1/16 
user@RO# set ge-0/0/2 unit 0 family mpls 

user@RO# set ge-0/0/3 unit 0 family inet address 172.30.0.1/16 
user@RO# set loO unit O family inet address 127.0.0.6/8 


3. Assign the router ID and autonomous system number for Device RO. 


[edit routing-options] 
user@RO# set router-id 127.0.0.6 
user@RO# set autonomous-system 64496 


4. Configure the SRLG definitions. 


[edit routing-options] 

user@RO# set srlg g1 srlg-value 100 
user@RO# set srlg g1 srig-cost 1000 
user@RO# set srlg g2 srlg-value 200 
user@RO# set srlg g2 srlg-cost 2000 
user@RO# set srlg g3 srlg-value 300 
user@RO# set srlg g3 srlg-cost 3000 


5. Configure the extended administrative group definitions. 


[edit routing-options] 

user@RO# set administrative-groups-extended-range minimum 50000 
user@RO# set administrative-groups-extended-range maximum 60000 
user@RO# set administrative-groups-extended gold group-value 50000 


6. Configure the administrative group definitions. 
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[edit protocols] 

user@RO# set mpls administrative-groups green O 
user@RO# set mpls administrative-groups blue 1 
user@RO# set mpls administrative-groups red 2 


7. Configure MPLS on all the interfaces of Device RO, excluding the management interface. 


[edit protocols] 
user@RO# set mpls interface all 
user@RO# set mpls interface fxp0.0 disable 


8. Assign the interfaces of Device RO with the configured traffic engineering attributes. 


[edit protocols] 

user@RO# set mpls interface ge-0/0/0.0 srlg g1 

user@RO# set mpls interface ge-0/0/0.0 administrative-group green 
user@RO# set mpls interface ge-0/0/0.0 administrative-group-extended gold 
user@RO# set mpls interface ge-0/0/2.0 srlg g2 

user@RO# set mpls interface ge-0/0/2.0 administrative-group red 

user@RO# set mpls interface ge-0/0/2.0 administrative-group-extended gold 
user@RO# set mpls interface ge-0/0/1.0 srlg g3 

user@RO# set mpls interface ge-0/0/1.0 administrative-group blue 
user@RO# set mpls interface ge-0/0/1.0 administrative-group-extended gold 


9. Configure an LSP connecting Device RO with Device R3, and assign primary and secondary path 
attributes to the LSP. 


[edit protocols] 

user@RO# set mpls label-switched-path RO-R31 to 127.0.0.3 

user@RO# set mpls label-switched-path RO-R31 primary prim 

user@RO# set mpls label-switched-path RO-R31 secondary stdby standby 
user@RO# set mpls label-switched-path RO-R31 secondary nonstdby 


10. Define the primary and secondary paths for the RO-R31 LSP. 


[edit protocols] 

user@RO# set mpls path path_primary 172.16.0.2 strict 
user@RO# set mpls path path_primary 172.21.0.2 strict 
user@RO# set mpls path path_primary 172.24.0.2 strict 
user@RO# set mpls path path_ter_nonstdby 172.18.0.1 strict 
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user@RO# set mpls path path_ter_nonstdby 172.26.0.2 strict 
user@RO# set mpls path path_sec_stdby 172.17.0.2 strict 
user@RO# set mpls path path_sec_stdby 172.23.0.2 strict 


11. Create constituent lists with constituent traffic engineering attributes for abstract-hop definitions. 


[edit protocols] 

user@RO# set mpls constituent-list c1 srlg g1 

user@RO# set mpls constituent-list c1 administrative-group green 
user@RO# set mpls constituent-list c2 administrative-group green 
user@RO# set mpls constituent-list c2 administrative-group-extended gold 
user@RO# set mpls constituent-list c3 srlg g2 

user@RO# set mpls constituent-list c3 administrative-group red 

user@RO# set mpls constituent-list c3 administrative-group-extended gold 
user@RO# set mpls constituent-list c4 srlg g3 

user@RO# set mpls constituent-list c4 administrative-group blue 
user@RO# set mpls constituent-list c4 administrative-group-extended gold 


12. Define abstract hops by assigning the configured constituent lists and respective operators. 


[edit protocols] 

user@RO# set mpls abstract-hop ahi operator AND 

user@RO# set mpls abstract-hop ah1 constituent-list c1 include-all-list 
user@RO# set mpls abstract-hop ah1 constituent-list c2 include-all-list 
user@RO# set mpls abstract-hop ah2 operator AND 

user@RO# set mpls abstract-hop ah2 constituent-list c3 include-all-list 
user@RO# set mpls abstract-hop ah3 operator AND 

user@RO# set mpls abstract-hop ah3 constituent-list c4 include-all-list 


13. Define constraints for the configured paths by including abstract hop definitions. 


[edit protocols] 

user@RO# set mpls path prim ah1 abstract 
user@RO# set mpls path prim ah1 strict 
user@RO# set mpls path stdby ah2 abstract 
user@RO# set mpls path stdby ah2 strict 
user@RO# set mpls path nonstdby ah3 abstract 
user@RO# set mpls path nonstdby ah3 strict 


14. Configure RSVP on Device RO. Enable RSVP on all the interfaces of Device RO, excluding the 
management interface and interface connecting to Host1, and assign bandwidth values. 
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[edit protocols] 

user@RO# set rsvp interface all aggregate 

user@RO# set rsvp interface fxp0.0 disable 

user@RO# set rsvp interface ge-0/0/0.0 bandwidth 80m 
user@RO# set rsvp interface ge-0/0/2.0 bandwidth 200m 
user@RO# set rsvp interface ge-0/0/1.0 bandwidth 500m 


15. Configure OSPF on all the interfaces of Device RO, excluding the management interface, and assign 
traffic engineering capabilities. 


[edit protocols] 

user@RO# set ospf traffic-engineering 

user@RO# set ospf area 0.0.0.0 interface all 

user@RO# set ospf area 0.0.0.0 interface fxp0.0 disable 


16. Configure a policy on Device RO to enable load balancing on a per-packet basis. 


[edit policy-options] 
user@RO# set forwarding-table export test 


17. Export the load-balancing policy to the forwarding table. 


[edit policy-options] 
user@RO# set policy-statement test then load-balance per-packet 


Results 

From configuration mode, confirm your configuration by entering the show chassis, show interfaces, show 
routing-options, show protocols, and show policy-options commands. If the output does not display the 
intended configuration, repeat the instructions in this example to correct the configuration. 


user@RO# show chassis 
network-services ip; 


user@RO# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 172.16.0.1/16; 


} 


family mpls; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 172.18.0.1/16; 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 172.17.0.1/16; 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 172.30.0.1/16; 


} 
lo0 { 
unit O { 
family inet { 
address 127.0.0.6/8; 


user@RO# show routing-options 
srlg { 
elt 
srlg-value 100; 
srlg-cost 1000; 
} 
g2 { 
srlg-value 200; 
srlg-cost 2000; 
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} 

g3 { 
srlg-value 300; 
srlg-cost 3000; 


} 
administrative-groups-extended-range { 
minimum 50000; 
maximum 60000; 
} 
administrative-groups-extended { 
gold group-value 50000; 


user@RO# show protocols 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 
} 
interface ge-0/0/0.0 { 
bandwidth 80m; 
} 
interface ge-0/0/2.0 { 
bandwidth 200m; 
} 
interface ge-0/0/1.0 { 
bandwidth 500m; 


} 
mpls { 
administrative-groups { 
green O; 
blue 1; 
red 2; 
} 
label-switched-path RO-R31 { 
to 127.0.0.3; 
adaptive; 
auto-bandwidth { 
adjust-interval 300; 
adjust-threshold 5; 
minimum-bandwidth 10m; 
maximum-bandwidth 1g; 
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} 
primary prim; 
secondary stdby { 
standby; 

} 
secondary nonstdby; 

} 

path path_primary { 
172.16.0.2 strict; 
172.21.0.2 strict; 
172.24.0.2 strict; 

} 

path path_ter_nonstdby { 
172.18.0.1 strict; 
172.26.0.2 strict; 

} 

path path_sec_stdby { 
172.17.0.2 strict; 
172.23.0.2 strict; 

} 

path prim { 
ah1 abstract strict; 

} 

path stdby { 
ah2 abstract strict; 

} 

path nonstdby { 
ah3 abstract strict; 

} 

constituent-list c1 { 
srlg g1; 
administrative-group green; 

} 

constituent-list c2 { 
administrative-group green; 
administrative-group-extended gold; 

} 

constituent-list c3 { 
srlg g2; 
administrative-group red; 
administrative-group-extended gold; 

} 

constituent-list c4 { 
srlg g3; 
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administrative-group blue; 
administrative-group-extended gold; 
} 
abstract-hop ah1 { 
operator AND; 
constituent-list { 
c1 include-all-list; 
c2 include-all-list; 


} 
abstract-hop ah2 { 
operator AND; 
constituent-list { 
c3 include-all-list; 


} 
abstract-hop ah3 { 
operator AND; 
constituent-list { 
c4 include-all-list; 


} 
interface all; 
interface fxp0.0 { 
disable; 
} 
interface ge-0/0/0.0 { 
srlg g1; 
administrative-group green; 
administrative-group-extended gold; 
} 
interface ge-0/0/2.0 { 
srlg g2; 
administrative-group red; 
administrative-group-extended gold; 
} 
interface ge-0/0/1.0 { 
srlg g3; 
administrative-group blue; 
administrative-group-extended gold; 


} 
ospf { 
traffic-engineering; 


area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 


user@RO# show policy-options 
policy-statement test { 
then { 
load-balance per-packet; 


Verification 


IN THIS SECTION 


@ Verifying Abstract Hop Configuration | 460 
@ Verifying Abstract Hop Path Computation | 461 


Confirm that the configuration is working properly. 


Verifying Abstract Hop Configuration 


Purpose 
Verify the members of the abstract hop definition on Device RO by issuing the show mpls 
abstract-hop-membership command, which displays the abstract hop membership tables. 


Action 
From operational mode, run the show mpls abstract-hop-membership command. 


user@RO> show mpls abstract-hop-membership 


Abstract hop: ah1 
Credibility: 0 

Addise'sish W770 -10i6 

Nelcheesss 127 50.0.1 
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Address: 127.0.0.2 
Address: 127.0.0.3 


Abstract hop: ah2 
Gre cdillons listen 
Po Ko brat—¥-t-) BAN OO) 
Adeimesise ml Or Ors 
Melcheasss 1b2°7 510.0 


Abstract hop: ah3 
Credibility: 0 
Address: 127.0.0 
Address: 127.0.0.3 
Address: 127.0.0 


Meaning 


The show mpls abstract-hop-membership command output provides the abstract hop to traffic engineering 
database node mapping. The Credibility field displays the credibility value associated with the interior 
gateway protocol in use (OSPF). 


Verifying Abstract Hop Path Computation 


Purpose 


Verify the abstract computation preprocessing for LSPs on Device RO by issuing the show mpls Isp 
abstract-computation command. 


Action 
From operational mode, run the show mpls Isp abstract-computation command. 


user@RO> show mpls Isp abstract-computation 


Path computation using abstract hops for LSP: RO-R31 


Path type: Primary, Pathname: prim 


Credibility: 0, Total no of CSPF passes: 2 
CSEHS Passa 70) 
Start address of the pass: 127.0.0.6 
Dasiciineciems 127 0,0, Sireieee WARD) 
DASicsvecsems 127 0,02, Sicaieee WwAbIp) 





Desicaimeresoms 127 ,0,0,3, Sireicae WALID 
AGRE ioaLiEW Ss eulovil 
CSPE pals sinless 
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Start address of the pass: 127.0.0.1 
Destination: 127.0.0.3, State: VALID 
Path type: Secondary, Path name: nonstdby 


Path type: Standby, Pathname: stdby 


Cuediloa kitty 100s Lo cllemonotNeSER Soassesis2 
CSPH Passe no can0 
Start address of the pass: 127.0.0.6 
Destination: lA OMOkS aicteatonn. AllnisD 
Desicaloeicikem?s 127 0,04, Siteiees WeAunI00) 
MEE LigiiEWws ila? 





CSPEO cls Sueno cm 
Start address of the pass: 127.0.0.4 


Destination: 127.0.0.3, State: VALID 


Meaning 

The show mpls Isp abstract-hop-computation command output provides the various computation passes 
involved per LSP, and the qualifying exit devces for each pass. The command output also gives the affinity 
per pass, and shows the current start device chosen for the pass. For each viable router (device), the state 
of backtracking is displayed, where it can either be valid or disqualified. 


The Credibility field indicates the credibility value associated with the interior gateway protocol in use 
(OSPF). 


Configuring the Maximum Number of MPLS Labels 


For interfaces that you configure for MPLS applications, you can set the maximum number of labels upon 
which MPLS can operate. 


By default, the maximum number of labels is three. You can change the maximum to four labels or five 
labels for applications that require four or five labels. 


Starting in Junos OS Release 19.1R1, the maximum number of labels that can be pushed by the egress 
Packet Forwarding Engine (PFE) can be leveraged, wherein the number of labels that can be pushed for 
an MPLS next hop is the number of labels the device is capable of pushing, or the maximum-labels 
configured under family mpls of the outgoing interface, whichever is smaller. This support is enabled on 
MX Series routers with MPC and MIC interfaces, and PTX Series routers with third-generation FPCs. 


The increased label push capability is useful for features, such as segment routing traffic-engineering LSPs 
and RSVP-TE pop-and-forward LSPs. All existing functionality of applications using MPLS next hops 
continue to work with the increased label push capability. This includes: 


e All OAM utilities, such as Isping, traceroute, and BFD for MPLS LSPs. 
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e Monitoring utilities, such as Ispmon, and LM DM for MPLS LSPs. 


The show route table and show route forwarding-table command outputs are enhanced to display up to 
16 labels per next hop component. 


For example: 


user@host> show route table inet.3 








inet.3: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 
+ = Active Route, Last Active, * = Both 
11.0.0, L7/32 *(SPRING-TE/8] 00:02:16, metric 1 





> to 192,142.28 waa ge-O/0/2.0, Pus LOOOLIS, Pusin LOO0LL4, 
Push 1000113, Push 1000112, Push 1000111, Push 1000110, Push 1000109, Push 1000108, 
Push 1000107, Push 1000106, Push 1000105, Push 1000104, Push 1000103, Push 1000102, 
Push 1000101 (top) 
CO 192 1,32 wia Ga—0/0/4.0, Pusan IOOOLIS, Pwsin 1HOOII14, 
Ruslana TOOLS, Rusia LOOOLIZ, Risley OOO, Bysin LOOOLLO, Rieisln LOOOLOS, leribisio, OOOO, 
Rush wi OOO Pushes O0OLOG  Seush OOOO See tsihes 00004 Pusha OURO s Push OO ONO 2, 
Push 1000101 (top) 








NOTE: When the maximum number of MPLS labels of an interface is modified, the MPLS interface 
is bounced. All LDP and RSVP sessions on that interface are restarted, resulting in all LSPs over 
that interface to flap. 


For example, suppose you configure a two-tier carrier-of-carriers VPN service for customers who provide 
VPN service. A carrier-of-carrier VPN is a two-tiered relationship between a provider carrier (Tier 1 ISP) 
and a customer carrier (Tier 2 ISP). In a carrier-of-carrier VPN, the provider carrier provides a VPN backbone 
network for the customer carrier. The customer carrier in turn provides Layer 3 VPN service to its end 
customers. The customer carrier sends labeled traffic to the provider carrier to deliver it to the next hop 
on the other side of the provider carrier’s network. This scenario requires a three-label stack: one label for 
the provider carrier VPN, another label for the customer carrier VPN, and a third label for the transport 


route. 


If you add fast reroute service, the PE routers in the provider carrier’s network must be configured to 
support a fourth label (the reroute label). If the customer carrier is using LDP as its signaling protocol and 
the provider carrier is using RSVP, the provider carrier must support LDP over RSVP tunnel service. This 
additional service requires an additional label, for a total of five labels. 


To the customer carrier, the router it uses to connect to the provider carrier's VPN is a PE router. However, 


the provider carrier views this device as a CE router. 
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Table 14 on page 464 summarizes the label requirements. 


Table 14: Sample Scenarios for Using 3, 4, or 5 MPLS Labels 


Number of Labels Required Scenarios 

3 Carrier-of-carriers VPN or a VPN with two labels and fast reroute 

4 Combination of carrier-of-carriers and fast reroute 

5 Carrier-of-carriers with fast reroute and the customer carrier running LDP, 


with the provider carrier running RSVP 


To configure and monitor the maximum number of labels: 
1. Specify the maximum on the logical interface. Apply this configuration to the carrier’s PE routers. 


[edit interfaces ge-0/1/3 unit 0 family mpls] 


user@switch# set maximum-labels maximum-limit 
2. Verify the configuration. 


[edit system] 


user@switch# show interfaces ge-0/1/3.0 


Logical interface ge-0/1/3.0 (Index 77) (SNMP ifIndex 507) 














Flags: SNMP-Traps Encapsulation: ENET2 





Input packets : 0 
Output packets: 0 
Protocol mpls, MTU: 1480, Maximum labels: 8 


Flags: Is-Primary 


The command output includes the Maximum labels: 5 field under the logical interface unit O. 


Configuring MPLS to Pop the Label on the Ultimate-Hop Router 


You can control the label value advertised on the egress router of a label-switched path (LSP). The default 
advertised label is label 3 (Implicit Null Label). If label 3 is advertised, the penultimate-hop router removes 
the label and sends the packet to the egress router. By enabling ultimate-hop popping, label O (IPv4 Explicit 
Null Label) is advertised. Ultimate-hop popping ensures that any packets traversing an MPLS network 
include a label. 
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NOTE: Juniper Networks routers queue packets based on the incoming label. Routers from 
other vendors might queue packets differently. Keep this in mind when working with networks 
containing routers from multiple vendors. 


To configure MPLS to pop the label on the ultimate-hop router, include the explicit-null statement: 


explicit-null; 


You can configure this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


Advertising Explicit Null Labels to BGP Peers 


For the IPv4 (inet) family only, BGP peers in a routing group can send an explicit NULL label for a set of 
connected routes (direct and loopback routes) for the inet labeled-unicast and inet6 labeled-unicast NLRI. 
By default, peers advertise label 3 (implicit NULL). If the explicit-null statement is enabled, peers advertise 
label O (explicit NULL). The explicit NULL labels ensures that labels are always present on packets traversing 
an MPLS network. If the implicit NULL label is used. the penultimate hop router removes the label and 
sends the packet as a plain IP packet to the egress router. This might cause issues in queuing the packet 
properly on the penultimate hop router if the penultimate hop is another vendor’s router. Some other 
vendors queue packets based on the CoS bits in the outgoing label rather than the incoming label. 


To advertise an explicit null label, include the following statements in the configuration: 


family inet { 
lJabeled-unicast { 
aggregate-label { 
community community-name: 
} 
explicit-null { 
connected-only; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


The connected-only statement is required to advertise explicit null labels. 
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To verify that the explicit NULL label is being advertised for connected routes, use the show route 
advertising-protocol bgp neighbor-address command. 


Understanding MPLS Label Operations on EX Series Switches 


IN THIS SECTION 


MPLS Label-Switched Paths and MPLS Labels on the Switches | 466 
Reserved Labels | 467 
MPLS Label Operations on the Switches | 468 


Penultimate-Hop Popping and Ultimate-Hop Popping | 469 


In the traditional packet-forwarding paradigm, as a packet travels from one switch to the next, an 
independent forwarding decision is made at each hop. The IP network header is analyzed and the next 
hop is chosen based on this analysis and on the information in the routing table. In an MPLS environment, 
the analysis of the packet header is made only once, when a packet enters the MPLS tunnel (that is, the 
path used for MPLS traffic). 


When an IP packet enters a label-switched path (LSP), the ingress provider edge (PE) switch examines the 
packet and assigns it a label based on its destination, placing the label in the packet’s header. The label 
transforms the packet from one that is forwarded based on its IP routing information to one that is 
forwarded based on information associated with the label. The packet is then forwarded to the next 
provider switch in the LSP. This switch and all subsequent switches in the LSP do not examine any of the 
IP routing information in the labeled packet. Rather, they use the label to look up information in their label 
forwarding table. They then replace the old label with a new label and forward the packet to the next 
switch in the path. When the packet reaches the egress PE switch, the label is removed, and the packet 
again becomes a native IP packet and is again forwarded based on its IP routing information. 


This topic describes: 


MPLS Label-Switched Paths and MPLS Labels on the Switches 


When a packet enters the MPLS network, it is assigned to an LSP. Each LSP is identified by a label, which 
is a short (20-bit), fixed-length value at the front of the MPLS label (32 bits). Labels are used as lookup 
indexes for the label forwarding table. For each label, this table stores forwarding information. Because 
no additional parsing or lookup is done on the encapsulated packet, MPLS supports the transmission of 
any other protocols within the packet payload. 
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4 
NOTE: The implementation of MPLS on Juniper Networks EX3200 and EX4200 Ethernet 
Switches supports only single-label packets. However, MPLS on Juniper Networks EX8200 


Ethernet Switches supports packets with as many as three labels. 


Figure 32 on page 467 shows the encoding of a single label. The encoding appears after data link layer 
headers, but before any network layer header. 


Figure 32: Label Encoding 





MPLS label 
Ethernet header (32 bits) IP packets 


0 1 2 3 
01234567890123456789012345678901 





Label | EXP |S| TTL 
bd DS ee 





Label: Label value, 20 bits 

EXP: Class of service, 3 bits (also known as experimental bits) 
S: Bottom of stack, 1 bit 

TTL: Time to live, 8 bits 
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Reserved Labels 


Labels range from O through 1,048,575. Labels O through 999,999 are for internal use. 


Some of the reserved labels (in the range O through 15) have well-defined meanings. The following reserved 
labels are used by the switches: 


e O, IPv4 Explicit Null label—This value is valid only when it is the sole label entry (no label stacking). It 
indicates that the label must be popped on receipt. Forwarding continues based on the IP version 4 
(IPv4) packet. 


e 1, Router Alert label—When a packet is received with a top label value of 1, it is delivered to the local 
software module for processing. 


e 2, IPv6 Explicit Null label—This value is legal only when it is the sole label entry (no label stacking). It 
indicates that the label must be popped on receipt. 


e 3, Implicit Null label—This label is used in the signaling protocol (RSVP) only to request label popping by 
the downstream switch. It never actually appears in the encapsulation. Labels with a value of 3 must not 
be used in the data packet as real labels. No payload type (IPv4 or IPv6) is implied with this label. 
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MPLS Label Operations on the Switches 


EX Series switches support the following label operations: 


e Push 
e Pop 
e Swap 


The push operation affixes a new label to the top of the IP packet. For IPv4 packets, the new label is the 
first label. The time to live (TTL) field value in the packet header is derived from the IP packet header. The 
push operation cannot be applied to a packet that already has an MPLS label. 


The pop operation removes a label from the beginning of the packet. Once the label is removed, the TTL 
is copied from the label into the IP packet header, and the underlying IP packet is forwarded as a native 
IP packet 


The swap operation removes an existing MPLS label from an IP packet and replaces it with a new MPLS 
label, based on the following: 


e Incoming interface 
e Label 


e Label forwarding table 


Figure 28 on page 427 shows an IP packet without a label arriving on the customer edge interface (ge-0/0/1) 
of the ingress PE switch. The ingress PE switch examines the packet and identifies that packet's destination 
as the egress PE switch. The ingress PE switch applies label 100 to the packet and sends the MPLS packet 
to its outgoing MPLS core interface (ge-0/0/5). The MPLS packet is transmitted on the MPLS tunnel 
through the provider switch, where it arrives at interface ge-0/0/5 with label 100. The provider switch 
swaps label 100 to label 200 and forwards the MPLS packet through its core interface (ge-0/0/7) to the 
next hop on the tunnel, which is the egress PE switch. The egress PE switch receives the MPLS packet 
through its core interface (ge-0/0/7), removes the MPLS label, and sends the IP packet out of its customer 
edge interface (ge-0/0/1) to a destination that is beyond the tunnel. 


Figure 33: MPLS Label Swapping 


IP Provider Edge MPLS Provider MPLS Provider Edge IP 
packet Ingress Switch packet Switch packet Egress Switch packet 
ge-0/0/1 Toop] | ge-0/0/5 2ooP | | g2-0/0/7 
Incoming ] Outgoing Label Incoming Outgoing Label Incoming | Outgoing ] 


label, port label, port label, port label, port label, port | label, port 
Nil, 1 100,5 100, 5 200, 7 200, 7 | Nil, 1 




















g020307 


ge-0/0/5 ge-0/0/7 ge-0/0/1 


Figure 33 on page 468 shows the path of a packet as it passes in one direction from the ingress PE switch 
to the egress PE switch. However, the MPLS configuration also allows traffic to travel in the reverse 
direction. Thus, each PE switch operates as both an ingress switch and an egress switch. 
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Penultimate-Hop Popping and Ultimate-Hop Popping 


The switches enable penultimate-hop popping (PHP) by default with IP over MPLS configurations. With 
PHP, the penultimate provider switch is responsible for popping the MPLS label and forwarding the traffic 
to the egress PE switch. The egress PE switch then performs an IP route lookup and forwards the traffic. 
This reduces the processing load on the egress PE switch, because it is not responsible for popping the 
MPLS label. 


On EX8200 switches, you can choose to use either the default, PHP, or to configure ultimate-hop popping. 


e The default advertised label is label 3 (Implicit Null label). If label 3 is advertised, the penultimate-hop 
switch removes the label and sends the packet to the egress PE switch. 


e If ultimate-hop popping is enabled, label 0 (IPv4 Explicit Null label) is advertised and the egress PE switch 
of the LSP removes the label. 


Release History Table 


Release Description 

19.1R1 Starting in Junos OS Release 19.1R1, the maximum number of labels that can be pushed by the 
egress Packet Forwarding Engine (PFE) can be leveraged, wherein the number of labels that can be 
pushed for an MPLS next hop is the number of labels the device is capable of pushing, or the 
maximum-labels configured under family mpls of the outgoing interface, whichever is smaller. This 


support is enabled on MX Series routers with MPC and MIC interfaces, and PTX Series routers with 
third-generation FPCs. 


14.2 Starting with Junos OS Release 14.2, entropy label is supported in mixed mode chassis where the 
entropy label can be configured without enhanced-ip configuration. 
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MPLS and Routing Tables 


The IGPs and BGP store their routing information in the inet.O routing table, the main IP routing table. If 
the traffic-engineering bgp command is configured, thereby allowing only BGP to use MPLS paths for 
forwarding traffic, MPLS path information is stored in a separate routing table, inet.3. Only BGP accesses 
the inet.3 routing table. BGP uses both inet.O and inet.3 to resolve next-hop addresses. If the 
traffic-engineering bgp-igp command is configured, thereby allowing the IGPs to use MPLS paths for 
forwarding traffic, MPLS path information is stored in the inet.O routing table. (Figure 34 on page 470 and 
Figure 35 on page 471 illustrate the routing tables in the two traffic engineering configurations.) 


Figure 34: Routing and Forwarding Tables, traffic-engineering bgp 
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The inet.3 routing table contains the host address of each LSP’s egress router. This routing table is used 
on ingress routers to route packets to the destination egress router. BGP uses the inet.3 routing table on 
the ingress router to help in resolving next-hop addresses. 
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MPLS also maintains an MPLS path routing table (mpls.0), which contains a list of the next label-switched 
router in each LSP. This routing table is used on transit routers to route packets to the next router along 
an LSP. 


Typically, the egress router in an LSP does not consult the mpls.0O routing table. (This router does not need 
to consult mpls.0 because the penultimate router in the LSP either changes the packet's label to a value 
of O or pops the label.) In either case, the egress router forwards it as an IPv4 packet, consulting the IP 
routing table, inet.0, to determine how to forward the packet. 


When a transit or egress router receives an MPLS packet, information in the MPLS forwarding table is 
used to determine the next transit router in the LSP or to determine that this router is the egress router. 


When BGP resolves a next-hop prefix, it examines both the inet.O and inet.3 routing tables, seeking the 
next hop with the lowest preference. If it finds a next-hop entry with an equal preference in both routing 
tables, BGP prefers the entry in the inet.3 routing table. 


Figure 35: Routing and Forwarding Tables, traffic-engineering bgp-igp 
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Generally, BGP selects next-hop entries in the inet.3 routing table because their preferences are always 
lower than OSPF and IS-IS next-hop preferences. When you configure LSPs, you can override the default 
preference for MPLS LSPs, which might alter the next-hop selection process. 


When BGP selects a next-hop entry from the inet.3 routing table, it installs that LSP into the forwarding 
table in the Packet Forwarding Engine, which causes packets destined for that next hop to enter and travel 
along the LSP. If the LSP is removed or fails, the path is removed from the inet.3 routing table and from 
the forwarding table, and BGP reverts to using a next hop from the inet.O routing table. 
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Fast Reroute Overview 


Fast reroute provides redundancy for an LSP path. When you enable fast reroute, detours are precomputed 
and preestablished along the LSP. In case of a network failure on the current LSP path, traffic is quickly 
routed to one of the detours. Figure 36 on page 472 illustrates an LSP from Router A to Router F, showing 
the established detours. Each detour is established by an upstream node to avoid the link toward the 
immediate downstream node and the immediate downstream node itself. Each detour might traverse 
through one or more label-switched routers (or switches) that are not shown in the figure. 


Fast reroute protects traffic against any single point of failure between the ingress and egress routers (or 
switches). If there is a failure in a scaled fast reroute scenario, the devices lose reachability to all the peers 
that were connected through the failed link. This leads to traffic interruption, as the BGP session among 
the devices goes down. If there are multiple failures along an LSP, fast reroute itself might fail. Also, fast 
reroute does not protect against failure of the ingress or egress routers. 


Figure 36: Detours Established for an LSP Using Fast Reroute 
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If anode detects that a downstream link has failed (using a link-layer-specific liveness detection mechanism) 
or that a downstream node has failed (for example, using the RSVP neighbor hello protocol), the node 
quickly switches the traffic to the detour and, at the same time, signals the ingress router about the link 
or node failure. Figure 37 on page 472 illustrates the detour taken when the link between Router B and 
Router C fails. 


Figure 37: Detour After the Link from Router B to Router C Fails 


Jb tk 






017073 


Detour to skip B-C 


If the network topology is not rich enough (there are not enough routers with sufficient links to other 
routers), some of the detours might not succeed. For example, the detour from Router A to Router C in 
Figure 36 on page 472 cannot traverse link A-B and Router B. If such a path is not possible, the detour does 
not occur. 


Note that after the node switches traffic to the detour, it might switch the traffic again to a newly calculated 
detour soon after. This is because the initial detour route might not be the best route. To make rerouting 
as fast as possible, the node switches traffic onto the initial detour without first verifying that the detour 
is valid. Once the switch is made, the node recomputes the detour. If the node determines that the initial 
detour is still valid, traffic continues to flow over this detour. If the node determines that the initial detour 
is no longer valid, it again switches the traffic to a newly computed detour. 


NOTE: If you issue show commands after the node has switched traffic to the initial detour, the 
node might indicate that the traffic is still flowing over the original LSP. This situation is temporary 
and should correct itself quickly. 


The time required for a fast-rerouting detour to take effect depends on two independent time intervals: 


e Amount of time to detect that there is a link or node failure—This interval depends greatly on the link 
layer in use and the nature of the failure. For example, failure detection on an SONET/SDH link typically 
is much faster than on a Gigabit Ethernet link, and both are much faster than detection of a router failure. 


e Amount of time required to splice the traffic onto the detour—This operation is performed by the Packet 
Forwarding Engine, which requires little time to splice traffic onto the detour. The time needed can vary 
depending on the number of LSPs being switched to detours. 


Fast reroute is a short-term patch to reduce packet loss. Because detour computation might not reserve 
adequate bandwidth, the detours might introduce congestion on the alternate links. The ingress router is 
the only router that is fully aware of LSP policy constraints and, therefore, is the only router able to come 
up with adequate long-term alternate paths. 


Detours are created by use of RSVP and, like all RSVP sessions, they require extra state and overhead in 
the network. For this reason, each node establishes at most one detour for each LSP that has fast reroute 
enabled. Creating more than one detour for each LSP increases the overhead, but serves no practical 
purpose. 


To reduce network overhead further, each detour attempts to merge back into the LSP as soon as possible 
after the failed node or link. If you can consider an LSP that travels through n router nodes, it is possible 
to create n - 1 detours. For instance, in Figure 38 on page 474, the detour tries to merge back into the LSP 
at Router D instead of at Router E or Router F. Merging back into the LSP makes the detour scalability 
problem more manageable. If topology limitations prevent the detour from quickly merging back into the 
LSP, detours merge with other detours automatically. 
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Figure 38: Detours Merging into Other Detours 
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Configuring Fast Reroute 


Fast reroute provides a mechanism for automatically rerouting traffic on an LSP if a node or link in an LSP 
fails, thus reducing the loss of packets traveling over the LSP. 


To configure fast reroute on an LSP, include the fast-reroute statement on the ingress router (or switch): 


fast-reroute { 
(bandwidth bps | bandwidth-percent percentage); 
(exclude [ group-names ] | no-exclude ); 
hop-limit number; 
(include-all [ group-names ] | no-include-all); 
(include-any [ group-names ] | no-include-any); 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


You do not need to configure fast reroute on the LSP’s transit and egress routers (or switches). Once fast 
reroute is enabled, the ingress router (or switch) signals all the downstream routers (or switches) that fast 
reroute is enabled on the LSP, and each downstream router does its best to set up detours for the LSP. If 
a downstream router does not support fast reroute, it ignores the request to set up detours and continues 
to support the LSP. A router that does not support fast reroute will cause some of the detours to fail, but 
otherwise has no impact on the LSP. 


NOTE: To enable PFE fast reroute, configure a routing policy statement with the load-balance 
per-packet statement at the [edit policy-options policy-statement policy-name then] hierarchy 
level on each of the routers where traffic might be rerouted. See also “Configuring Load Balancing 
Across RSVP LSPs” on page 806. 


By default, no bandwidth is reserved for the rerouted path. To allocate bandwidth for the rerouted path, 
include either the bandwidth statement or the bandwidth-percent statement. You can only include one 
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of these statements at a time. If you do not include either the bandwidth statement or the 
bandwidth-percent statement, the default setting is to not reserve bandwidth for the detour path. 


When you include the bandwidth statement, you can specify the specific amount of bandwidth (in bits 
per second [bps]) you want to reserve for the detour path. The bandwidth does not need to be identical 
to that allocated for the LSP. 


When you specify a bandwidth percent using the bandwidth-percent statement, the detour path bandwidth 
is computed by multiplying the bandwidth percentage by the bandwidth configured for the main 
traffic-engineered LSP. For information about how to configure the bandwidth for a traffic-engineered 
LSP, see “Configuring Traffic-Engineered LSPs” on page 1128. 


Hop-limit constraints define how many more routers a detour is allowed to traverse compared with the 
LSP itself. By default, the hop limit is set to 6. For example, if an LSP traverses 4 routers, any detour for 
the LSP can be up to 10 (that is, 4 + 6) router hops, including the ingress and egress routers. 


By default, a detour inherits the same administrative (coloring) group constraints as its parent LSP when 
CSPF is determining the alternate path. Administrative groups, also known as link coloring or resource 
class, are manually assigned attributes that describe the “color” of links, such that links with the same color 
conceptually belong to the same class. If you specify the include-any statement when configuring the 
parent LSP, all links traversed by the alternate session must have at least one color found in the list of 
groups. If you specify the include-all statement when configuring the parent LSP, all links traversed by the 
alternate session must have all of the colors found in the list of groups. If you specify the exclude statement 
when configuring the parent LSP, none of the links must have a color found in the list of groups. For more 
information about administrative group constraints, see “Configuring Administrative Groups for LSPs” on 
page 503. 


Detour Merging Process 


This section describes the process used by a router to determine which LSP to select when the router 
receives path messages from different interfaces with identical Session and Sender Template objects. 
When this occurs, the router needs to merge the path states. 


The router employs the following process to determine when and how to merge path states: 


e When all the path messages do not include a fast reroute or a detour object, or when the router is the 
egress of the LSP, no merging is required. The messages are processed according to RSVP traffic 
engineering. 


e Otherwise, the router must record the path state in addition to the incoming interface. If the path 
messages do not share the same outgoing interface and next-hop router, the router considers them to 
be independent LSPs and does not merge them. 


For all the path messages that share the same outgoing interface and next-hop router, the router uses 


the following process to select the final LSP: 
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If only one LSP originates from this node, select it as the final LSP. 


e 


If only one LSP contains a fast reroute object, select it as the final LSP. 


If there are several LSPs and some of them have a detour object, eliminate those containing a detour 


object from the final LSP selection process. 


If several final LSP candidates remain (that is, there are still both detour and protected LSPs), select 
the LSPs with fast reroute objects. 


e 


If none of the LSPs have fast reroute objects, select the ones without detour objects. If all the LSPs 
have detour objects, select them all. 


Of the remaining LSP candidates, eliminate from consideration those that traverse nodes that other 
LSPs avoid. 


If several candidate LSPs still remain, select the one with the shortest explicit route object (ERO) path 


e 


length. If more than one LSP has the same path length, select one randomly. 


Once the final LSP has been identified, the router must transmit only the path messages that correspond 
to this LSP. All other LSPs are considered merged at this node. 


Detour Computations 


Computing and setting up detours is done independently at each node. On a node, if an LSP has fast reroute 
enabled and if a downstream link or node can be identified, the router performs a Constrained Shortest 
Path First (CSPF) computation using the information in the local traffic engineering database. For this 
reason, detours rely on your IGP supporting traffic engineering extensions. Without the traffic engineering 
database, detours cannot be established. 


CSPF initially attempts to find a path that skips the next downstream node. Attempting to find this path 
provides protection against downstream failures in either nodes or links. If a node-skipping path is not 
available, CSPF attempts to find a path on an alternate link to the next downstream node. Attempting to 
find an alternate link provides protection against downstream failures in links only. Detour computations 
might not succeed the first time. If a computation fails, the router recomputes detours approximately once 
every refresh interval until the computation succeeds. The RSVP metric for each detour is set to a value 
in the range from 10,000 through 19,999. 


Fast Reroute Path Optimization 


A fast reroute protection path is nondeterministic. The actual protection path of a particular node depends 
on the history of the LSP and the network topology when the fast reroute path was computed. The lack 

of deterministic behavior can lead to operational difficulties and poorly optimized paths after multiple link 
flaps in a network. Even in a small network, after a few link flaps fast reroute paths can traverse an arbitrarily 
large number of nodes and can remain in that state indefinitely. This is inefficient and makes the network 
less predictable. 
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Fast reroute optimization addresses this deficiency. It provides a global path optimization timer, allowing 
you to optimize all LSPs that have fast reroute enabled and a detour path up and running. The timer value 
can be varied depending on the expected RE processing load. 


The fast reroute optimization algorithm is based on the IGP metric only. As long as the new path’s IGP 
metric is lower than the old path’s, the CSPF result is accepted, even if the new path might be more 
congested (higher bandwidth utilization) or traverses more hops. 


In conformance with RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels, when a new path is 
computed and accepted for fast reroute optimization, the existing detour is destroyed first and then the 
new detour is established. To prevent traffic loss, detours actively protecting traffic are not optimized. 


Configuring the Optimization Interval for Fast Reroute Paths 


You can enable path optimization for fast reroute by configuring the fast reroute optimize timer. The 
optimize timer triggers a periodic optimization process that recomputes the fast reroute detour LSPs to 
use network resources more efficiently. 


To enable fast reroute path optimization, specify the number of seconds using the optimize-timer option 
for the fast-reroute statement: 


fast-reroute seconds; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 


Adding LSP-Related Routes to the inet.3 or inet6.3 Routing Table 


By default, a host route toward the egress router is installed in the inet.3 or inet6.3 routing table. (The 
host route address is the one you configure in the to statement.) Installing the host route allows BGP to 
perform next-hop resolution. It also prevents the host route from interfering with prefixes learned from 
dynamic routing protocols and stored in the inet.O or inet6.0 routing table. 


Unlike the routes in the inet.O or inet6.0 table, routes in the inet.3 or inet6.3 table are not copied to the 
Packet Forwarding Engine, and hence they cause no changes in the system forwarding table directly. You 
cannot use the ping or traceroute command through these routes. The only use for inet.3 or inet6.3 is to 
permit BGP to perform next-hop resolution. To examine the inet.3 or inet6.3 table, use the show route 
table inet.3 or show route table inet6.3 command. 


To inject additional routes into the inet.3 or inet6.3 routing table, include the install statement: 


install { 
destination-prefix <active>; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 
e [edit protocols mpls static-label-switched-path Isp-name] 
e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name] 


The specified routes are installed as aliases into the routing table when the LSP is established. Installing 
additional routes allows BGP to resolve next hops within the specified prefix and to direct additional traffic 
for these next hops to a particular LSP. 


Including the active option with the install statement installs the specified prefix into the inet.O or inet6.0 
routing table, which is the primary forwarding table. The result is a route that is installed in the forwarding 
table any time the LSP is established, which means you can ping or trace the route. Use this option with 
care, because this type of prefix is very similar to a static route. 


You use alias routes for routers that have multiple addresses being used as BGP next hops, or for routers 
that are not MPLS capable. In either of these cases, the LSP can be configured to another MPLS capable 
system within the local domain, which then acts as a “border” router. The LSP then terminates on the 
border router and, from that router, Layer 3 forwarding takes the packet to the true next-hop router. 


In the case of an interconnect, the domain’s border router can act as the proxy router and can advertise 
the prefix for the interconnect if the border router is not setting the BGP next hop to itself. 


In the case of a point of presence (POP) that has routers that do not support MPLS, one router (for example, 
a core router) that supports MPLS can act as a proxy for the entire POP and can inject a set of prefixes 
that cover the POP. Thus, all routers within the POP can advertise themselves as interior BGP (IBGP) next 
hops, and traffic can follow the LSP to reach the core router. This means that normal IGP routing would 
prevail within the POP. 


You cannot use the ping or traceroute commands on routes in the inet.3 or inet6.3 routing table. 


For BGP next-hop resolution, it makes no difference whether a route is in inet.0/inet6.0 or inet.3/inet6.3; 
the route with the best match (longest mask) is chosen. Among multiple best-match routes, the one with 
the highest preference value is chosen. 
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NOTE: The install destination-prefix active statement is not supported on static LSPs. When the 
install destination-prefix active statement is configured for a static LSP, the MPLS routes do not 
get installed into the inet.O routing table. 
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Constrained-Path LSP Computation 


The Constrained Shortest Path First (CSPF) algorithm is an advanced form of the shortest-path-first (SPF) 
algorithm used in OSPF and IS-IS route computations. CSPF is used in computing paths for LSPs that are 
subject to multiple constraints. When computing paths for LSPs, CSPF considers not only the topology of 
the network, but also the attributes of the LSP and the links, and it attempts to minimize congestion by 
intelligently balancing the network load. 


The constraints that CSPF considers include: 
e LSP attributes 


e Administrative groups (that is, link color requirements) 


e Bandwidth requirements 
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e Explicit route (strict or loose) 
e Hop limitations 


e Priority (setup and hold) 


Link attributes 


e Administrative groups (that is, link colors assigned to the link) 


e Reservable bandwidth of the links (static bandwidth minus the currently reserved bandwidth) 


The data that CSPF considers comes from the following sources: 


e Traffic engineering database—Provides CSPF with up-to-date topology information, the current reservable 
bandwidth of links, and the link colors. For the CSPF algorithm to perform its computations, a link-state 
IGP (such as OSPF or IS-IS) with special extensions is needed. For CSPF to be effective, the link-state 
IGP onall routers must support the special extensions. While building the topology database, the extended 
IGP must take into consideration the current LSPs and must flood the route information everywhere. 
Because changes in the reserved link bandwidth and link color cause database updates, an extended 
IGP tends to flood more frequently than a normal IGP. See Figure 39 on page 480 for a diagram of the 
relationships between these components. 


Currently active LSPs—Includes all the LSPs that should originate from the router and their current 


operational status (up, down, or timeout). 


Figure 39: CSPF Computation Process 
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This section discusses the following topics: 
e How CSPF Selects a Path on page 481 


e CSPF Path Selection Tie-Breaking on page 481 
e Computing CSPF Paths Offline on page 482 
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How CSPF Selects a Path 


To select a path, CSPF follows certain rules. The rules are as follows: 


1. Computes LSPs one at a time, beginning with the highest priority LSP (the one with the lowest setup 
priority value). Among LSPs of equal priority, CSPF services the LSPs in alphabetical order of the LSP 
names. 


2. Prunes the traffic engineering database of all the links that are not full duplex and do not have sufficient 
reservable bandwidth. 


3. If the LSP configuration includes the include statement, prunes all links that do not share any included 
colors. 


4. |f the LSP configuration includes the exclude statement, prunes all links that contain excluded colors. 
If the link does not have a color, it is accepted. 


5. If several paths have equal cost, chooses the one whose last-hop address is the same as the LSP’s 
destination. 


6. If several equal cost paths remain, selects the one with the fewest number of hops. 


7. If several equal-cost paths remain, applies the CSPF load-balancing rule configured on the LSP (least 
fill, most fill, or random). 


CSPF finds the shortest path toward the LSP’s egress router, taking into account explicit-path constraints. 
For example, if the path must pass through Router A, two separate SPFs are computed, one from the 
ingress router to Router A, the other from Router A to the egress router. All CSPF rules are applied to both 
computations. 


CSPF Path Selection Tie-Breaking 


If more than one path is still available after the CSPF rules (“How CSPF Selects a Path” on page 481) have 
been applied, a tie-breaking rule is applied to choose the path for the LSP. The rule used depends on the 
configuration. There are three tie-breaking rules: 


e Random—One of the remaining paths is picked at random. This rule tends to place an equal number of 
LSPs on each link, regardless of the available bandwidth ratio. This is the default behavior. 


e Least fill—The path with the largest minimum available bandwidth ratio is preferred. This rule tries to 
equalize the reservation on each link. 


e Most fill—The path with the smallest minimum available bandwidth ratio is preferred. This rule tries to 
fill a link before moving on to alternative links. 


The following definitions describe how a figure for minimum available bandwidth ratio is derived for the 
least fill and most fill rules: 
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e Reservable bandwidth = bandwidth of link x subscription factor of link 
e Available bandwidth = reservable bandwidth - (sum of the bandwidths of the LSPs traversing the link) 
e Available bandwidth ratio = available bandwidth/reservable bandwidth 


e Minimum available bandwidth ratio (for a path) = the smallest available bandwidth ratio of the links in a 
path 


NOTE: For the least fill or most fill behaviors to be used, the paths must have their bandwidth 
(specified using the bandwidth statement at the [edit protocols mpls label-switched-path 
Isp-name] hierarchy level) or minimum bandwidth (specified using the minimum-bandwidth 
statement at the [edit protocols mpls label-switched-path Isp-name auto-bandwidth] hierarchy 
level) configured to a value greater than O. If the bandwidth or minimum bandwidth for the paths 
is either not configured or configured as O, the minimum available bandwidth cannot be calculated 
and the random path selection behavior is used instead. 


Computing CSPF Paths Offline 


The Junos OS provides online, real-time CSPF computation only; each router performs CSPF calculations 
independent of the other routers in the network. These calculations are based on currently available 
topology information—information that is usually recent, but not completely accurate. LSP placements are 
locally optimized, based on current network status. 


To optimize links globally across the network, you can use an offline tool to perform the CSPF calculations 
and determine the paths for the LSPs. You can create such a tool yourself, or you can modify an existing 
network design tool to perform these calculations. You should run the tool periodically (daily or weekly) 
and download the results into the router. An offline tool should take the following into account when 
performing the optimized calculations: 


e All the LSP’s requirements 
e All link attributes 


e Complete network topology 


Configuring CSPF Tie Breaking 


When selecting a path for an LSP, CSPF uses a tie-breaking process if there are several equal-cost paths. 
For information about how CSPF selects a path, see “How CSPF Selects a Path” on page 481. 


You can configure one of the following statements (you can only configure one of these statements at a 
time) to alter the behavior of CSPF tie-breaking: 
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e By default, a random tie-breaking rule for CSPF is used to select a path from the set of equal-cost paths. 
However, you can also explicitly configure this behvior using the random statement: 


random; 


e To prefer the path with the least-utilized links, include the least-fill statement: 


least-fill; 


e To prefer the path with the most-utilized links, include the most-fill statement: 


most-fill; 


You can include each of these statements at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


Disabling Constrained-Path LSP Computation 


If the IGP is a link-state protocol (such as IS-IS or OSPF) and supports extensions that allow the current 
bandwidth reservation on each router’s link to be reported, constrained-path LSPs are computed by default. 


The Junos implementations of IS-IS and OSPF include the extensions that support constrained-path LSP 
computation. 


e 1S-IS—These extensions are enabled by default. To disable this support, include the disable statement 
at the [edit protocols isis traffic-engineering] hierarchy level, as discussed in the Junos OS Routing 
Protocols Library. 


e OSPF—These extensions are disabled by default. To enable this support, include the traffic-engineering 
statement in the configurations of all routers running OSPF, as described in the Junos OS Routing Protocols 
Library. 


If IS-IS is enabled on a router or you enable OSPF traffic engineering extensions, MPLS performs the 
constrained-path LSP computation by default. For information about how constrained-path LSP computation 
works, see “Constrained-Path LSP Computation” on page 479. 


Constrained-path LSPs have a greater chance of being established quickly and successfully for the following 
reasons: 


e The LSP computation takes into account the current bandwidth reservation. 


e Constrained-path LSPs reroute themselves away from node failures and congestion. 
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When constrained-path LSP computation is enabled, you can configure the LSP so that it is periodically 
reoptimized, as described in “Optimizing Signaled LSPs” on page 511. 


When an LSP is being established or when an existing LSP fails, the constrained-path LSP computation is 
repeated periodically at the interval specified by the retry timer until the LSP is set up successfully. Once 
the LSP is set up, no recomputation is done. For more information about the retry timer, see “Configuring 
the Connection Between Ingress and Egress Routers” on page 493. 


By default, constrained-path LSP computation is enabled. You might want to disable constrained-path LSP 
computation when all nodes do not support the necessary traffic engineering extensions. To disable 
constrained-path LSP computation, include the no-cspf statement: 


no-cspf; 
For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


If you disable constrained-path LSP computation on LSPs by configuring the no-cspf statement and then 
attempt to advertise other LSPs with lower metrics than the IGPs from this router in either IS-IS or OSPF, 
new LSPs cannot be established. 
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Routers in an LSP 


Each router in an LSP performs one of the following functions: 


Ingress router—The router at the beginning of an LSP. This router encapsulates IP packets with an MPLS 
Layer 2 frame and forwards it to the next router in the path. Each LSP can have only one ingress router. 


Egress router—The router at the end of an LSP. This router removes the MPLS encapsulation, thus 
transforming it from an MPLS packet to an IP packet, and forwards the packet to its final destination 
using information in the IP forwarding table. Each LSP can have only one egress router. The ingress and 


egress routers in an LSP cannot be the same router. 


Transit router—Any intermediate router in the LSP between the ingress and egress routers. A transit 
router forwards received MPLS packets to the next router in the MPLS path. An LSP can contain zero 
or more transit routers, up to a maximum of 253 transit routers in a single LSP. 


A single router can be part of multiple LSPs. It can be the ingress or egress router for one or more LSPs, 
and it also can be a transit router in one or more LSPs. The functions that each router supports depend 
on your network design. 


Configuring the Ingress and Egress Router Addresses for LSPs 
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The following sections describe how to specify the addresses of an LSP’s ingress and egress routers: 


Configuring the Ingress Router Address for LSPs 


The local router always is considered to be the ingress router, which is the beginning of the LSP. The 
software automatically determines the proper outgoing interface and IP address to use to reach the next 


router in an LSP. 


By default, the router ID is chosen as the address of the ingress router. To override the automatic selection 
of the source address, specify a source address in the from statement: 


from address; 


You can include this statement at the following hierarchy levels: 
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e [edit protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 
The outgoing interface used by the LSP is not affected by the source address that you configure. 


Configuring the Egress Router Address for LSPs 


When configuring an LSP, you must specify the address of the egress router by including the to statement: 


to address; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 
e [edit protocols mpls static-label-switched-path Isp-name] 
e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name] 


When you are setting up a signaled LSP, the to statement is the only required statement. All other statements 
are optional. 


After the LSP is established, the address of the egress router is installed as a host route in the routing 
table. This route can then be used by BGP to forward traffic. 


To have the software send BGP traffic over an LSP, the address of the egress router is the same as the 
address of the BGP next hop. You can specify the egress router's address as any one of the router's interface 
addresses or as the BGP router ID. If you specify a different address, even if the address is on the same 
router, BGP traffic is not sent over the LSP. 


To determine the address of the BGP next hop, use the show route detail command. To determine the 
destination address of an LSP, use the show mpls Isp command. To determine whether a route has gone 
through an LSP, use the show route or show route forwarding-table command. In the output of these last 
two commands, the label-switched-path or push keyword included with the route indicates it has passed 
through an LSP. Also, use the traceroute command to trace the actual path to which the route leads. This 
is another indication whether a route has passed through an LSP. 


You also can manipulate the address of the BGP next hop by defining a BGP import policy filter that sets 
the route’s next-hop address. 


Preventing the Addition of Egress Router Addresses to Routing Tables 


You must configure an address using the to statement for all LSPs. This address is always installed as a 
/32 prefix in the inet.3 or inet.0 routing tables. You can prevent the egress router address configured using 
the to statement from being added to the inet.3 and inet.O routing tables by including the 
no-install-to-address statement. 
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Some reasons not to install the to statement address in the inet.3 and inet.O routing tables include the 
following: 


e Allow Constrained Shortest Path First (CSPF) RSVP LSPs to be mapped to traffic intended for secondary 
loopback addresses. If you configure an RSVP tunnel, including the no-install-to-address statement, and 
then configure an install pfx/ <active> policy later, you can do the following: 


e Verify that the LSP was set up correctly without impacting traffic. 
e Map traffic to the LSP in incremental steps. 


e Map traffic to the destination loopback address (the BGP next hop) by removing the 
no-install-to-address statement once troubleshooting is complete. 


e Prevent CCC connections from losing IP traffic. When an LSP determines that it does not belong toa 
connection, it installs the address specified with the to statement in the inet.3 routing table. IP traffic is 
then forwarded to the CCC remote endpoint, which can cause some types of PICs to fail. 


To prevent the egress router address configured using the to statement from being added to the inet.3 


and inet.O routing tables, include the no-install-to-address statement: 


no-install-to-address; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 
e [edit protocols mpls static-label-switched-path Isp-name] 
e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name] 


Configuring the Ingress Router for MPLS-Signaled LSPs 
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MPLS-signaled label-switched paths (LSPs) run from a specific ingress router to a specific egress router. 
For basic MPLS-signaled LSP function, you must configure the ingress router, but do not have to configure 
any other routers. 


To configure signaled LSPs, perform the following tasks on the ingress router: 


Creating Named Paths 


To configure signaled LSPs, you must first create one or more named paths on the ingress router. For each 
path, you can specify some or all transit routers in the path, or you can leave it empty. 


Each pathname can contain up to 32 characters and can include letters, digits, periods, and hyphens. The 
name must be unique within the ingress router. Once a named path is created, you can use the named 
path with the primary or secondary statement to configure LSPs at the [edit protocols mpls 
label-switched-path label-path-name] hierarchy level. You can specify the same named path on any number 
of LSPs. 


To determine whether an LSP is associated with the primary or secondary path in an RSVP session, issue 
the show rsvp session detail command. 


To create an empty path, create a named path by including the following form of the path statement. This 
form of the path statement is empty, which means that any path between the ingress and egress routers 
is accepted. In actuality, the path used tends to be the same path as is followed by destination-based, 
best-effort traffic. 


path path-name; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


To create a path in which you specify some or all transit routers in the path, include the following form of 
the path statement, specifying one address for each transit router: 


path path-name { 
(address | hostname) <strict | loose>; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


In this form of the path statement, you specify one or more transit router addresses. Specifying the ingress 
or egress routers is optional. You can specify the address or hostname of each transit router, although you 
do not need to list each transit router if its type is loose. Specify the addresses in order, starting with the 
ingress router (optional) or the first transit router, and continuing sequentially along the path up to the 

egress router (optional) or the router immediately before the egress router. You need to specify only one 
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address per router hop. If you specify more than one address for the same router, only the first address 
is used; the additional addresses are ignored and truncated. 


For each router address, you specify the type, which can be one of the following: 


e strict—(Default) The route taken from the previous router to this router is a direct path and cannot 
include any other routers. If address is an interface address, this router also ensures that the incoming 
interface is the one specified. Ensuring that the incoming interface is the one specified is important when 
there are parallel links between the previous router and this router. It also ensures that routing can be 
enforced on a per-link basis. 


For strict addresses, you must ensure that the router immediately preceding the router you are configuring 
has a direct connection to that router. The address can be a loopback interface address, in which case 
the incoming interface is not checked. 


e loose—The route taken from the previous router to this router need not be a direct path, can include 
other routers, and can be received on any interface. The address can be any interface address or the 
address of the loopback interface. 


Examples: Creating Named Paths 


Configure a path, to-hastings, to specify the complete strict path from the ingress to the egress routers 
through 14.1.1.1, 13.1.1.1, 12.1.1.1, and 11.1.1.1, in that order. There cannot be any intermediate routers 
except the ones specified. However, there can be intermediate routers between 11.1.1.1 and the egress 
router because the egress router is not specifically listed in the path statement. To prevent intermediate 
routers before egress, configure the egress router as the last router, with a strict type. 


[edit protocols mpls] 

path to-hastings { 
14.1.1.1 strict; 
13.1.1.1 strict; 
12.1.1.1 strict; 
11.1.1.1 strict; 


Create a path, alt-hastings, to allow any number of intermediate routers between routers 14.1.1.1 and 
11.1.1.1. In addition, intermediate routers are permitted between 11.1.1.1 and the egress router. 


[edit protocols mpls] 

path alt-hastings { 
14.1.1.1 strict; 
11.1.1.1 loose; 
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Configuring Alternate Backup Paths Using Fate Sharing 
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Example: Configuring Fate Sharing | 492 


You can create a database of information that Constrained Shortest Path First (CSPF) uses to compute 
one or more backup paths in case the primary path becomes unstable. The database describes the 
relationships between elements of the network, such as routers and links. Because these network elements 
share the same fate, this relationship is called fate sharing. 


You can configure backup paths that minimize the number of shared links and fiber paths with the primary 
paths as much as possible to ensure that, if a fiber is cut, the minimum amount of data is lost and a path 
still exists to the destination. 


For a backup path to work optimally, it must not share links or physical fiber paths with the primary path. 
This ensures that a single point of failure will not affect the primary and backup paths at the same time. 


The following sections describe how to configure fate sharing and how it affects CSPF, and provides a 
fate sharing configuration example: 
Configuring Fate Sharing 


To configure fate sharing, include the fate-sharing statement: 


fate-sharing { 
group group-name { 
cost value; 
from address <to address>; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Each fate-sharing group must have a name, which can be up to 32 characters long and can contain letters, 
digits, periods (.) and hyphens (-). You can define up to 512 groups. 


Fate-sharing groups contain three types of objects: 
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e Point-to-point links—Identified by the IP addresses at each end of the link. Unnumbered point-to-point 
links are typically identified by borrowing IP addresses from other interfaces. Order is not important; 
from 1.2.3.4 to 1.2.3.5 and from 1.2.3.5 to 1.2.3.4 have the same meaning. 


e Non-point-to-point links—Include links on a LAN interface (such as Gigabit Ethernet interfaces) or 
nonbroadcast multiaccess (NBMA) interfaces (such as Asynchronous Transfer Mode [ATM] or Frame 
Relay). You identify these links by their individual interface address. For example, if the LAN interface 
192.168.200.0/24 has four routers attached to it, each router link is individually identified: 


from 192.168.200.1; # LAN interface of router 1 
from 192.168.200.2; # LAN interface of router 2 
from 192.168.200.3; # LAN interface of router 3 
from 192.168.200.4; # LAN interface of router 4 


You can list the addresses in any order. 


e Arouter node—Identified by its configured router ID. 


All objects in a group share certain similarities. For example, you can define a group for all fibers that share 
the same fiber conduit, all optical channels that share the same fiber, all links that connect to the same 
LAN switch, all equipment that shares the same power source, and so on. All objects are treated as /32 
host addresses. 


For a group to be meaningful, it should contain at least two objects. You can configure groups with zero 
or one object; these groups are ignored during processing. 


An object can be in any number of groups, and a group can contain any number of objects. Each group 
has a configurable cost attributed to it, which represents the level of impact this group has on CSPF 
computations. The higher the cost, the less likely a backup path will share with the primary path any objects 
in the group. The cost is directly comparable to traffic engineering metrics. By default, the cost is 1. Changing 
the fate-sharing database does not affect established LSPs until the next reoptimization of CSPF. The 
fate-sharing database does influence fast-reroute computations. 


Implications for CSPF 


When CSPF computes the primary paths of an LSP (or secondary paths when the primary path is not 
active), it ignores the fate-sharing information. You always want to find the best possible path (least IGP 
cost) for the primary path. 


When CSPF computes a secondary path while the primary path (of the same LSP) is active, the following 
occurs: 


492 


1. CSPF identifies all fate-sharing groups that are associated with the primary path. CSPF does this by 
identifying all links and nodes that the primary path traverses and compiling group lists that contain at 
least one of the links or nodes. CSPF ignores the ingress and egress nodes in the search. 


2. CSPF checks each link in the traffic engineering database against the compiled group list. If the link is 
a member of a group, the cost of the link is increased by the cost of the group. If a link is a member of 
multiple groups, all group costs are added together. 


3. CSPF performs the check for every node in the traffic engineering database, except the ingress and 
egress node. Again, a node can belong to multiple groups, so costs are additive. 


4. The router performs regular CSPF computation with the adjusted topology. 


Implications for CSPF When Fate Sharing with Bypass LSPs 


When fate sharing is enabled with link protection or link-node protection, CSPF operates as follows when 
calculating the bypass LSP path: 


e CSPF identifies the fate-sharing groups that are associated with the primary LSP path. CSPF does this 
by identifying the immediate downstream link and immediate downstream nodes that the bypass is 
trying to protect. CSPF compiles group lists that contain the immediate downstream link and immediate 
downstream nodes. 


e CSPF checks each link (from ingress to the immediate downstream node) in the traffic engineering 
database against the compiled group list. If the link is a member of a group, the cost of the link is increased 
by the cost of the group. 


e CSPF identifies the downstream link that is not in the fate-shared path. 


This calculation prevents bypasses from using the same physical link as the primary LSP path when viable 
alternatives are available. 


Example: Configuring Fate Sharing 


Configure fate-sharing groups east and west. Because west has no objects, it is ignored during processing. 


[edit routing-options] 
fate-sharing { 
group east { 
cost 20; # Optional, default value is 1 
from 1.2.3.4 to 1.2.3.5; # A point-to-point link 
from 192.168.200.1; # LAN interface 
from 192.168.200.2; # LAN interface 
from 192.168.200.3; # LAN interface 
from 192.168.200.4; # LAN interface 
from 10.168.1.220; # Router ID of a router node 
from 10.168.1.221; # Router ID of a router node 
} 


group west { 
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Configuring the Intermediate and Egress Routers for MPLS-Signaled LSPs 


To configure signaled LSPs on all MPLS routers that should participate in MPLS, you need to enable MPLS 
and RSVP on these routers. 


Configuring the Connection Between Ingress and Egress Routers 


The ingress router might make many attempts to connect and reconnect to the egress router using the 
primary path. You can control how often the ingress router tries to establish a connection using the primary 
path and how long it waits between retry attempts. 


The retry timer configures how long the ingress router waits before trying to connect again to the egress 
router using the primary path. The default retry time is 30 seconds. The time can be from 1 through 
600 seconds. To modify this value, include the retry-timer statement: 


retry-timer seconds; 


You can configure this statement at the following hierarchy levels: 
e [edit protocols mpls label-switched-path Isp-name] 
e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


By default, no limit is set to the number of times an ingress router attempts to establish or reestablish a 
connection to the egress router using the primary path. To limit the number of attempts, include the 
retry-limit statement: 


retry-limit number; 


You can configure this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 
e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


The limit can be a value up to 10,000. When the retry limit is exceeded, no more attempts are made to 
establish a path connection. At this point, intervention is required to restart the primary path. 


If you set a retry limit, it is reset to 1 each time a successful primary path is created. 


Pinging LSPs 
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The following sections describe how to use the ping mpls command to confirm LSP functioning. 


Pinging MPLS LSPs 


You can ping a specific LSP. Echo requests are sent over the LSP as MPLS packets. The payload is a User 
Datagram Protocol (UDP) packet forwarded to an address in the 127/8 range (127.0.0.1 by default, this 

address is configurable) and port 3503. The label and interface information for building and sending this 

information as an MPLS packet is the same as for standard LSP traffic. 


When the echo request arrives at the egress node, the receiver checks the contents of the packet and 
sends a reply containing the correct return value, by using UDP. The router sending the echo request waits 
to receive an echo reply after a timeout of 2 seconds (you cannot configure this value). 


You must configure MPLS at the [edit protocols mpls] hierarchy level on the remote router to be able to 
ping an LSP terminating there. You must configure MPLS even if you intend to ping only LDP forwarding 
equivalence classes (FECs). 


To ping an MPLS LSP use the ping mpls <count count> <Idp <fec>> <rsvp <exp forwarding-class> 
<Isp-name>> command. To ping a secondary MPLS LSP, use the ping mpls <count count> <rsvp <Isp-name>> 
standby path-name command. For a detailed description of this command, see the CLI Explorer. 


NOTE: The ping mpls command is not supported within routing instances. 
NOTE: Self-ping is supported for the master instance and not supported for VLAN-based LSPs 


or LSPs used in CCC. The message is displayed for each LSP and reduces the readability of the 
configuration. 
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Pinging Point-to-Multipoint LSPs 

To ping a point-to-multipoint LSP, use the ping mpls rsvp Isp-name multipoint or ping mpls rsvp egress 
address commands. The ping mpls rsvp Isp-name multipoint command returns a list of all of the egress 
router identifiers and the current status of the point-to-multipoint LSP egress routers. The ping mpls rsvp 
Isp-name multipoint egress address command returns the current status of the specified egress router. 


Pinging the Endpoint Address of MPLS LSPs 


To determine whether an LSP between two provider edge (PE) routers is up and running, you can ping the 
endpoint address of the LSP. To ping an MPLS LSP endpoint, use the ping mpls Isp-end-point address 
command. This command tells you what type of LSP (RSVP or LDP) terminates at the address specified 
and whether that LSP is up or down. 


For a detailed description of this command, see the CLI Explorer. 
Pinging CCC LSPs 


You can ping a specific CCC LSP. The CCC LSP ping command is identical to the one used for MPLS LSPs. 
The command you use is ping mpls <count count> <rsvp </sp-name>>. You can also ping a secondary 
standby CCC LSP by using the ping mpls <count count> <rsvp <Isp-name>> standby path-name command. 


For a detailed description of this command, see the CLI Explorer. 
Pinging Layer 3 VPNs 


You can use a similar command, ping mpls I3vpn vpn-name prefix prefix <count count>, to ping a Layer 3 
VPN. For more information about this command, see the Junos OS VPNs Library for Routing Devices and 
the CLI Explorer. 


Support for LSP Ping and Traceroute Commands Based on RFC 4379 
The Junos OS supports LSP ping and traceroute commands based on RFC 4379, Detecting Multi-Protocol 
Label Switched (MPLS) Data Plane Failures. 


LSP ping and traceroute commands based on RFC 4379 attempt to trace the path taken by an LSP by 
relying on MPLS TTL expiration. An LSP can take multiple paths from ingress to egress. This occurs in 
particular with Equal Cost Multipath (ECMP). The LSP traceroute command can trace all possible paths to 
an LSP node. 
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The LSP metric is used to indicate the ease or difficulty of sending traffic over a particular LSP. Lower LSP 
metric values (lower cost) increase the likelihood of an LSP being used. Conversely, high LSP metric values 
(higher cost) decrease the likelihood of an LSP being used. 


The LSP metric can be specified dynamically by the router or explicitly by the user as described in the 
following sections: 
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Configuring Dynamic LSP Metrics 


If no specific metric is configured, an LSP attempts to track the IGP metric toward the same destination 
(the to address of the LSP). IGP includes OSPF, IS-IS, Routing Information Protocol (RIP), and static routes. 
BGP and other RSVP or LDP routes are excluded. 


For example, if the OSPF metric toward a router is 20, all LSPs toward that router automatically inherit 
metric 20. If the OSPF toward a router later changes to a different value, all LSP metrics change accordingly. 
If there are no IGP routes toward the router, the LSP raises its metric to 65,535. 


Note that in this case, the LSP metric is completely determined by IGP; it bears no relationship to the 
actual path the LSP is currently traversing. If LSP reroutes (such as through reoptimization), its metric does 
not change, and thus it remains transparent to users. Dynamic metric is the default behavior; no 
configuration is required. 


Configuring Static LSP Metrics 


You can manually assign a fixed metric value to an LSP. Once configured with the metric statement, the 
LSP metric is fixed and cannot change: 


metric number; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 
e [edit protocols mpls static-label-switched-path Isp-name] 
e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name] 
The LSP metric has several uses: 


e When there are parallel LSPs with the same egress router, the metrics are compared to determine which 
LSP has the lowest metric value (the lowest cost) and therefore the preferred path to the destination. 
If the metrics are the same, the traffic is shared. 


Adjusting the metric values can force traffic to prefer some LSPs over others, regardless of the underlying 
IGP metric. 


e When an IGP shortcut is enabled (see Using Labeled-Switched Paths to Augment SPF to Compute IGP 
Shortcuts), an IGP route might be installed in the routing table with an LSP as the next hop, if the LSP is 
on the shortest path to the destination. In this case, the LSP metric is added to the other IGP metrics to 
determine the total path metric. For example, if an LSP whose ingress router is X and egress router is Y 
is on the shortest path to destination Z, the LSP metric is added to the metric for the IGP route from Y 
to Z to determine the total cost of the path. If several LSPs are potential next hops, the total metrics of 
the paths are compared to determine which path is preferred (that is, has the lowest total metric). Or, 
IGP paths and LSPs leading to the same destination could be compared by means of the metric value to 
determine which path is preferred. 
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By adjusting the LSP metric, you can force traffic to prefer LSPs, prefer the IGP path, or share the load 
among them. 


e If router X and Y are BGP peers and if there is an LSP between them, the LSP metric represents the total 
cost to reach Y from X. If for any reason the LSP reroutes, the underlying path cost might change 
significantly, but X’s cost to reach Y remains the same (the LSP metric), which allows X to report through 
a BGP multiple exit discriminator (MED) a stable metric to downstream neighbors. As long as Y remains 
reachable through the LSP, no changes are visible to downstream BGP neighbors. 


It is possible to configure IS-IS to ignore the configured LSP metric by including the ignore-Isp-metrics 
statement at the [edit protocols isis traffic-engineering shortcuts] hierarchy level. This statement removes 
the mutual dependency between IS-IS and MPLS for path computation. For more information, see the 
Junos OS Routing Protocols Library. 


Configuring a Text Description for LSPs 


You can provide a textual description for an LSP by enclosing any descriptive text that includes spaces 
within quotation marks ("""). The descriptive text you include is displayed in the detail output of the show 
mpls Isp or the show mpls container-Isp command. 


Adding a text description for an LSP has no effect on the operation of the LSP. The LSP text description 
can be no more than 80 characters in length. 


To provide a textual description for an LSP, include the description statement at any of the following 
hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 

e [edit protocols mpls container-label-switched-path Isp-name] 

e [edit protocols mpls static-label-switched-path Isp-name] 

e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 

e [edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name] 


Before you begin: 


e Configure the device interfaces. 

e Configure the device for network communication. 
e Enable MPLS on the device interfaces. 

e Configure an LSP in the MPLS domain. 


To add a text description for an LSP: 


1. Enter any text describing the LSP. 
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[edit protocols mpls Isp Isp-name] 
user@host# set description text 


For example: 


[edit protocols mpls Isp LSP1] 
user@host# set description “Connecting remote device” 


2. Verify and commit the configuration. 


For example: 


[edit protocols mpls Isp] 

user@host# set protocols mpls label-switched-path LSP1 to 1.1.1.1 

user@host# set protocols mpls label-switched-path LSP1 description "Connecting remote device" 
user@host# set protocols mpls interface ge-1/0/8.0 


[edit] 
user@host# commit 
commit complete 


3. View the description of an LSP using the show mpls Isp detail or show mpls container-Isp detail 
command, depending on the type of LSP configured. 


user@host> show mpls Isp detail 


Ingress LSP: 1 sessions 


Wo dle dls al 
From: 0.0.0.0, State: Up, ActiveRoute: 1, LSPname: LSP1 
Description: Connecting remote device 
ActivePath: (none) 
LSPtype: Static Configured, Penultimate hop popping 
LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





Primary State: Up 
Riew@realicaess 7 (0) 
SmartOptimizeTimer: 180 


No computed ERO. 





Total 1 displayed, Up 1, Down 0 
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Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Configuring MPLS Soft Preemption 


Soft preemption attempts to establish a new path for a preempted LSP before tearing down the original 
LSP. The default behavior is to tear down a preempted LSP first, signal a new path, and then reestablish 
the LSP over the new path. In the interval between when the path is taken down and the new LSP is 
established, any traffic attempting to use the LSP is lost. Soft preemption prevents this type of traffic loss. 
The trade-off is that during the time when an LSP is being soft preempted, two LSPs with their corresponding 
bandwidth requirements are used until the original path is torn down. 


MPLS soft preemption is useful for network maintenance. For example, you can move all LSPs away from 
a particular interface, then take the interface down for maintenance without interrupting traffic. MPLS 
soft preemption is described in detail in RFC 5712, MPLS Traffic Engineering Soft Preemption. 


Soft preemption is a property of the LSP and is disabled by default. You configure it at the ingress of an 
LSP by including the soft-preemption statement: 


soft-preemption; 


You can include this statement at the following hierarchy levels: 
e [edit protocols mpls label-switched-path Isp-name] 
e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


You can also configure a timer for soft preemption. The timer designates the length of time the router 
should wait before initiating a hard preemption of the LSP. At the end of the time specified, the LSP is 
torn down and resignaled. The soft-preemption cleanup timer has a default value of 30 seconds; the range 
of permissible values is O through 180 seconds. A value of O means that soft preemption is disabled. The 
soft-preemption cleanup timer is global for all LSPs. 


Configure the timer by including the cleanup-timer statement: 


cleanup-timer seconds; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp preemption soft-preemption] 


e [edit logical-systems logical-system-name protocols rsvp preemption soft-preemption] 


NOTE: Soft preemption cannot be configured on LSPs for which fast reroute has been configured. 
The configuration fails to commit. However, you can enable soft preemption in conjunction with 
node and link protection. 


NOTE: The counter value for SoftPreemptionCnt initializes with a value of O (zero), visible in the 
command show rsvp interface detail output. 


Configuring Priority and Preemption for LSPs 


When there is insufficient bandwidth to establish a more important LSP, you might want to tear down a 
less important existing LSP to free the bandwidth. You do this by preempting the existing LSP. 


Whether an LSP can be preempted is determined by two properties associated with the LSP: 


e Setup priority—Determines whether a new LSP that preempts an existing LSP can be established. For 
preemption to occur, the setup priority of the new LSP must be higher than that of the existing LSP. 
Also, the act of preempting the existing LSP must produce sufficient bandwidth to support the new LSP. 
That is, preemption occurs only if the new LSP can be set up successfully. 


e Reservation priority—Determines the degree to which an LSP holds on to its session reservation after 
the LSP has been set up successfully. When the reservation priority is high, the existing LSP is less likely 
to give up its reservation, and hence it is unlikely that the LSP can be preempted. 


You cannot configure an LSP with a high setup priority and a low reservation priority, because permanent 
preemption loops might result if two LSPs are allowed to preempt each other. You must configure the 
reservation priority to be higher than or equal to the setup priority. 


The setup priority also defines the relative importance of LSPs on the same ingress router. When the 
software starts, when a new LSP is established, or during fault recovery, the setup priority determines the 
order in which LSPs are serviced. Higher-priority LSPs tend to be established first and hence enjoy more 
optimal path selection. 


To configure the LSP’s preemption properties, include the priority statement: 


priority setup-priority reservation-priority; 
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For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Both setup-priority and reservation-priority can be a value from O through 7. The value O corresponds to 
the highest priority, and the value 7 to the lowest. By default, an LSP has a setup priority of 7 (that is, it 
cannot preempt any other LSPs) and a reservation priority of O (that is, other LSPs cannot preempt it). 
These defaults are such that preemption does not happen. When you are configuring these values, the 
setup priority should always be less than or equal to the hold priority. 


Configuring Administrative Groups for LSPs 


Administrative groups, also known as link coloring or resource class, are manually assigned attributes that 
describe the “color” of links, such that links with the same color conceptually belong to the same class. 
You can use administrative groups to implement a variety of policy-based LSP setups. 


Administrative groups are meaningful only when constrained-path LSP computation is enabled. 


You can assign up to 32 names and values (in the range O through 31), which define a series of names and 
their corresponding values. The administrative names and values must be identical across all routers within 
a single domain. 


NOTE: The administrative value is distinct from the priority. You configure the priority for an 
LSP using the priority statement. See “Configuring Priority and Preemption for LSPs” on page 502. 


To configure administrative groups, follow these steps: 


1. Define multiple levels of service quality by including the admin-groups statement: 


admin-groups { 
group-name group-value; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 
e [edit logical-systems logical-system-name protocols mpls] 
The following configuration example illustrates how you might configure a set of administrative names 


and values for a domain: 


[edit protocols mpls] 
admin-groups { 


504 


gold 1; 

silver 2; 
copper 3; 
best-effort 4; 


2. Define the administrative groups to which an interface belongs. You can assign multiple groups to an 
interface. Include the interface statement: 


interface interface-name { 
admin-group [ group-names ]; 


You can include this statement at the following hierarchy levels: 
e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


If you do not include the admin-group statement, an interface does not belong to any group. 


IGPs use the group information to build link-state packets, which are then flooded throughout the 
network, providing information to all nodes in the network. At any router, the IGP topology, as well as 
administrative groups of all the links, is available. 


Changing the interface’s administrative group affects only new LSPs. Existing LSPs on the interface are 
not preempted or recomputed to keep the network stable. If LSPs need to be removed because of a 
group change, issue the clear rsvp session command. 


NOTE: When configuring administrative groups and extended administrative groups together 
for a link, both the types of administrative groups must be configured on the interface. 


3. Configure an administrative group constraint for each LSP or for each primary or secondary LSP path. 
Include the label-switched-path statement: 


label-switched-path Isp-name { 
to address; 


admin-group { 
exclude [ group-names ]; 
include-all [ group-names ]; 
include-any [ group-names ]; 
} 


primary path-name { 


admin-group { 
exclude [ group-names ]; 
include-all [ group-names ]; 
include-any [ group-names ]; 


} 
secondary path-name { 
admin-group { 
exclude [ group-names ]; 
include-all [ group-names ]; 
include-any [ group-names ]; 


You can include the label-switched-path statement at the following hierarchy levels: 
e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


If you omit the include-all, include-any, or exclude statements, the path computation proceeds 
unchanged. The path computation is based on the constrained-path LSP computation. For information 
about how the constrained-path LSP computation is calculated, see “How CSPF Selects a Path” on 
page 481. 


NOTE: Changing the LSP’s administrative group causes an immediate recomputation of the 
route; therefore, the LSP might be rerouted. 


Configuring Extended Administrative Groups for LSPs 


In MPLS traffic engineering, a link can be configured with a set of administrative groups (also known as 
colors or resource classes). Administrative groups are carried in the interior gateway protocol (IGP) (OSPFv2 
and IS-IS) as a 32-bit value assigned to each link. Juniper Networks routers normally interpret this 32-bit 
value as a bit mask with each bit representing a group, limiting each network to a total of 32 distinct 
administrative groups (value range O through 31). 


You configure extended administrative groups, represented by a 32-bit value, expanding the number of 
administrative groups supported in the network beyond just 32. The original range of values available for 
administrative groups is still supported for backwards compatibility. 


The extended administrative groups configuration accepts a set of interfaces with a corresponding set of 
extended administrative group names. It converts the names into a set of 32-bit values and propagates 
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this information into the IGP. The extended administrative group values are global and must be identically 
configured on all the supported routers participating in the network. The domain-wide extended 
administrative groups database, learned from other routers through IGP flooding, is used by Constrained 
Shortest Path First (CSPF) for path computation. 


The following procedure describes how to configure extended administrative groups: 
1. Configure the admin-groups-extended-range statement: 
admin-groups-extended-range { 


maximum maximum-number; 
mininum minimum-number,; 


You can include this statement at the following hierarchy levels: 
e [edit routing-options] 
e [edit logical-systems logical-system-name routing-options] 


The admin-groups-extended-range statement includes the minimum and maximum options. The range 
maximum must be greater than the range minimum. 


2. Configure the admin-groups-extended statement: 


admin-groups-extended group-name { 
group-value group-identifier; 


You can include this statement at the following hierarchy levels: 
e [edit routing-options] 
e [edit logical-systems logical-system-name routing-options] 


The admin-groups-extended statement enables you to configure a group name and group value for 
the administrative group. The group value must be within the range of values configured using the 
admin-groups-extended-range statement. 


3. The extended administrative groups for an MPLS interface consist of the set of extended administrative 
group names assigned for the interface. The interface extended administrative group names must be 
configured for the global extended administrative groups. 


To configure an extended administrative group for an MPLS interface, specify the administrative group 
name within the MPLS interface configuration using the admin-groups-extended statement: 
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admin-groups-extended group-name; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls interface interface-name] 
e [edit logical-systems logical-system-name protocols mpls interface interface-name] 


4. The LSP extended administrative groups define the set of include and exclude constraints for an LSP 
and for a path’s primary and secondary paths. The extended administrative group names must be 
configured for the global extended administrative groups. 


To configure extended administrative groups for an LSP, include the admin-group-extended statement 
at an LSP hierarchy level: 


admin-group-extended { 
apply-groups group-value; 
apply-groups-except group-value; 
exclude group-value; 
include-all group-value; 
include-any group-value; 


The admin-group-extended statement includes the following options: apply-groups, 
apply-groups-except, exclude, include-all, and include-any. Each option enables you to configure one 
or more extended administrative groups. 


For the list of the hierarchy levels at which you can configure this statement, see the statement summary 
for this statement. 


5. To display the currently configured extended administrative groups, issue the show mpls 
admin-groups-extended command. 


NOTE: When configuring administrative groups and extended administrative groups together 
for a link, both the types of administrative groups must be configured on the interface. 


Configuring Preference Values for LSPs 


As an option, you can configure multiple LSPs between the same pair of ingress and egress routers. This 
is useful for balancing the load among the LSPs because all LSPs, by default, have the same preference 
level. To prefer one LSP over another, set different preference levels for individual LSPs. The LSP with the 
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lowest preference value is used. The default preference for RSVP LSPs is 7 and for LDP LSPs is 9. These 
preference values are lower (more preferred) than all learned routes except direct interface routes. 


To change the default preference value, include the preference statement: 


preference preference; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Disabling Path Route Recording by LSPs 


The Junos implementation of RSVP supports the Record Route object, which allows an LSP to actively 
record the routers through which it transits. You can use this information for troubleshooting and to 
prevent routing loops. By default, path route information is recorded. To disable recording, include the 
no-record statement: 


no-record; 


For a list of hierarchy levels at which you can include the record and no-record statements, see the 
statement summary section for the statement. 


Achieving a Make-Before-Break, Hitless Switchover for LSPs 


IN THIS SECTION 


@ = Specifying the Amount of Time the Router Waits to Switch Over to New Paths | 509 
@ = Specifying the Amount of Time to Delay the Tear Down of Old Paths | 510 
@ = Achieving a Hitless, MBB Switchover Without Artificial Delays | 510 


Adaptive label-switched paths (LSPs) might need to establish a new LSP instance and transfer traffic from 
an old LSP instance onto the new LSP instance before tearing down the old one. This type of configuration 
is referred to as a make before break (MBB). 


RSVP-TE is a protocol used to establish LSPs in MPLS networks. The Junos OS implementation of RSVP-TE 
to achieve a hitless (no traffic loss) MBB switchover has relied on configuring the timer values in the 
following configuration statements: 


e optimize-switchover-delay—Amount of time to wait before switching to the new LSP instance. 


e optimize-hold-dead-delay—Amount of time to wait after switchover and before deletion of the old LSP 
instance. 


Both the optimize-switchover-delay and optimize-hold-dead-delay statements apply to all LSPs that use 
the make-before-break behavior for LSP setup and teardown, not just for LSPs for which the optimize-timer 
statement has also been configured. The following MPLS features cause LSPs to be set up and torn down 
using make-before-break behavior: 


e Adaptive LSPs 

e Automatic bandwidth allocation 

e BFD for LSPs 

e Graceful Routing Engine switchover 
e Link and node protection 

e Nonstop active routing 

e Optimized LSPs 

e Point-to-multipoint (P2MP) LSPs 

e Soft preemption 


e Standby secondary paths 


Both the optimize-switchover-delay and optimize-hold-dead-delay statements when configured add an 
artificial delay to the MBB process. The value of the optimize-switchover-delay statement varies with the 
size of the Explicit Route Objects (EROs). An ERO is an extension to RSVP that allows an RSVP PATH 
message to traverse an explicit sequence of routers that is independent of conventional shortest-path IP 
routing. The value of the optimize-switchover-delay statement also depends on the CPU load on each of 
the routers on the path. Customers set the optimize-switchover-delay statement by trial and error. 


The value of the optimize-hold-dead-delay statement depends on how fast the ingress router moves all 
application prefixes to point to the new LSP. This is determined by the Packet Forwarding Engine load, 
which can vary from platform to platform. Customers have to set the optimize-hold-dead-delay statement 
by trial and error. 


However, as of Release 15.1, Junos OS is able to achieve a hitless MBB switchover without configuring 
the artificial delays that such timer values introduce. 


This topic summarizes the three methods of achieving a MBB switchover from an old LSP to a new LSP 
using Junos OS: 


Specifying the Amount of Time the Router Waits to Switch Over to New Paths 


To specify the amount of time the router waits to switch over LSP instances to newly optimized paths, 
use the optimize-switchover-delay statement. You only need to configure this statement on routers acting 
as the ingress for the affected LSPs (you do not need to configure this statement on transit or egress 
routers). The timer in this statement helps to ensure that the new optimized paths have been established 
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before traffic is switched over from the old paths. This timer can only by enabled or disabled for all of the 
LSPs configured on the router. 


To configure the amount of time the router waits to switch over LSP instances to newly optimized paths, 
specify the time in seconds by using the optimize-switchover-delay statement: 


optimize-switchover-delay seconds; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


Specifying the Amount of Time to Delay the Tear Down of Old Paths 


To specify the amount of time to delay the tear down of old paths after the router has switched traffic to 
new optimized paths, use the optimize-hold-dead-delay statement. You only need to configure this 
statement on routers acting as the ingress for the affected LSPs (you do not need to configure this statement 
on transit or egress routers). The timer in this statement helps to ensure that old paths are not torn down 
before all routes have been switched over to the new optimized paths. This timer can be enabled for 
specific LSPs or for all of the LSPs configured on the router. 


To configure the amount of time in seconds to delay the tear down of old paths after the router has 
switched traffic to new optimized paths, use the optimize-hold-dead-delay statement: 


optimize-hold-dead-delay seconds; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Achieving a Hitless, MBB Switchover Without Artificial Delays 


As of Junos OS Release 15.1, there is another way to relinquish the old LSP instances after MBB switchover 
without relying on the arbitrary time intervals set up by the optimize-switchover-delay or 
optimize-hold-dead-delay statement. For example, if you use the optimize-hold-dead-delay statement, 
you configure a time you think it is safe to wait before tearing down the old LSP instance after MBB. 
However, some routes might still be in the process of shifting to the new instance. Tearing down the old 
LSP instance prematurely results in one of the transit nodes dropping the traffic for those routes that have 
not shifted to the new LSP instance. 


To avoid traffic loss, instead of using the optimize-switchover-delay statement, you can use MPLS-OAM 
(Isp ping), which confirms that the LSP data plane is established end-to-end. Instead of using the 
optimize-hold-dead-delay statement, you can use a feedback mechanism from the rpd infrastructure that 
confirms that all prefixes referring to the old LSP have been switched over. The feedback mechanism is 
sourced from the Tag library and relies on the routing protocol process (rpd) infrastructure to determine 
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when all the routes using the old LSP instance have fully shifted to the new LSP instance after MBB 
switchover. 


The feedback mechanism is always in place, and it is optional. Configure the optimize-adaptive-teardown 
statement to have the feedback mechanism used during MBB switchover. This feature is not supported 
for RSVP point-to-multipoint (P2MP) LSP instances. Global configuration of the optimize-adaptive-teardown 
statement only affects the point-to-point LSPs that are configured in the system. 


You only need to configure the optimize-adaptive-teardown statement on routers acting as the ingress 
for the affected LSPs (you do not need to configure this statement on transit or egress routers). This 
feedback mechanism ensures that old paths are not torn down before all routes have been switched over 
to the new optimized paths. The global configuration of this configuration statement affects only the 
point-to-point LSPs that are configured in the system. 


optimize-adaptive-teardown { 
p2p: 


You can include this statement at the [edit protocols mpls] hierarchy level. 


Optimizing Signaled LSPs 


Once an LSP has been established, topology or resources changes might, over time, make the path 
suboptimal. A new path might have become available that is less congested, has a lower metric, and 
traverses fewer hops. You can configure the router to recompute paths periodically to determine whether 
a more optimal path has become available. 


If reoptimization is enabled, an LSP can be rerouted through different paths by constrained-path 
recomputations. However, if reoptimization is disabled, the LSP has a fixed path and cannot take advantage 
of newly available network resources. The LSP is fixed until the next topology change breaks the LSP and 
forces a recomputation. 


Reoptimization is not related to failover. A new path is always computed when topology failures occur 
that disrupt an established path. 


Because of the potential system overhead involved, you need to carefully control the frequency of 
reoptimization. Network stability might suffer when reoptimization is enabled. By default, the optimize-timer 
statement is set to O (that is, it is disabled). 


LSP optimization is meaningful only when constrained-path LSP computation is enabled, which is the 
default behavior. For more information about constrained-path LSP computation, see “Disabling 
Constrained-Path LSP Computation” on page 483. Also, LSP optimization is only applicable to ingress LSPs, 
so it is only necessary to configure the optimize-timer statement on the ingress router. The transit and 
egress routers require no specific configuration to support LSP optimization (other than to have MPLS 
enabled). 


To enable path reoptimization, include the optimize-timer statement: 


optimize-timer seconds; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Once you have configured the optimize-timer statement, the reoptimization timer continues its countdown 
to the configured value even if you delete the optimize-timer statement from the configuration. The next 
optimization uses the new value. You can force the Junos OS to use a new value immediately by deleting 
the old value, committing the configuration, configuring the new value for the optimize-timer statement, 
and then committing the configuration again. 


After reoptimization is run, the result is accepted only if it meets the following criteria: 


1. The new path is not higher in IGP metric. (The metric for the old path is updated during computation, 
so if a recent link metric changed somewhere along the old path, it is accounted for.) 


2. If the new path has the same IGP metric, it is not more hops away. 


3. The new path does not cause preemption. (This is to reduce the ripple effect of preemption causing 
more preemption.) 


4. The new path does not worsen congestion overall. 


The relative congestion of the new path is determined as follows: 


a. The percentage of available bandwidth on each link traversed by the new path is compared to that 
for the old path, starting from the most congested links. 


b. For each current (old) path, the software stores the four smallest values for bandwidth availability 
for the links traversed in ascending order. 


c. The software also stores the four smallest bandwidth availability values for the new path, 
corresponding to the links traversed in ascending order. 


d. If any of the four new available bandwidth values are smaller than any of the corresponding old 
bandwidth availability values, the new path has at least one link that is more congested than the 
link used by the old path. Because using the link would cause more congestion, traffic is not switched 
to this new path. 


e. If none of the four new available bandwidth values is smaller than the corresponding old bandwidth 
availability values, the new path is less congested than the old path. 
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When all the above conditions are met, then: 


5. If the new path has a lower IGP metric, it is accepted. 


6. If the new path has an equal IGP metric and lower hop count, it is accepted. 


7. \f you choose least-fill as a load balancing algorithm, LSPs are load balanced as follows: 


a. The LSP is moved to a new path that is utilized at least 10% less than the current path. This might 


reduce congestion on the current path by only a small amount. For example, if an LSP with 1 MB 
of bandwidth is moved off a path carrying a minimum of 200 MB, congestion on the original path 
is reduced by less than 1%. 


b. For random or most-fill algorithms, this rule does not apply. 


The following example illustrates how the least-fill load balancing algorithm works. 


Figure 40: least-fill Load Balancing Algorithm Example 
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As shown in Figure 40 on page 513, there are two potential paths for an LSP to traverse from router A 
to router H, the odd links from L1 through L13 and the even links from L2 through L14. Currently, the 
router is using the even links as the active path for the LSP. Each link between the same two routers 


(for example, router A and router B) has the same bandwidth: 


Li, L2 = 10GE 
L3, L4 = 1GE 
L5, L6 = 1GE 
L7, L8 = 1GE 
L9, L10 = 1GE 


L11, L12 = 10GE 
L13, L14 = 10GE 


The 1GE links are more likely to be congested. In this example, the odd 1GE links have the following 
available bandwidth: 


L3 = 41% 
L5 = 56% 
L7 = 66% 


L9 = 71% 
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The even 1GE links have the following available bandwidth: 


e L4=37% 
e L6=52% 
e [8 =61% 
e L10 = 70% 


Based on this information, the router would calculate the difference in available bandwidth between 
the odd links and the even links as follows: 


e L4-L3 = 41% - 37% = 4% 
e L6-L5 = 56% - 52% = 4% 
e L8-L7 = 66% - 61% = 5% 
e L10-L9 = 71% - 70% = 1% 


The total additional bandwidth available over the odd links is 14% (4% + 4% + 5% + 1%). Since 14% is 
greater than 10% (the least-fill algorithm minimum threshold), the LSP is moved to the new path over 
the odd links from the original path using the even links. 


8. Otherwise, the new path is rejected. 


You can disable the following reoptimization criteria (a subset of the criteria listed previously): 


e If the new path has the same IGP metric, it is not more hops away. 


e The new path does not cause preemption. (This is to reduce the ripple effect of preemption causing 
more preemption.) 


e The new path does not worsen congestion overall. 


e If the new path has an equal IGP metric and lower hop count, it is accepted. 


To disable them, either issue the clear mpls Isp optimize-aggressive command or include the 
optimize-aggressive statement: 


optimize-aggressive; 


You can include this statement at the following hierarchy levels: 
e [edit protocols mpls] 
e [edit logical-systems logical-system-name protocols mpls] 


Including the optimize-aggressive statement in the configuration causes the reoptimization procedure to 
be triggered more often. Paths are rerouted more frequently. It also limits the reoptimization algorithm to 
the IGP metric only. 


Configuring the Smart Optimize Timer for LSPs 


Because of network and router resource constraints, it is typically inadvisable to configure a short interval 
for the optimize timer. However, under certain circumstances, it might be desirable to reoptimize a path 
sooner than would normally be provided by the optimize timer. 


For example, an LSP is traversing a preferred path that subsequently fails. The LSP is then switched to a 
less desirable path to reach the same destination. Even if the original path is quickly restored, it could take 
an excessively long time for the LSP to use it again, because it has to wait for the optimize timer to 
reoptimize the network paths. For such situations, you might want to configure the smart optimize timer. 


When you enable the smart optimize timer, an LSP is switched back to its original path so long as the 
original path has been restored within 3 minutes of going down. Also, if the original path goes down again 
within 60 minutes, the smart optimize timer is disabled, and path optimization behaves as it normally does 
when the optimize timer alone is enabled. This prevents the router from using a flapping link. 


The smart optimize timer is dependant on other MPLS features to function properly. For the scenario 
described here in which an LSP is switched to an alternate path in the event of a failure on the original 
path, it is assumed that you have configured one or more of the MPLS traffic protection features, including 
fast reroute, link protection, and standby secondary paths. These features help to ensure that traffic can 
reach its destination in the event of a failure. 


At the least, you must configure a standby secondary path for the smart optimize timer feature to work 
properly. Fast reroute and link protection are more temporary solutions to a network outage. A secondary 
path ensures that there is a stable alternate path in the event the primary path fails. If you have not 
configured any sort of traffic protection for an LSP, the smart optimize timer by itself does not ensure that 
traffic can reach its destination. For more information about MPLS traffic protection, see “MPLS and Traffic 
Protection” on page 277. 


When a primary path fails and the smart optimize timer switches traffic to the secondary path, the router 
might continue to use the secondary path even after the primary path has been restored. If the ingress 
router completes a CSPF calculation, it might determine that the secondary path is the better path. 


This might be undesirable if the primary path should be the active path and the secondary path should be 
used as a backup only. Also, if the secondary path is being used as the active path (even though the primary 
path has been reestablished) and the secondary path fails, the smart optimize timer feature will not 
automatically switch traffic back to the primary path. However, you can enable protection for the secondary 
path by configuring node and link protection or an additional standby secondary path, in which case, the 
smart optimize timer can be effective. 


Specify the time in seconds for the smart optimize timer using the smart-optimize-timer statement: 


smart-optimize-timer seconds; 
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You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


Limiting the Number of Hops in LSPs 


By default, each LSP can traverse a maximum of 255 hops, including the ingress and egress routers. To 
modify this value, include the hop-limit statement: 


hop-limit number; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


The number of hops can be from 2 through 255. (A path with two hops consists of the ingress and egress 
routers only.) 


Configuring the Bandwidth Value for LSPs 


Each LSP has a bandwidth value. This value is included in the sender’s Tspec field in RSVP path setup 
messages. You can specify a bandwidth value in bits per second. If you configure more bandwidth for an 
LSP, it should be able to carry a greater volume of traffic. The default bandwidth is O bits per second. 


A nonzero bandwidth requires that transit and egress routers reserve capacity along the outbound links 
for the path. The RSVP reservation scheme is used to reserve this capacity. Any failure in bandwidth 
reservation (such as failures at RSVP policy control or admission control) might cause the LSP setup to fail. 
If there is insufficient bandwidth on the interfaces for the transit or egress routers, the LSP is not established. 


To specify a bandwidth value for a signaled LSP, include the bandwidth statement: 


bandwidth bps; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Automatic Bandwidth Allocation for LSPs 


Automatic bandwidth allocation allows an MPLS tunnel to automatically adjust its bandwidth allocation 
based on the volume of traffic flowing through the tunnel. You can configure an LSP with minimal bandwidth; 
this feature can dynamically adjust the LSP’s bandwidth allocation based on current traffic patterns. The 
bandwidth adjustments do not interrupt traffic flow through the tunnel. 


You set a sampling interval on an LSP configured with automatic bandwidth allocation. The average 
bandwidth is monitored during this interval. At the end of the interval, an attempt is made to signal a new 
path for the LSP with the bandwidth allocation set to the maximum average value for the preceding 
sampling interval. If the new path is successfully established and the original path is removed, the LSP is 
switched over to the new path. If a new path is not created, the LSP continues to use its current path until 
the end of the next sampling interval, when another attempt is made to establish a new path. Note that 
you can set minimum and maximum bandwidth values for the LSP. 


During the automatic bandwidth allocation interval, the router might receive a steady increase in traffic 
(increasing bandwidth utilization) on an LSP, potentially causing congestion or packet loss. To prevent this, 
you can define a second trigger to prematurely expire the automatic bandwidth adjustment timer before 
the end of the current adjustment interval. 


Configuring Automatic Bandwidth Allocation for LSPs 


IN THIS SECTION 


@ = Configuring Automatic Bandwidth Allocation on LSPs | 518 


@ Requesting Automatic Bandwidth Allocation Adjustment | 524 


Automatic bandwidth allocation allows an MPLS tunnel to automatically adjust its bandwidth allocation 
based on the volume of traffic flowing through the tunnel. You can configure an LSP with minimal bandwidth, 
and this feature can dynamically adjust the LSP’s bandwidth allocation based on current traffic patterns. 
The bandwidth adjustments do not interrupt traffic flow through the tunnel. 


At the end of the automatic bandwidth allocation time interval, the current maximum average bandwidth 
usage is compared with the allocated bandwidth for the LSP. If the LSP needs more bandwidth, an attempt 
is made to set up a new path where bandwidth is equal to the current maximum average usage. If the 
attempt is successful, the LSP’s traffic is routed through the new path and the old path is removed. If the 
attempt fails, the LSP continues to use its current path. 


NOTE: Incalculating the value for Max AvgBW (relative to the ingress LSP), the sample collected 
during make before break (MBB) is ignored to prevent inaccurate results. The first sample after 
a bandwidth adjustment, or after a change in the LSP ID (regardless of path change), is also 
ignored. 


If you have configured link and node protection for the LSP and traffic has been switched to the bypass 
LSP, the automatic bandwidth allocation feature continues to operate and take bandwidth samples from 
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the bypass LSP. For the first bandwidth adjustment cycle, the maximum average bandwidth usage taken 
from the original link and node-protected LSP is used to resignal the bypass LSP if more bandwidth is 
needed. (Link and node protection are not supported on QFX Series switches.) 


If you have configured fast-reroute for the LSP, you might not be able to use this feature to adjust the 
bandwidth. Because the LSPs use a fixed filter (FF) reservation style, when a new path is signaled, the 
bandwidth might be double-counted. Double-counting can prevent a fast-reroute LSP from ever adjusting 
its bandwidth when automatic bandwidth allocation is enabled. (Fast reroute is not supported on QFX 
Series switches.) 


To configure automatic bandwidth allocation, complete the steps in the following sections: 


NOTE: On the QFX10000 switches, you can only configure automatic bandwidth allocation at 
the edit protocols mpls hierarchy level. Logical systems are not supported. 


Configuring Automatic Bandwidth Allocation on LSPs 


IN THIS SECTION 


Configuring the Automatic Bandwidth Allocation Interval | 519 
Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth | 520 
Configuring the Automatic Bandwidth Adjustment Threshold | 521 


Configuring a Limit on Bandwidth Overflow and Underflow Samples | 521 


Configuring Passive Bandwidth Utilization Monitoring | 523 


To enable automatic bandwidth allocation on an LSP, include the auto-bandwidth statement: 


If an LSP has an automatic bandwidth configuration, you can disable automatic bandwidth adjustments 
on a particular path (either primary or secondary) by configuring a static bandwidth value and by disabling 
the CSPF computation (using the no-cspf statement). 


For example: 


user@host> show protocols mpls 
label-switched-path primary-path { 
to 192.168.0.1; 
Idp-tunneling; 
optimize-timer 3571; 


least-fill; 

link-protection; 

adaptive; 

auto-bandwidth { 
adjust-interval 7177; 
adjust-threshold 5; 
minimum-bandwidth 1m; 
maximum-bandwidth 2500000000; 
adjust-threshold-overflow-limit 2; 
resignal-minimum-bandwidth; 

} 

primary primary-path; 

secondary secondary-path { 
bandwidth 0; 
no-cspf; 
priority O O; 


The statements configured at the [edit protocols mpls label-switched-path label-switched-path-name 
auto-bandwidth] hierarchy level are optional and explained in the following sections: 


Configuring the Automatic Bandwidth Allocation Interval 


At the end of the automatic bandwidth allocation interval, the automatic bandwidth computation and new 
path setup process is triggered. 


NOTE: To prevent unnecessary resignaling of LSPs, it is best to configure an LSP adjustment 
interval that is at least three times longer than the MPLS automatic bandwidth statistics interval. 
For example, if you configure a value of 30 seconds for the MPLS automatic bandwidth statistics 
interval (interval statement at the [edit protocols mpls statistics] hierarchy level), you should 
configure a value of at least 90 seconds for the LSP adjustment interval (adjust-interval statement 
at the [edit protocols mpls label-switched-path label-switched-path-name auto-bandwidth] 
hierarchy level). See also “Configuring Reporting of Automatic Bandwidth Allocation Statistics 
for LSPs” on page 525. 


To specify the bandwidth reallocation interval in seconds for a specific LSP, include the adjust-interval 
statement: 


adjust-interval seconds; 


You can include this statement at the following hierarchy levels: 
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e [edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth] 


Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth 


You can maintain the LSP’s bandwidth between minimum and maximum bounds by specifying values for 
the minimum-bandwidth and maximum-bandwidth statements. 


NOTE: For a label-swtiched path (LSP) that has both bandwidth and minimum-bandwidth for 
autobandwidth configured under the [edit protocols mpls label-switched-path Isp-name] hierarchy 
level, the LSP bandwidth is adjusted differently. 


The LSP is initiated with the bandwidth value configured under the bandwidth statement at the 
[edit protocols mpls label-switched-path Isp-name] hierarchy level. At the expiry of the 
adjust-interval timer, the LSP bandwidth gets adjusted based on the traffic flow. 


If the bandwidth to be signaled is less than the value configured under the minimum-bandwidth 
statement at the [edit protocols mpls label-switched-path Isp-name autobandwidth] hierarchy 
level, then the LSP is signaled only using the minimum bandwidth. 


If the bandwidth to be signaled is greater than the value configured under the 
maximum-bandwidth statement at the [edit protocols mpls label-switched-path Isp-name 
autobandwidth] hierarchy level, then the LSP is signaled only using the maximum bandwidth. 


To specify the minimum amount of bandwidth allocated for a specific LSP, include the minimum-bandwidth 
statement: 


minimum-bandwidth bps; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth] 
To specify the maximum amount of bandwidth allocated for a specific LSP, include the maximum-bandwidth 


statement: 


maximum-bandwidth bps; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth] 


Configuring the Automatic Bandwidth Adjustment Threshold 


Use the adjust-threshold statement to specify the sensitivity of the automatic bandwidth adjustment of 
an LSP to changes in bandwidth utilization. You can set the threshold for when to trigger automatic 
bandwidth adjustments. When configured, bandwidth demand for the current interval is determined and 
compared to the LSP’s current bandwidth allocation. If the percentage difference in bandwidth is greater 
than or equal to the specified adjust-threshold percentage, the LSP’s bandwidth is adjusted to the current 
bandwidth demand. 


For example, assume that the current bandwidth allocation is 100 megabits per second (Mbps) and that 
the percentage configured for the adjust-threshold statement is 15 percent. If the bandwidth demand 
increases to 110 Mbps, the bandwidth allocation is not adjusted. However, if the bandwidth demand 
increases to 120 Mbps (20 percent over the current allocation) or decreases to 80 Mbps (20 percent under 
the current allocation), the bandwidth allocation is increased to 120 Mbps or decreased to 80 Mbps, 
respectively. 


To configure the threshold for automatic bandwidth adjustment, include the adjust-threshold statement: 


adjust-threshold percent; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth] 


Configuring a Limit on Bandwidth Overflow and Underflow Samples 


The automatic bandwidth adjustment timer is a periodic timer which is triggered every adjust interval to 
determine whether any bandwidth adjustments are required on the LSP's active path. This interval is 
typically configured as a long period of time, usually hours. If, at the end of adjust interval, the change in 
bandwidth is above a certain adjust threshold, the LSP is resignaled with the new bandwidth. 


During the automatic bandwidth adjustment interval, the router might receive a steady increase in traffic 
(increasing bandwidth utilization) on an LSP, potentially causing congestion or packet loss. To prevent this, 
you can define a second trigger to prematurely expire the automatic bandwidth adjustment timer before 
the end of the current adjustment interval. 


Every statistics interval, the router samples the average bandwidth utilization of an LSP and if this has 
exceeded the current maximum average bandwidth utilization, the maximum average bandwidth utilization 
is updated. 


During each sample period, the following conditions are also checked: 


e Is the current average bandwidth utilization above the active bandwidth of the path? 


e Has the difference between the average bandwidth utilization and the active bandwidth exceeded the 
adjust threshold (bandwidth utilization has changed significantly)? 
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If these conditions are true, it is considered to be one bandwidth overflow sample. Using the 
adjust-threshold-overflow-limit statement, you can define a limit on the number of bandwidth overflow 
samples such that when the limit is reached, the current automatic bandwidth adjustment timer is expired 
and a bandwidth adjustment is triggered. Once this adjustment is complete, the normal automatic bandwidth 
adjustment timer is reset to expire after the periodic adjustment interval. 


To specify a limit on the number of bandwidth overflow samples before triggering an automatic bandwidth 
allocation adjustment, configure the adjust-threshold-overflow-limit statement: 


adjust-threshold-overflow-limit number; 


Similarly, if the current average bandwidth utilization is below the active bandwidth of the path by the 
configured adjusted threshold (meaning that bandwidth utilization has gone down significantly), the sample 
is considered to be an underflow sample. The adjusted (new signaling) bandwidth after an adjustment due 
to underflow is the maximum average bandwidth among the underflow samples. Starting in Junos OS 
Release 14.1R9, 15.1R7, 16.1R5, 16.1X2, 16.2R3, and 17.2R2, all zero value bandwidth samples are 
considered as underflow samples, except for the zero value samples that arrive after an LSP comes up for 
the first time, and the zero value samples that arrive first after a Routing Engine switchover. 


You can specify a limit on the number of bandwidth underflow samples before triggering an automatic 
bandwidth allocation adjustment by configuring the adjust threshold-underflow-limit statement: 


adjust-threshold-underflow-limit number; 


These statements can be configured at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth] 


You must configure the adjust-threshold and minimum-bandwidth statements whenever you configure 
the adjust-threshold-underflow-limit statement. You must configure the adjust-threshold and 
maximum-bandwidth statements whenever you configure the adjust-threshold-overflow-limit statement 


e You must configure a nonzero value for the adjust-threshold statement if you configure the 
adjust-threshold-overflow-limit or adjust-threshold-underflow-limit statement. 


e Any bandwidth increase or decrease below the value configured for the adjust-threshold statement 
does not constitute an overflow or underflow condition. 


e To prevent unlimited increases in LSP bandwidth (to limit overflow beyond a certain bandwidth), you 
must also configure the maximum-bandwidth statement when you configure the 
adjust-threshold-overflow-limit statement. 


The following describes the other aspects of the adjust-threshold-overflow-limit statement: 
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e It only applies to bandwidth overflows. If the bandwidth is decreasing, the normal automatic bandwidth 
adjustment interval is used. 


e It does not affect manually triggered automatic bandwidth adjustment. 
e It applies to single-class DiffServ-TE LSPs. 


e Because the adjust-threshold-overflow-limit statement can trigger a bandwidth adjustment, it cannot 
be enabled at the same time as the monitor-bandwidth statement (for information about that statement, 
see “Configuring Passive Bandwidth Utilization Monitoring” on page 523). 


You cannot configure automatic bandwidth adjustments to occur more often than every 300 seconds. 
The adjust-threshold-overflow-limit statement is subject to the same minimum value with regard to the 
minimum frequency of adjustment allowed. Overflow condition based adjustments can occur no sooner 
than 300 seconds from the start of the overflow condition. Therefore it is required that: 


sample interval x adjust-threshold-overflow-limit >= 300s 


These values are checked during the commit operation. An error is returned if the value is less than 
300 seconds. 


If you change the value of the adjust-threshold-overflow-limit statement on a working router, you can 


expect the following behavior: 


e If you increase the current value of the adjust-threshold-overflow-limit statement, the old value is 
replaced with the new one. 


e If you decrease the current value of the adjust-threshold-overflow-limit statement and the current 
bandwidth overflow count is less than the new value, the old value is replaced with the new one. 


e If you decrease the current value of the adjust-threshold-overflow-limit statement and the current 
bandwidth overflow count is greater than the new value, the adjustment timer is immediately expired 
and a bandwidth adjustment is initiated. 


Configuring Passive Bandwidth Utilization Monitoring 


Use the monitor-bandwidth statement to switch to a passive bandwidth utilization monitoring mode. In 
this mode, no automatic bandwidth adjustments are made, but the maximum average bandwidth utilization 
is continuously monitored and recorded. 


To configure passive bandwidth utilization monitoring, include the monitor-bandwidth statement: 


monitor-bandwidth; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth] 


If you have configured an LSP with primary and secondary paths, the automatic bandwidth allocation 
statistics are carried over to the secondary path if the primary path fails. For example, consider a primary 
path whose adjustment interval is half complete and whose maximum average bandwidth usage is currently 
calculated as 50 Mbps. If the primary path suddenly fails, the time remaining for the next adjustment and 
the maximum average bandwidth usage are carried over to the secondary path. 


Requesting Automatic Bandwidth Allocation Adjustment 


For MPLS LSP automatic bandwidth allocation adjustment, the minimum value for the adjustment interval 
is 5 minutes (300 seconds). You might find it necessary to trigger a bandwidth allocation adjustment 
manually, for example in the following circumstances: 


e When you are testing automatic bandwidth allocation in a network lab. 


e When the LSP is configured for automatic bandwidth allocation in monitor mode (the monitor-bandwidth 
statement is included in the configuration as described in “Configuring Passive Bandwidth Utilization 
Monitoring” on page 523), and want to initiate an immediate bandwidth adjustment. 


To use the request mpls Isp adjust-autobandwidth command, the following must be true: 


e Automatic bandwidth allocation must be enabled on the LSP. 


e The criteria required to trigger a bandwidth adjustment have been met (the difference between the 
adjust bandwidth and the current LSP path bandwidth is greater than the threshold limit). 


A manually triggered bandwidth adjustment operates only on the active LSP path. Also, if you have enabled 
periodic automatic bandwidth adjustment, the periodic automatic bandwidth adjustment parameters (the 
adjustment interval and the maximum average bandwidth) are not reset after a manual adjustment. 


For example, suppose the periodic adjust interval is 10 hours and there are currently 5 hours remaining 
before an automatic bandwidth adjustment is triggered. If you initiate a manual adjustment with the request 
mpls Isp adjust-autobandwidth command, the adjust timer is not reset and still has 5 hours remaining. 


To manually trigger a bandwidth allocation adjustment, you need to use the request mpls Isp 
adjust-autobandwidth command. You can trigger the command for all affected LSPs on the router, or you 
can specify a particular LSP: 


user@host> request mpls Isp adjust-autobandwidth 


Once you execute this command, the automatic bandwidth adjustment validation process is triggered. If 
all the criteria for adjustment are met, the LSP’s active path bandwidth is adjusted to the adjusted bandwidth 
value determined during the validation process. 
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Configuring Reporting of Automatic Bandwidth Allocation Statistics for LSPs 


Automatic bandwidth allocation allows an MPLS tunnel to automatically adjust its bandwidth allocation 
based on the volume of traffic flowing through the tunnel. You can configure the device to collect statistics 
related to automatic bandwidth allocation by completing the following steps: 


1. To collect statistics related to automatic bandwidth allocation, configure the auto-bandwidth option 
for the statistics statement at the [edit protocols mpls] hierarchy level. These settings apply to all LSPs 
configured on the router on which you have also configured the auto-bandwidth statement at the [edit 
protocols mpls label-switched-path label-switched-path-name] hierarchy level. 


statistics { 
auto-bandwidth (MPLS Statistics); 
file filename <files number> <size size> <world-readable | no-world-readable>; 
interval seconds; 
no-transit-statistics; 
transit-statistics-polling; 


2. Specify the filename for the files used to store the MPLS trace operation output using the file option. 
All files are placed in the directory /var/log. We recommend that you place MPLS tracing output in the 
file mpls-log. 


3. Specify the maximum number of trace files using the files number option. When a trace file named 
trace-file reaches its maximum size, it is renamed trace-file.0, then trace-file.1, and so on, until the 
maximum number of trace files is reached. Then the oldest trace file is overwritten. 


4. Specify the interval for calculating the average bandwidth usage by configuring a time in seconds using 
the interval option. You can also set the adjustment interval on a specific LSP by configuring the interval 
option at the [edit protocols mpls label-switch-path label-switched-path-name statistics] hierarchy 
level. 


NOTE: To prevent unnecessary resignaling of LSPs, it is best to configure an LSP adjustment 
interval that is at least three times longer than the MPLS automatic bandwidth statistics 
interval. For example, if you configure a value of 30 seconds for the MPLS automatic 
bandwidth statistics interval (interval statement at the [edit protocols mpls statistics] hierarchy 
level), you should configure a value of at least 90 seconds for the LSP adjustment interval 
(adjust-interval statement at the [edit protocols mpls label-switched-path 
label-switched-path-name auto-bandwidth] hierarchy level). 
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5. To trace automatic bandwidth allocation, include the autobw-state flag for the MPLS traceoptions 
statement at the [edit protocols mpls] hierarchy level. 


The following configuration enables the MPLS traceoptions for automatic bandwidth allocation. The 
trace records are stored in a file called auto-band-trace (the filename is user configurable): 


[edit protocols mpls] 

traceoptions { 
file auto-band-trace size 10k files 10 world-readable; 
flag autobw-state; 


6. Using the show log command, you can display the automatic bandwidth allocation statistics file generated 
when you configure the auto-bandwidth (MPLS Statistics) statement. The following shows sample log 
file output taken from an MPLS statistics file named auto-band-stats on a router configured with an 
LSP named E-D. The log file shows that LSP E-D is operating over its reserved bandwidth limit initially. 
Before Oct 30 17:14:57, the router triggered an automatic bandwidth adjustment (you might see two 
sessions for an LSP undergoing an automatic bandwidth adjustment). By Oct 30 17:16:57, the LSP has 
been reestablished at a higher bandwidth and is now shown using less than 100 percent of its Reserved 
Bw (reserved bandwidth). 


user@host> show log auto-band-stats 
jd}=1D) (LSP ID 5, Tunnel ID 6741) 209 pkt 17094 Byte 
1 pps 90 Bps Util 240.01% Reserved Bw 37 Bps 
decr nh 0x95267247 type 4, flags 0x0); nugw 1, nhrd) 0) tovretcount VOce 307 1% o7, 





Total 1 sessions: 1 success, 0 fail, 0 ignored 
B=) (LSP ID 5, Tunnel ID 6741) 241 pkt ico ECW =) Ae) 
1 pps 88 Bps Util 234.67% Reserved Bw 37 Bias 
decr nh 0x9526224, type 4, flags 0x0), nagw Wl, nhid) 0) to retcount MOce 30) 17 714227, 





Total 1 sessions: 1 success, 0 fail, O ignored 
=D) (S32 10) S, Wivtoveretl iD) G 74h) 276 pkt 22607 Byte 
1 pps 95 Bps Util 253.34% Reserved Bw S37 Bios 
Clee mn Ox52e224, iyos “4, tlags Os, mew i, minicl © t@ retteoume oer 30 Iy7gilass7 





etc ls eSiskon sic SCC SIS)me Ome celal lm OmElchIa Giraecl 








j}=10) (LSP ID 5, Tunnel ID 6741) 0 pkt 0 Byte 
0 pps 0 Bps Util 0.00% Reserved Bw SE OS 

=I) (LSP ID 6, Tunnel ID 6741) OR pKE QO Byte 
0 pps O Bps Util 0.00% Reserved Bw 101 Bps 


decr nh 0x952c224, type 4, flags 0x0, n_gw 1, nhid 0 to refcount ldecr nh 
OxIs2es0s, ceyvse “4, tllags Ox0, mogw i, marcel 0 to mearocoume oct 30 17 eilss27 wocal 
2 sessions: 2 success, 0 fail, 0 ignored 


jd\=1D) (LSP ID 5, Tunnel ID 6741) OnpKE QO Byte 





7. 


8. 
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O pps O Bps Util 0.00% Reserved Bw 37 Bps 
i= ID) (LSP ID 6, Tunnel ID 6741) So) JOC 2695 Byte 
1 pps 89 Bps Util 87.69% Reserved Bw 101 Bps 


decr nh 0x952c224, type 4, flags 0x0, n_gw 1, nhid 0 to refcount ldecr nh 
OxI52e308, twee 4, tllags Ox0, mow i, marcel 0 to mearcoume lOc: 30 I7sisess7 wera 


2 sessions: 2 success, 0 fail, 0 ignored 








1D) (gS 1D) , AWiGbovereIl ICD) (6 7/4111) 0 pkt QO Byte 
0 pps 0 Bps Util 0.00% Reserved Bw 37 Bps 

11D) (LSP ID 6, Tunnel ID 6741) 65D 5338 Byte 
1 pps 88 Bps Util 86.70% Reserved Bw 101 Bps 


decr nh 0x952c224, type 4, flags 0x0, n_gw 1, nhid 0 to refcount ldecr nh 
OxIS52e308, twee 4, tillage Ox0, mow i, maicl 0 to mercoume lOc: 30 I7siees27 wetal 
2 sessions: 2 success, 0 fail, 0 ignored 
E-D (LSP ID 6, Tunnel ID 6741) 7 jolie 7981 Byte 
1 pps 88 Bps Util 86.70% Reserved Bw LOL isos 





decr nh 0x952c308) type 4, Elags 0x0), nagw i, nhc) 0 tor retcounts VOce 307 31657, 


Total 1 sessions: 1 success, 0 fail, 0 ignored 


Issue the show mpls Isp autobandwidth command to display current information about automatic 
bandwidth allocation. The following shows sample output from the show mpls Isp autobandwidth 
command taken at about the same time as the log file shown previously: 


user@host> show mpls lsp autobandwidth 
Lspname Last Requested Reserved Highwater 
AdjustTime LastAdjust 





BW BW BW mark Left 
(Siee) 
1D) 300bps 812.005bps 812bps 1.56801lkbps 294 sec 
Hac Oce 30 Lysiss26 21s 





Issue the file show command to display the MPLS trace file. You need to specify the file location and 
file name (the file is located in /var/log/. The following shows sample trace file output is taken from 
an MPLS trace file named auto-band-trace.0.gz on a router configured with an LSP named E-D. The 
trace file shows that LSP E-D is operating over its reserved bandwidth limit initially. At Oct 30 17:15:26, 
the router triggers an automatic bandwidth adjustment (you might see two sessions for an LSP 
undergoing an automatic bandwidth adjustment). By Oct 30 17:15:57, the LSP has been reestablished 
at a higher bandwidth and is now shown using less than 100 percent of its Reserved Bw (reserved 
bandwidth). 


user@host> file show /var/log/auto-band-trace.0.gz 
Oeics SO I7sisges7] crace_ome Weeciing ico " /waie/log/in/auicoconnc-crace” siceicirecl 
Oct 30 17:13:57.466825 LSP E-D (id 5) new bytes arrived 2A shin, 28) 








sec 


Ocis SO We ilas2 7. 


SN SST) 
Bps 


O6ic 30 I7sil4ie27 o 


bytes recorded 


Oeic 30 I7sil4ie2y o 


sec 


Oleic, Si) ay SLs By 7) 


ZENO) 7 
Bps 
Qcie 30 L7eldes7 
bytes recorded 
Qe SO 27 e9iaesy 
sec 
Oe 30 Ls ilas26 














466713 E-D (G32 IND) &, Weiaineil ID) 67/4! 11)) ZAM jolie 

Byte 1 pps 88 Bps Util 234.67% Reserved Bw 37 

466962 LSP E-D (id 5, old id 5); sampled bytes 19737 > 
17094 

467035 LSP E-D (id 5) new bytes arrived AG AS meine 9 

ANG (ys) Sh2) 1d)—ID) (LSP ID 5, Tunnel ID 6741) 2 WG) jONeIC 

Byte 1 pps 95 Bps Util 253.34% Reserved Bw 37 

-AGSTISE WS wD (acl 5, Ole acl 5)r sSamiplecl loyrras 2260 > 
SN Sh! 

-466825 LSP E-D (id 5) new bytes arrived 2BTO sain 2S) 

-265816 Adjust Autobw: LSP E-D (id 5) curr adj bw 300bps updated 


with 812.005bps 


Occ 30 I7silss26 
Oce SO Ty/silss26 


-266064 
5 HOSS 


prev active bw 300 bps 


mpls LSP 


Autobw Success: 








E-D Autobw change 512.005bps >= threshold 75bps 
LS iD) (() (old id 5 new id 6) update 





with 812 bps 
































Oct 30 17:15:26.363686 RPD_MPLS_ PATH BANDWIDTH_CHANGE: MPLS path (lsp E-D) 

bandwidth changed, path bandwidth 812 bps 

Oct 30 17:15:27.364751 RPD_MPLS_LSP_BANDWIDTH_CHANGE: MPLS LSP E-D bandwidth 

changed, lsp bandwidth 812 bps 

Qeie 30) Lyelss27 Noose’) in) (LSP ID 5, Tunnel ID 6741) 0 pkt 
0 Byte 0 pps O Bps Util 0.00% Reserved Bw 37 

Bps 

Gee 30 t7/slss27 467050 nD (LSP ID 6, Tunnel ID 6741) 0 pkt 
0 Byte 0 pps 0 Bps Util 0.00% Reserved Bw ALO) iL 

Bps 

Ooe 30 17s15357 466858 =D (LSP ID 5, Tunnel ID 6741) 0 pkt 
0 Byte 0 pps O Bps Util 0.00% Reserved Bw Sy 

Bps 

ce 30 17eilseo7 467106 ind (LSP ID 6, Tunnel ID 6741) SeupkKe 

2695 Byte 1 pps 89 Bps Util 87.69% Reserved Bw 1 Q)iL 
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You can configure an LSP to traverse multiple areas in a network by including the inter-domain statement 
as a part of the LSP configuration. This statement allows the router to search for routes in the IGP database. 
You need to configure this statement on routers that might be unable to locate a path using intra-domain 
CSPF (by looking in the traffic engineering database (TED)). When you configure inter-area LSPs, the 


inter-domain statement 


Before you begin: 


is required. 


e Configure the device interfaces with family MPLS. 


Configure the device router ID and autonomous system number. 
Enable MPLS and RSVP on the router and transit interfaces. 
Configure your IGP to support traffic engineering. 


Set up an LSP from the ingress to the egress router. 


To configure an LSP across multiple ASs on the ingress label-switched router (LER): 


1. 


[edit protocols] 


user@LER# set mpls interface all 


Enable MPLS on all the interfaces (excluding the management interface). 


user@LER# set mpls interface fxp0.0 disable 


Enable RSVP on all the interfaces (excluding the management interface). 


[edit protocols] 
user@LER# set rsvp interface all 
user@LER# set rsvp interface fxp0.0 disable 


3. Configure the inter-area LSP. 


[edit protocols] 
user@LER# set mpls label-switched-path inter-area-LSP-name to egress-LER-ip-address 
user@LER# set mpls label-switched-path inter-area-LSP-name inter-domain 


4. Verify and commit the configuration. 


[edit protocols] 

user@LER# set rsvp interface ge-0/0/0.0 

user@LER# set rsvp interface lo0.0 

user@LER# set rsvp interface fxp0.0 disable 

user@LER# set mpls statistics traffic-class-statistics 
user@LER# set mpls label-switched-path R1-R2 to 20.0.0.1 
user@LER# set mpls label-switched-path R1-R2 inter-domain 
user@LER# set mpls interface ge-0/0/0.0 

user@LER# set mpls interface 1o0.0 

user@LER# set mpls interface fxp0.0 disable 

user@LER# set ospf traffic-engineering 

user@LER# set ospf area 0.0.0.0 interface ge-0/0/0.0 
user@LER# set ospf area 0.0.0.0 interface lo0.0 


Damping Advertisement of LSP State Changes 


When an LSP changes from being up to being down, or from down to up, this transition takes effect 
immediately in the router software and hardware. However, when advertising LSPs into IS-IS and OSPF, 
you may want to damp LSP transitions, thereby not advertising the transition until a certain period of time 
has transpired (known as the hold time). In this case, if the LSP goes from up to down, the LSP is not 
advertised as being down until it has remained down for the hold-time period. Transitions from down to 
up are advertised into IS-IS and OSPF immediately. Note that LSP damping affects only the IS-IS and OSPF 
advertisements of the LSP; other routing software and hardware react immediately to LSP transitions. 


To damp LSP transitions, include the advertisement-hold-time statement: 


advertisement-hold-time seconds; 


seconds can be a value from O through 65,535 seconds. The default is 5 seconds. 
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You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


Configuring Corouted Bidirectional LSPs 


A corouted bidirectional packet LSP is a combination of two LSPs sharing the same path between a pair 
of ingress and egress nodes, as shown in Figure 41 on page 531. It is established using the GMPLS extensions 
to RSVP-TE. This type of LSP can be used to carry any of the standard types of MPLS-based traffic, including 
Layer 2 VPNs, Layer 2 circuits, and Layer 3 VPNs. You can configure a single BFD session for the 
bidirectional LSP (you do not need to configure a BFD session for each LSP in each direction). You can 
also configure a single standby bidirectional LSP to provide a backup for the primary bidirectional LSP. 
Corouted bidirectional LSPs are supported for both penultimate hop popping (PHP) and ultimate hop 
popping (UHP). 


High availability is available for bidirectional LSPs. You can enable graceful restart and nonstop active 
routing. Graceful restart and nonstop active routing are supported when the restarting router is the ingress, 
egress, or transit router for the bidirectional LSP. 


Figure 41: Corouted Bidirectional LSP 
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To configure a corouted bidirectional LSP: 


1. In configuration mode, configure the ingress router for the LSP and include the corouted-bidirectional 
statement to specify that the LSP be established as a corouted bidirectional LSP. 


The path is computed using CSPF and initiated using RSVP signaling (just like a unidirectional RSVP 
signaled LSP). Both the path to the egress router and the reverse path from the egress router are created 
when this configuration is committed. 


[edit protocols mpls] 
user@PE1# set label-switched-path sample-Isp corouted-bidirectional 


2. (Optional) For a reverse path, configure an LSP on the egress router and include the 
corouted-bidirectional-passive statement to associate the LSP with another LSP. 
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No path computation or signaling is used for this LSP since it relies on the path computation and 
signaling provided by the ingress LSP. You cannot configure both the corouted-bidirectional statement 
and the corouted-bidirectional-passive statement on the same LSP. 


[edit protocols mpls] 


user@PE1# set label-switched-path sample-Isp-reverse-path corouted-bidirectional-passive 


This statement also makes it easier to debug corouted bidirectional LSPs. If you configure the 
corouted-bidirectional-passive statement (again, on the egress router), you can issue ping mpls 
Isp-end-point, ping mpls Idp, ping mpls rsvp, traceroute mpls Idp, and traceroute mpls rsvp commands 
to test the corouted bidirectional LSP from the egress router. 


Use the show mpls Isp extensive and the show rsvp session extensive commands to display information 
about the bidirectional LSP. 


The following shows output for the show rsvp session extensive command when run on an ingress 
router with a bidirectional LSP configured: 


user@PE1> show rsvp session extensive 


Ingress RSVP: 2 sessions 


10.255 14.39) 
From: 10.255.14.43, LSPstate: Up, ActiveRoute: 0 
LSPname: l-to-h, LSPpath: Primary 





LSPtype: Static Configured 


Bidirectional, Upstream label in: 3, Upstream label out: - 








Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 300032 
Resv style: 1 FF, Label in: , Label out: 300032 
Time left: =, SuiMmeeg Wwe wes Si O8s4os2s Zoid 





Tspec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 24617 protocol 0 
PATH rcevfrom: localclient 

Adspec: sent MTU 1500 

Path MTU: received 1500 

PATH sentto: 10.1.1.2 (ge-0/0/0.0) 3396 pkts 
RESV revirom: 10.1.1.2 (ge-0/0/0.0) 3394 pkts 
PATH notifyto: localclient 

NGG mowLEVeEO? 10) ,.255,14.3¢ 








Protection attributes: primary, working, 1:N protection 
Association attributes: recovery, sre 10.255.14.43, id 1 
Hole wows, LO ga IO.1.2.2 LO.1.3.2 
NeCorme PouESs LO .d.1.2 I@.1,262 IW.1,362 
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10,255.14. 39) 
From: 10.255.14.43, LSPstate: Up, ActiveRoute: 0 
LSPname: 1-to-h, LSPpath: Secondary 





LSPtype: Static Configured 


Bidirectional, Upstream label in: 3, Upstream label out: - 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 300032 
Resv style: 1 FF, Label in: -, Label out: 300032 
Time left: =, SumeSee Woe Weny Si O8s4Oe25 Zoid 





Tspec: rate Obps size Obps peak Infbps m 20 M 1500 


Port number: sender 2 receiver 24617 protocol 0 





PATH revfrom: localclient 

Adspec: sent MTU 1500 

Path MTU: received 1500 

DAME sSemiccos LO, 1,2 (ge-O/0/0.0) 3396 pkies 
RESV revirom: 10.1.1.2 (ge-0/0/0.0) 3394 pkts 





Protection attributes: primary, protecting 

Association attributes: recovery, sre 10.255.14.43, id 1 
Holt wOUESs LO 2.1.2 IO .2.2.2 LU. 2.352 

NCO! PouUESs LO .2.do2 WO,.2.2.2 1IO.k.3.28 

Total 2 displayed, Up 2, Down 0 





Egress RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 
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Configuring the Entropy Label for LSPs 


The insertion of entropy labels for an LSP enables transit routers to load-balance MPLS traffic across ECMP 
paths or Link Aggregation groups using just the MPLS label stack as a hash input without having to rely 
on deep packet inspection. Deep packet inspection requires more of the router’s processing power and 
different routers have differing deep-packet inspection capabilities. 


To configure the entropy label for an LSP, complete the following steps: 


1. On the ingress router, include the entropy-label statement at the [edit protocols mpls 
labeled-switched-path labeled-switched-path-name] hierarchy level or at the [edit protocols mpls 
static-labeled-switched-path labeled-switched-path-name ingress] hierarchy level. The entropy label 
is added to the MPLS label stack and can be processed in the forwarding plane. 


entropy-label; 


NOTE: This is only applicable for RSVP and static LSPs. 


2. On the ingress router, you can configure an ingress policy for LDP-signaled LSPs: 


entropy-label { 
ingress-policy policy-name; 


Configure the ingress policy at the [edit policy-options] hierarchy level: 


policy-options { 
policy-statement policy-name { 
term term-name { 
from { 
prefix-list prefix-list-name; 
} 


then actions; 


The following shows an example of an entropy label ingress policy. 


policy-options { 
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policy-statement entropy-policy { 
term no-insert-entropy-label { 
from { 
prefix-list no-entropy-label-fec; 


} 


then accept; 


3. (Optional) By default, routers that support the pushing and popping of entropy labels are configured 
with the load-balance-label-capability statement at the [edit forwarding-options] hierarchy level to 
signal the labels on a per-LSP basis. If the peer router is not equipped to handle load-balancing labels, 
you can prevent the provider edge (PE) router from signaling the entropy label capability by configuring 
the no-load-balance-label-capability statement at the [edit forwarding-options] hierarchy level. 


[edit forwarding-options] 
user@PE no-load-balance-label-capability; 


Transit routers require no configuration. The presence of the entropy label indicates to the transit router 
to load balance based solely on the MPLS label stack. 


Penultimate hop routers pop the entropy label by default. 


Example: Configuring an Entropy Label for a BGP Labeled Unicast LSP 


IN THIS SECTION 


Requirements | 536 
Overview | 536 
Configuration | 538 


Verification | 556 


This example shows how to configure an entropy label for a BGP labeled unicast to achieve end-to-end 
load balancing using entropy labels. When an IP packet has multiple paths to reach its destination, Junos 
OS uses certain fields of the packet headers to hash the packet to a deterministic path. This requires an 
entropy label, a special load-balancing label that can carry the flow information. LSRs in the core simply 
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use the entropy label as the key to hash the packet to the correct path. An entropy label can be any label 
value between 16 to 1048575 (regular 20-bit label range). Since this range overlaps with the existing 
regular label range, a special label called entropy label indicator (ELI) is inserted before the entropy label. 
ELI is a special label assigned by IANA with the value of 7. 


BGP labeled unicasts generally concatenate RSVP or LDP LSPs across multiple IGP areas or multiple 
autonomous systems. RSVP or LDP entropy labels are popped at the penultimate hop node, together with 
the RSVP or LDP label. This feature enables the use of entropy labels at the stitching points to bridge the 
gap between the penultimate hop node and the stitching point, in order to achieve end-to-end entropy 
label load balancing for BGP traffic. 

Requirements 


This example uses the following hardware and software components: 

e Seven MX Series routers with MPCs 

e Junos OS Release 15.1 or later running on all the devices 

Before you configure an entropy label for BGP labeled unicast, make sure you: 


1. Configure the device interfaces. 


2. Configure OSPF or any other IGP protocol. 


3. Configure BGP. 


4. Configure RSVP. 


5. Configure MPLS. 


Overview 


When BGP labeled unicasts concatenate RSVP or LDP LSPs across multiple IGP areas or multiple 
autonomous systems, RSVP or LDP entropy labels are popped at the penultimate hop node, together with 
the RSVP or LDP label. However, there are no entropy labels at the stitching points, that is, the routers 
between two areas. Therefore, the routers at the stitching points used the BGP labels to forward packets. 


Beginning with Junos OS Release 15.1, you can configure an entropy label for BGP labeled unicast to 
achieve end-to-end entropy label load balancing. This feature enables the use of an entropy label at the 
stitching points in order to achieve end-to-end entropy label load balancing for BGP traffic. Junos OS 
allows the insertion of entropy labels at the BGP labeled unicast LSP ingress. 


By default, routers that support entropy labels are configured with the load-balance-label-capability 
statement at the [edit forwarding-options] hierarchy level to signal the labels on a per-LSP basis. If the 
peer router is not equipped to handle load-balancing labels, you can prevent the signaling of entropy label 
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capability by configuring the no-load-balance-label-capability at the [edit forwarding-options] hierarchy 
level. 


[edit forwarding-options] 
user@PE# no-load-balance-label-capability 


NOTE: You can explicitly disable advertising entropy label capability at egress for routes specified 
in the policy with the no-entropy-label-capability option at the [edit policy-options 
policy-statement policy name then] hierarchy level. 


[edit policy-options policy-statement policy-name then] 
user@PE# no-entropy-label-capability 


Topology 


In Figure 42 on page 538 , Router PE1 is the ingress router and Router PE2 is the egress router. Routers 
P1 and P2 are the transit routers. Router ABR is the area bridge router between Area O and Area 1. LAG 
is configured on the provider routers for load balancing the traffic. Entropy label capability for BGP labeled 
unicast is enabled on the ingress Router PE1. 
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Figure 42: Configuring an Entropy Label for BGP Labeled Unicast 
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Configuration 


IN THIS SECTION 


Configuring Router PE1 | 544 


@ 

@ Configuring Router P1 | 548 
@ = Configuring Router ABR | 550 
e 


Results | 552 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


Router PE1 
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set interfaces ge-0/0/0 unit 0 family inet address 1.5.0.1/24 

set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family inet6 address 2000::1:5:0:1/120 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 1.1.0.1/24 

set interfaces ge-0/0/1 unit 0 family iso 

set interfaces ge-0/0/1 unit 0 family inet6 address 2000::1:1:0:1/120 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 50.0.1.1/24 

set interfaces ge-0/0/2 unit 0 family inet6 address 2000::1:34:0:2/120 
set interfaces ge-0/0/3 vlan-tagging 

set interfaces ge-0/0/3 unit 0 vian-id 520 

set interfaces ge-0/0/3 unit 0 family inet address 1.0.0.2/16 

set interfaces loO unit O family inet address 10.255.101.100/32 primary 
set routing-options router-id 10.255.101.100 

set routing-options autonomous-system 1 

set protocols rsvp interface all 

set protocols mpls icmp-tunneling 

set protocols mpls no-cspf 

set protocols mpls label-switched-path r0-r2 to 10.255.102.102 

set protocols mpls label-switched-path r0-r2 entropy-label 

set protocols mpls interface all 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp local-address 10.255.101.100 

set protocols bgp group ibgp family inet labeled-unicast entropy-label 
set protocols bgp group ibgp neighbor 10.255.102.102 family inet labeled-unicast rib inet.3 
set protocols bgp group ibgp neighbor 10.255.101.200 family inet-vpn unicast 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set policy-options prefix-list el-fec 10.255.101.200/32 

set policy-options prefix-list el-fec-2 10.255.102.102/32 

set policy-options policy-statement EL from prefix-list el-fec 

set policy-options policy-statement EL then accept 

set policy-options policy-statement EL-2 from prefix-list el-fec-2 

set policy-options policy-statement EL-2 then accept 

set policy-options policy-statement bgp-to-ospf from protocol bgp 
set policy-options policy-statement bgp-to-ospf then accept 

set policy-options policy-statement ospf-to-bgp from protocol ospf 
set policy-options policy-statement ospf-to-bgp then accept 

set policy-options policy-statement stat-to-bgp from protocol static 
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set policy-options policy-statement stat-to-bgp then accept 

set policy-options community VPN members target:100:1 

set routing-instances VPN-I3vpn instance-type vrf 

set routing-instances VPN-I3vpn interface ge-0/0/2.0 

set routing-instances VPN-I3vpn interface ge-0/0/3.0 

set routing-instances VPN-I3vpn route-distinguisher 100.100.100.100:100 

set routing-instances VPN-I3vpn vrf-target target:100:1 

set routing-instances VPN-I3vpn routing-options static route 5.0.0.0/16 next-hop 1.0.0.1 
set routing-instances VPN-I3vpn protocols ospf export bgp-to-ospf 

set routing-instances VPN-I3vpn protocols ospf area 0.0.0.0 interface ge-0/0/2.0 


Router P1 


set interfaces ge-0/0/0 unit 0 family inet address 1.5.0.2/24 

set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family inet6 address 2000::1:5:0:2/120 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 gigether-options 802.3ad aeO 

set interfaces ge-0/0/2 unit 0 family inet address 1.1.0.2/24 

set interfaces ge-0/0/2 unit 0 family iso 

set interfaces ge-0/0/2 unit 0 family inet6 address 2000::1:1:0:2/120 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 gigether-options 802.3ad aeO 

set interfaces aeO unit 0 family inet address 1.12.0.1/24 

set interfaces aeO unit O family mpls 

set interfaces loO unit O family inet address 10.255.102.101/32 primary 
set forwarding-options hash-key family mpls label-1 

set forwarding-options hash-key family mpls label-2 

set forwarding-options hash-key family mpls label-3 

set forwarding-options enhanced-hash-key family mpls no-payload 
set routing-options router-id 10.255.102.101 

set routing-options autonomous-system 1 

set routing-options forwarding-table export pplb 

set protocols rsvp interface all 

set protocols mpls icmp-tunneling 

set protocols mpls interface all 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface all 
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set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 
set policy-options policy-statement pplb then load-balance per-packet 


Router ABR 


set interfaces ge-0/0/0 gigether-options 802.3ad aeO 

set interfaces ge-0/0/1 gigether-options 802.3ad ae1 

set interfaces ge-0/0/2 gigether-options 802.3ad aeO 

set interfaces ge-0/0/3 gigether-options 802.3ad ae1 

set interfaces aeO unit 0 family inet address 1.12.0.2/24 

set interfaces aeO unit O family mpls 

set interfaces ae1 unit O family inet address 1.23.0.1/24 

set interfaces ae1 unit O family mpls 

set interfaces loO unit O family inet address 10.255.102.102/32 primary 
set forwarding-options hash-key family mpls label-1 

set forwarding-options hash-key family mpls label-2 

set forwarding-options hash-key family mpls label-3 

set forwarding-options enhanced-hash-key family mpls no-payload 
set routing-options router-id 10.255.102.102 

set routing-options autonomous-system 1 

set routing-options forwarding-table export pplb 

set protocols rsvp interface all 

set protocols mpls icmp-tunneling 

set protocols mpls label-switched-path r2-r0 to 10.255.101.100 
set protocols mpls label-switched-path r2-r0 entropy-label 

set protocols mpls label-switched-path r2-r4 to 10.255.101.200 
set protocols mpls label-switched-path r2-r4 entropy-label 

set protocols mpls interface all 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp local-address 10.255.102.102 

set protocols bgp group ibgp family inet labeled-unicast rib inet.3 
set protocols bgp group ibgp neighbor 10.255.101.100 export send-inet3-R4 
set protocols bgp group ibgp neighbor 10.255.101.200 export send-inet3-RO 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ae0.0 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 
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set protocols ospf area 0.0.0.1 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.1 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.1 interface ae1.0 

set protocols Idp interface all 

set policy-options policy-statement pplb then load-balance per-packet 

set policy-options policy-statement send-inet3-RO from route-filter 10.255.101.100/32 exact 
set policy-options policy-statement send-inet3-RO then accept 

set policy-options policy-statement send-inet3-R4 from route-filter 10.255.101.200/32 exact 
set policy-options policy-statement send-inet3-R4 then accept 


Router P2 


set chassis aggregated-devices ethernet device-count 3 

set interfaces ge-0/0/0 gigether-options 802.3ad aeO 

set interfaces ge-0/0/1 unit 0 family inet address 1.34.0.1/24 

set interfaces ge-0/0/1 unit 0 family iso 

set interfaces ge-0/0/1 unit 0 family inet6 address 2000::1:34:0:1/120 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 gigether-options 802.3ad aeO 

set interfaces ae1 unit O family inet address 1.23.0.2/24 

set interfaces ae1 unit O family mpls 

set interfaces loO unit O family inet address 10.255.102.103/32 primary 
set forwarding-options enhanced-hash-key family mpls no-payload 
set routing-options router-id 10.255.102.103 

set routing-options autonomous-system 1 

set routing-options forwarding-table export pplb 

set protocols rsvp interface all 

set protocols mpls icmp-tunneling 

set protocols mpls interface all 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.1 interface lo0.0 passive 

set protocols ospf area 0.0.0.1 interface fxp0.0 disable 

set protocols ospf area 0.0.0.1 interface all 

set policy-options policy-statement pplb then load-balance per-packet 


Router PE2 
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set interfaces ge-0/0/0 unit 0 family inet address 1.34.0.2/24 

set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family inet6 address 2000::1:34:0:2/120 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 vlan-tagging 

set interfaces ge-0/0/1 unit 0 vian-id 520 

set interfaces ge-0/0/1 unit 0 family inet address 2.0.0.2/16 

set interfaces ge-0/0/2 unit 0 family inet address 50.4.1.1/24 

set interfaces ge-0/0/2 unit 0 family inet6 address 2000::1:34:0:2/120 
set interfaces loO unit O family inet address 10.255.101.200/32 primary 
set routing-options router-id 10.255.101.200 

set routing-options autonomous-system 1 

set protocols rsvp interface all 

set protocols mpls icmp-tunneling 

set protocols mpls no-cspf 

set protocols mpls label-switched-path r4-r2 to 10.255.102.102 

set protocols mpls label-switched-path r4-r2 entropy-label 

set protocols mpls interface all 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp local-address 10.255.101.200 

set protocols bgp group ibgp neighbor 10.255.102.102 family inet labeled-unicast rib inet.3 
set protocols bgp group ibgp neighbor 10.255.101.100 family inet-vpn unicast 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.1 interface all 

set protocols ospf area 0.0.0.1 interface fxp0.0 disable 

set protocols ospf area 0.0.0.1 interface lo0.0 passive 

set policy-options prefix-list el-fec 10.255.101.100/32 

set policy-options policy-statement EL term el from prefix-list el-fec 
set policy-options policy-statement EL term el then accept 

set policy-options policy-statement bgp-to-ospf from protocol bgp 

set policy-options policy-statement bgp-to-ospf then accept 

set policy-options policy-statement ospf-to-bgp from protocol ospf 

set policy-options policy-statement ospf-to-bgp then accept 

set policy-options policy-statement stat-to-bgp from protocol static 
set policy-options policy-statement stat-to-bgp then accept 

set policy-options community VPN members target:100:1 

set routing-instances VPN-I3vpn instance-type vrf 

set routing-instances VPN-I3vpn interface ge-0/0/1.0 

set routing-instances VPN-I3vpn interface ge-0/0/2.0 

set routing-instances VPN-I3vpn route-distinguisher 100.100.100.100:104 
set routing-instances VPN-I3vpn vrf-target target:100:1 

set routing-instances VPN-I3vpn routing-options static route 6.0.0.0/16 next-hop 2.0.0.1 
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set routing-instances VPN-I3vpn protocols ospf export bgp-to-ospf 
set routing-instances VPN-I3vpn protocols ospf area 0.0.0.0 interface ge-0/0/2.0 
set routing-instances VPN-I3vpn protocols ospf area 0.0.0.0 interface ge-0/0/1.0 


Configuring Router PE1 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Router PE1: 


NOTE: Repeat this procedure for Router PE2 after modifying the appropriate interface names, 
addresses, and other parameters. 


1. Configure the interfaces with IPv4 and IPvé addresses. 


[edit interfaces] 

user@PE1# set ge-0/0/0 unit O family inet address 1.5.0.1/24 
user@PE1# set ge-0/0/0 unit 0 family iso 

user@PE1# set ge-0/0/0 unit O family inet6 address 2000::1:5:0:1/120 
user@PE1# set ge-0/0/0 unit 0 family mpls 


user@PE1# set ge-0/0/1 unit O family inet address 1.1.0.1/24 
user@PE1# set ge-0/0/1 unit O family iso 

user@PE1# set ge-0/0/1 unit O family inet6 address 2000::1:1:0:1/120 
user@PE1# set ge-0/0/1 unit 0 family mpls 


user@PE1# set ge-0/0/2 unit 0 family inet address 50.0.1.1/24 
user@PE1# set ge-0/0/2 unit O family inet6 address 2000::1:34:0:2/120 


user@PE1# set ge-0/0/3 vian-tagging 
user@PE1# set ge-0/0/3 unit 0 vian-id 520 
user@PE1# set ge-0/0/3 unit O family inet address 1.0.0.2/16 


2. Configure the loopback interface. 


[edit interfaces] 
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user@PE1# set loO unit O family inet address 10.255.101.100/32 primary 


3. Set the router ID and the autonomous system number. 


[edit routing-options] 
user@PE1# set router-id 10.255.101.100 
user@PE1# set autonomous-system 1 


4. Configure RSVP protocol for all interfaces. 


[edit protocols] 
user@PE1# set protocols rsvp interface all 


5. Enable MPLS on all the interfaces of Router PE1 and specify the LSP. 


[edit protocols] 

user@PE1# set mpls icmp-tunneling 

user@PE1# set mpls no-cspf 

user@PE1# set mpls label-switched-path r0-r2 to 10.255.102.102 
user@PE1# set mpls label-switched-path r0-r2 entropy-label 
user@PE1# set mpls interface all 


6. Configure IBGP on the internal routers. 


[edit protocols] 
user@PE1# set bgp group ibgp type internal 
user@PE1# set bgp group ibgp local-address 10.255.101.100 


7. Enable entropy label capability for BGP labeled unicast for internal BGP group ibgp. 


user@PE1# set bgp group ibgp family inet labeled-unicast entropy-label 
user@PE1# set bgp group ibgp neighbor 10.255.102.102 family inet labeled-unicast rib inet.3 
user@PE1# set bgp group ibgp neighbor 10.255.101.200 family inet-vpn unicast 


8. Enable the OSPF protocol on all the interfaces of the area border router (ABR). 


[edit protocols] 
user@PE1# set ospf traffic-engineering 
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user@PE1# set ospf area 0.0.0.0 interface all 
user@PE1# set ospf area 0.0.0.0 interface fxp0.0 disable 
user@PE1# set ospf area 0.0.0.0 interface lo0.0 passive 


9. Define prefix lists to specify the routes with entropy label capability. 
[edit policy-options ] 


user@PE1# set policy-options prefix-list el-fec 10.255.101.200/32 
user@PE1# set policy-options prefix-list el-fec-2 10.255.102.102/32 


10. Define a policy EL to specify the routes with entropy label capability. 
[edit policy-options ] 


user@PE1# set policy-statement EL from prefix-list el-fec 
user@PE1# set policy-statement EL then accept 


11. Define another policy EL-2 to specify the routes with entropy label capability. 
[edit policy-options ] 


user@PE1# set policy-statement EL-2 from prefix-list el-fec-2 
user@PE1# set policy-statement EL-2 then accept 


12. Define a policy to export BGP routes to the OSPF routing table. 
[edit policy-options ] 


user@PE1# set policy-statement bgp-to-ospf from protocol bgp 
user@PE1# set policy-statement bgp-to-ospf then accept 


13. Define a policy to export OSPF routes to the BGP routing table. 
[edit policy-options ] 


user@PE1# set policy-statement ospf-to-bgp from protocol ospf 
user@PE1# set policy-statement ospf-to-bgp then accept 


14. Define a policy to export static routes to the BGP routing table. 


[edit policy-options ] 
user@PE1# set policy-statement stat-to-bgp from protocol static 


user@PE11# set policy-statement stat-to-bgp then accept 


15. Configure a VPN target for the VPN community. 


[edit policy-options ] 
user@PE1# set community VPN members target:100:1 


16. Configure the Layer 3 VPN routing instance VPN-I3vpn. 


[edit routing-instances] 
user@PE1# set VPN-I3vpn instance-type vrf 


17. Assign the interfaces for the VPN-I3vpn routing instance. 


[edit routing-instances] 
user@PE1# set VPN-I3vpn interface ge-0/0/2.0 
user@PE1# set VPN-I3vpn interface ge-0/0/3.0 


18. Configure the route distinguisher for the VPN-I3vpn routing instance. 


[edit routing-instances] 
user@PE1# set VPN-I3vpn route-distinguisher 100.100.100.100:100 


19. Configure a VPN routing and forwarding (VRF) target for the VPN-I3vpn routing instance. 


[edit routing-instances] 
user@PE1# set VPN-I3vpn vrf-target target:100:1 


20. Configure a static route to Device CE1 using the Layer 3 VPN protocol for the VPN-I3vpn routing 
instance. 


[edit routing-instances] 
user@PE1# set VPN-I3vpn routing-options static route 5.0.0.0/16 next-hop 1.0.0.1 


21. Export the BGP routes to the OSPF routing table for the VPN-I3vpn routing instance. 
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[edit routing-instances] 
user@PE1# set VPN-I3vpn protocols ospf export bgp-to-ospf 


22. Assign the OSPF interface for the VPN-I3vpn routing instance. 


[edit routing-instances] 
user@PE1# set VPN-I3vpn protocols ospf area 0.0.0.0 interface ge-0/0/2.0 


Configuring Router P1 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Router P11: 


NOTE: Repeat this procedure for Router P2 after modifying the appropriate interface names, 
addresses, and other parameters. 


1. Configure the interfaces with IPv4 and IPvé addresses. 


[edit interfaces] 

user@P1# set ge-0/0/0 unit O family inet address 1.5.0.2/24 
user@P1# set ge-0/0/0 unit O family iso 

user@P1# set ge-0/0/0 unit O family inet6 address 2000::1:5:0:2/120 
user@P1# set ge-0/0/0 unit O family mpls 


user@P1# set ge-0/0/2 unit O family inet address 1.1.0.2/24 
user@P1# set ge-0/0/2 unit 0 family iso 

user@P1# set ge-0/0/2 unit O family inet6 address 2000::1:1:0:2/120 
user@P1# set ge-0/0/2 unit O family mpls 


user@P1# set ge-0/0/1 gigether-options 802.3ad aeO 


user@P1# set ge-0/0/3 gigether-options 802.3ad aeO 


2. Configure link aggregation on the interfaces. 


user@P1# set aeO unit O family inet address 1.12.0.1/24 
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user@P1# set aeO unit O family mpls 


3. Configure the loopback interface. 


[edit interfaces] 
user@P1# set loO unit 0 family inet address 10.255.102.101/32 primary 


4. Configure MPLS labels that the router uses for hashing the packets to its destination for load balancing. 


[edit forwarding-options] 

user@P1# set hash-key family mpls label-1 

user@P1# set hash-key family mpls label-2 

user@P1# set hash-key family mpls label-3 

user@P1# set enhanced-hash-key family mpls no-payload 


5. Set the router ID and the autonomous system number. 
[edit routing-options] 


user@P1# set router-id 10.255.102.101 
user@P1# set autonomous-system 1 


6. Enable per packet load balancing. 


[edit routing-options] 
user@P1# set forwarding-table export pplb 


7. Configure the RSVP protocol for all interfaces. 


[edit protocols] 
user@P1# set protocols rsvp interface all 


8. Enable MPLS on all the interfaces of Router P1 and specify the LSP. 


[edit protocols] 
user@P1# set protocols mpls icmp-tunneling 
user@P1# set protocols mpls interface all 
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9. Enable the OSPF protocol on all the interfaces of Router P1 excluding the management interface. 


[edit protocols] 

user@P1# set protocols ospf traffic-engineering 

user@P1# set protocols ospf area 0.0.0.0 interface lo0.0 passive 
user@P1# set protocols ospf area 0.0.0.0 interface fxp0.0 disable 
user@P1# set protocols ospf area 0.0.0.0 interface all 

user@P1# set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 
user@P1# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 


10. Define a policy for per packet load balancing. 


[edit policy-options]] 
user@P1# set policy-statement pplb then load-balance per-packet 


Configuring Router ABR 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Router ABR: 


1. Configure the interfaces with IPv4 and IPvé addresses. 


[edit interfaces] 
user@ABR# set ge-0/0/0 gigether-options 802.3ad aeO 


user@ABR# set ge-0/0/1 gigether-options 802.3ad ae1 
user@ABR# set ge-0/0/2 gigether-options 802.3ad aeO 


user@ABR# set ge-0/0/3 gigether-options 802.3ad ae1 


2. Configure the loopback interface. 


[edit interfaces] 
user@ABR# set loO unit O family inet address 10.255.102.102/32 primary 


3. Configure link aggregation on the interfaces. 


[edit interfaces] 

user@ABR# set aeO unit O family inet address 1.12.0.2/24 
user@ABR# set aeO unit 0 family mpls 

user@ABR# set ae1 unit 0 family inet address 1.23.0.1/24 
user@ABR# set ae1 unit O family mpls 


4. Configure MPLS labels that the router uses for hashing the packets to its destination for load balancing. 


[edit forwarding-options] 

user@ABR# set hash-key family mpls label-1 

user@ABR# set hash-key family mpls label-2 

user@ABR# set hash-key family mpls label-3 

user@ABR# set enhanced-hash-key family mpls no-payload 


5. Set the router ID and the autonomous system number. 
[edit routing-options] 


user@ABR# set router-id 10.255.102.102 
user@ABR# set autonomous-system 1 


6. Enable per packet load balancing. 


[edit routing-options] 
user@ABR# set forwarding-table export pplb 


7. Configure the RSVP protocol for all interfaces. 


[edit protocols] 
user@ABR# set protocols rsvp interface all 


8. Enable MPLS on all the interfaces of Router P1 and specify the LSP. 


[edit protocols] 

user@ABR# set mpls icmp-tunneling 

user@ABR# set mpls label-switched-path r2-r0 to 10.255.101.100 
user@ABR# set mpls label-switched-path r2-r0 entropy-label 
user@ABR# set mpls label-switched-path r2-r4 to 10.255.101.200 
user@ABR# set mpls label-switched-path r2-r4 entropy-label 
user@ABR# set mpls interface all 
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9. Configure IBGP on the internal routers. 


[edit protocols ] 

user@ABR# set bgp group ibgp type internal 

user@ABR# set bgp group ibgp local-address 10.255.102.102 

user@ABR# set bgp group ibgp family inet labeled-unicast rib inet.3 
user@ABR# set bgp group ibgp neighbor 10.255.101.100 export send-inet3-R4 
user@ABR# set bgp group ibgp neighbor 10.255.101.200 export send-inet3-RO 


10. Enable the OSPF protocol on all the interfaces of ABR. 


[edit protocols ] 

user@ABR# set ospf traffic-engineering 

user@ABR# set ospf area 0.0.0.0 interface lo0.0 passive 
user@ABR# set ospf area 0.0.0.0 interface ge-0/0/2.0 
user@ABR# set ospf area 0.0.0.0 interface ge-0/0/0.0 
user@ABR# set ospf area 0.0.0.0 interface ae0.0 
user@ABR# set ospf area 0.0.0.0 interface fxp0.0 disable 
user@ABR¢# set ospf area 0.0.0.1 interface ge-0/0/3.0 
user@ABR# set ospf area 0.0.0.1 interface ge-0/0/1.0 
user@ABR# set ospf area 0.0.0.1 interface ae1.0 


11. Define a policy to specify the routes with entropy label capability. 


[edit policy-options ] 

user@ABR# set policy-statement pplb then load-balance per-packet 

user@ABR# set policy-statement send-inet3-RO from route-filter 10.255.101.100/32 exact 
user@ABR# set policy-statement send-inet3-RO then accept 

user@ABRi set policy-statement send-inet3-R4 from route-filter 10.255.101.200/32 exact 
user@ABR# set policy-statement send-inet3-R4 then accept 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
show routing-options, show forwarding options, and show policy-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


[edit] 
user@ABR# show interfaces 
ge-0/0/0 { 
gigether-options { 
802.3ad aeO; 
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} 
ge-0/0/1 { 
gigether-options { 
802.3ad ae1; 


} 
ge-0/0/2 { 
gigether-options { 
802.3ad aeO; 


} 
ge-0/0/3 { 
gigether-options { 
802.3ad ae1; 


} 
aeO { 
unit O { 
family inet { 
address 1.12.0.2/24, 
} 


family mpls; 


} 
aei { 
unit O { 
family inet { 
address 1.23.0.1/24; 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 10.255.102.102/32 { 
primary; 


[edit] 
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user@ABR# show protocols 
rsvp { 
interface all; 
} 
mpls { 
icmp-tunneling; 
label-switched-path r2-r0 { 
to 10.255.101.100; 
entropy-label; 
} 
label-switched-path r2-r4 { 
to 10.255.101.200; 
entropy-label; 
} 
interface all; 
} 
bgp { 
group ibgp { 
type internal; 
local-address 10.255.102.102; 
family inet { 
labeled-unicast { 
rib { 
inet.3; 


} 

neighbor 10.255.101.100 { 
export send-inet3-R4; 

} 

neighbor 10.255.101.200 { 
export send-inet3-RO; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface 100.0 { 
passive; 
} 
interface ge-0/0/2.0; 
interface ge-0/0/0.0; 
interface aeO.0; 
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interface fxp0.0 { 
disable; 


} 

area 0.0.0.1 { 
interface ge-0/0/3.0; 
interface ge-0/0/1.0; 
interface ae1.0; 


[edit] 
user@ABR# show routing-options 
router-id 10.255.102.102; 
autonomous-system 1; 
forwarding-table { 

export pplb; 


[edit] 
user@ABR# show forwarding-options 
hash-key { 
family mpls { 
label-1; 
label-2; 
label-3; 


} 
enhanced-hash-key { 
family mpls { 


no-payload; 


[edit] 
user@ABR# show policy-options 
policy-statement pplb { 
then { 
load-balance per-packet; 


} 
policy-statement send-inet3-RO { 
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from { 
route-filter 10.255.101.100/32 exact; 
} 


then accept; 


} 
policy-statement send-inet3-R4 { 
from { 
route-filter 10.255.101.200/32 exact; 
} 


then accept; 


Verification 


IN THIS SECTION 


@ Verifying That the Entropy Label Capability ls Being Advertised from Router PE2 | 556 
@ Verifying That Router ABR Receives the Entropy Label Advertisement | 557 
@ ~~ Verifying That the Entropy Label Flag Is Set | 559 


Confirm that the configuration is working properly. 


Verifying That the Entropy Label Capability Is Being Advertised from Router PE2 


Purpose 
Verify that the entropy label capability path attribute is being advertised from the upstream Router PE2 
at egress. 


Action 


From operational mode, run the show route 10.255.101.200 advertising-protocol bgp 10.255.102.102 
command on Router PE2. 





user@PE2> show route 10.255.101.200 advertising-protocol bgp 10.255.102.102 


inet.3: 2 destinations, 2 routes (2 active, 0 holddown, O hidden) 
= 10.255. 10 200/32 (il eierey, IL eiimaroybiavcrercl)) 
BGP group ibgp type Internal 

Route Label: 299920 

Nexthop: Self 


Flags: Nexthop Change 
MED: 2 

Localpref: 4294967294 
AS jowicing [by 2 





Entropy label capable 


Meaning 
The output shows that the host PE2 with the IP address of 10.255.101.200 has the entropy label capability. 
The host is advertising the entropy label capability to its BGP neighbors. 


Verifying That Router ABR Receives the Entropy Label Advertisement 


Purpose 
Verify that Router ABR receives the entropy label advertisement at ingress from Router PE2. 


Action 
From operational mode, run the show route 10.255.101.200 receiving-protocol bgp 10.255.101.200 
command on Router ABR. 


user@ABR> show route 10.255.101.200 receiving-protocol bgp 10.255.101.200 


inet.0: 63 destinations, 63 routes (63 active, 0 holddown, O hidden) 


inet.3: 2 destinations, 2 routes (2 active, 0 holddown, O hidden) 
1G). 255. Oi. LOO/32 (il Crates, IL elmovoibiaverexcl) 

Accepted 

Route Label: 299920 

Nescehlopre Oz So O2 ral Oe 

MED: 2 

Localpref: 4294967294 

MS jOmiclag I 





Entropy label capable 


VPN-l13vpn.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) 


iso.0: 2 destinations, 2 routes (2 active, 0 holddown, O hidden) 


mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) 


bgp.13vpn.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 


inet6.0: 7 destinations, 7 routes (7 active, 0 holddown, O hidden) 
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VPN-l13vpn.inet6.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 





user@PE1> show route protocol bgp detail 


inet.0: 64 destinations, 64 routes (64 active, 0 holddown, O hidden) 


inet.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 
Om 255-02 00) Search ry a leannolnced) 


BE Ge 


Preference: 170/1 
Next hop type: Indirect, Next hop index: 0 
Address: 0xa533c10 





Next-hop reference count: 2 

Sousees 10.255. 1M0Z 4 LOZ 

Next hop type: Router, Next hop index: 0 
Next hop: 1.1.0.2 via ge-0/0/1.0, selected 





Label-switched-path r0-r2 

Label operation: Push 299904, Push 300096 (top) 

Inaloeil WWI) EGELOMe force, jercMO—icicll (item) 

Load balance label: Label 299904: Entropy label; Label 300096: None; 
Label element ptr: 0xa5335a0 

Label parent element ptr: 0xa5338a0 


Label element references: 2 





Label element child references: 1 





Label element lsp id: 0 

Session Id: 0x0 

DEOL OCOMMmoxt enor OZ 55).hO2 02 
Label operation: Push 299904 
Label TTL action: prop-ttl 








Load balance label: Label 299904: Entropy label; 





Indirect next hop: 0xaal8540 - INH Session ID: 0x0 





State: <Active Int Ext> 

Local AS: 1 Peer AS: 1 

Age: 12:39 Metric: 2 Metric2: 2 

Validation State: unverified 

Haskeg WES 1, 10.255. 102.102 

Announcement bits (2): O-Resolve tr 1 3-Resolve_IGP_FRR task 





AS jOeNelag I 

Accepted 

Route Label: 299904 
Localpref: 4294967294 
Ropes IDs 10,255. 102. 102 


VPN-l13vpn.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) 
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Meaning 


Router ABR receives the entropy label capability advertisement from its BGP neighbor PE2. 


Verifying That the Entropy Label Flag Is Set 


Purpose 


Verify that the entropy label flag is set for the label elements at the ingress. 


Action 


From operational mode, run the show route protocol bgp detail command on Router PE1. 





user@PE1> show route protocol bgp detail 


inet.0: 64 destinations, 64 routes (64 active, 0 holddown, O hidden) 


inet.3: 2 destinations, 2 routes (2 active, 0 holddown, O hidden) 
10.255. 100.200/32 (1 entry, 1 announced) 

* BGP Preference: 170/1 
Next hop type: Indirect, Next hop index: 0 
Addesis:) Uxaossenp 





Next-hop reference count: 2 

Sommeee LO 2556 IMO-4 6 102 

Next hop type: Router, Next hop index: 0 
NExXthopee lle Om avltamge—0)/0/nOpselcebed 





Label-switched-path r0-r2 

Label operation: Push 299904, Push 300096 (top) 

Inaloeil WWI ACGELOME jorCeqicicll, joc m—icicill (item) 

Load balance label: Label 299904: Entropy label; Label 300096: None; 


Label element ptr: 0xa5335a0 





Label parent element ptr: 0xa5338a0 





Label element references: 2 


Label element child references: 1 





Label element lsp id: 0 

Session Id: 0x0 

PEOEO COM MexE NOP as OP 2 So Oe Oe 
Label operation: Push 299904 
Label TTL action: prop-ttl 








Load balance label: Label 299904: Entropy label; 





Indirect next hop: 0xaal8540 —- INH Session ID: 0x0 





State: <Active Int Ext> 
lWoOcalwAS: 1 Peer AS: als 
Age: 12:39 Metric: 2 Metric2: 2 


Validation State: unverified 
Tasks wee 1,10 .255. 102.102 
Announcement bits (2): O-Resolve tr 1 3-Resolve_IGP_FRR task 





AS@pate hier 
Accepted 
Route Label: 299904 
Localpref: 4294967294 
RowESr IDs 10.255. 102. 102 
VPN-l13vpn.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) 


Meaning 


An entropy label is enabled on Router PE1. The output shows that the entropy label is being used for the 
BGP labeled unicast to achieve end-to-end load balancing. 


Configuring Ultimate-Hop Popping for LSPs 


By default, RSVP-signaled LSPs use penultimate-hop popping (PHP). Figure 43 on page 560 illustrates a 
penultimate-hop popping LSP between Router PE1 and Router PE2. Router CE1 forwards a packet to its 
next hop (Router PE1), which is also the LSP ingress. Router PE1 pushes label 1 on the packet and forwards 
the labeled packet to Router P1. Router P1 completes the standard MPLS label swapping operation, 
swapping label 1 for label 2, and forwards the packet to Router P2. Since Router P2 is the penultimate-hop 
router for the LSP to Router PE2, it first pops the label and then forwards the packet to Router PE2. When 
Router PE2 receives it, the packet can have a service label, an explicit-null label, or just be a plain IP or 
VPLS packet. Router PE2 forwards the unlabeled packet to Router CE2. 


Figure 43: Penultimate-Hop Popping for an LSP 
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You can also configure ultimate-hop popping (UHP) (as shown in Figure 44 on page 561) for RSVP-signaled 
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LSPs. Some network applications can require that packets arrive at the egress router (Router PE2) with a 
non-null outer label. For an ultimate- hop popping LSP, the penultimate router (Router P2 in 

Figure 44 on page 561) performs the standard MPLS label swapping operation (in this example, label 2 for 
label 3 ) before forwarding the packet to egress Router PE2. Router PE2 pops the outer label and performs 
a second lookup of the packet address to determine the end destination. It then forwards the packet to 
the appropriate destination (either Router CE2 or Router CE4). 
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Figure 44: Ultimate-Hop Popping for an LSP 
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The following network applications require that you configure UHP LSPs: 


e MPLS-TP for performance monitoring and in-band OAM 
e Edge protection virtual circuits 


The following features do not support the UHP behavior: 


e LDP-signaled LSPs 

e Static LSPs 

e Point-to-multipoint LSPs 
e CCC 


e traceroute command 


For more information about UHP behavior, see Internet draft 
draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Non PHP behavior and Out-of-Band Mapping for RSVP-TE 
LSPs. 


For point-to-point RSVP-signaled LSPs, UHP behavior is signaled from the LSP ingress. Based on the 
ingress router configuration, RSVP can signal the UHP LSP with the non-PHP flag set. RSVP PATH messages 
carry the two flags in the LSP-ATTRIBUTES object. When the egress router receives the PATH message, 
it assigns a non-null label to the LSP. RSVP also creates and installs two routes in the mpls.O routing table. 
S refers to the S bit of the MPLS label, which indicates whether or not the bottom of the label stack has 
been reached. 


e Route S=O—Indicates that there are more labels in the stack. The next hop for this route points to the 
mpls.O routing table, triggering a chained MPLS label lookup to discover the remaining MPLS labels in 
the stack. 


e Route S=1—Indicates that there are no more labels. The next hop points to the inet.O routing table if 
the platform supports chained and multi-family lookup. Alternatively, the label route can point to a VT 
interface to initiate IP forwarding. 


If you enable UHP LSPs, MPLS applications such as Layer 3 VPNs, VPLS, Layer 2 VPNs, and Layer 2 circuits 
can use the UHP LSPs. The following explains how UHP LSPs affect the different types of MPLS applications: 


e Layer 2 VPNs and Layer 2 circuits—A packet arrives at the PE router (egress of the UHP LSP) with two 
labels. The outer label (S=O) is the UHP label, and the inner label (S=1) is the VC label. A lookup based 
on the transport label results in a table handle for the mpls.O routing table. There is an additional route 
in the mpls.O routing table corresponding to the inner label. A lookup based on the inner label results in 
the CE router next hop. 


e Layer 3 VPN—A packet arrives at the PE router (egress of the UHP LSP) with two labels. The outer label 
(S=0) is the UHP label, and the inner label is the VPN label (S=1). A lookup based on the transport label 
results in the table handle for the mpls.O routing table. There are two cases in this scenario. By default, 
Layer 3 VPNs advertise the per-next hop label. A lookup based on the inner label results in the next hop 
toward the CE router. However, if you have configured the vrf-table-label statement for the Layer 3 
VPN routing instance, the inner LSI label points to the VRF routing table. An IP lookup is also completed 
for the VRF routing table. 


NOTE: UHP for Layer 3 VPNs configured with the vrf-table-label statement is supported on 
MX Series 5G Universal Routing Platforms only. 


VPLS—A packet arrives at the PE router (egress of the UHP LSP) with two labels. The outer label is the 
transport label (S=O) and the inner label is the VPLS label (S=1). A lookup based on the transport label 
results in the table handle for the mpls.O routing table. A lookup based on the inner label in mpls.O routing 


table results in the LSI tunnel interface of the VPLS routing instance if tunnel-services is not configured 
(or a VT interface not available). MX 3D Series routers support chained lookup and multi-family lookup. 


NOTE: UHP for VPLS configured with the no-tunnel-service statement is supported on MX 
3D Series routers only. 


IPv4 over MPLS—A packet arrives at the PE router (egress of the UHP LSP) with one label (S=1). A lookup 
based on this label returns a VT tunnel interface. Another IP lookup is completed on the VT interface 


to determine where to forward the packet. If the routing platform supports multi-family and chained 
lookups (for example, MX 3D routers and PTX Series Packet Transport Routers), lookup based on label 
route (S=1) points to the inet.O routing table. 


IPv6 over MPLS—For IPvé6 tunneling over MPLS, PE routers advertise IPv6é routes to each other with a 


label value of 2. This is the explicit null label for IPv6. As a result, the forwarding next hops for IPvé 
routes that are learned from remote PE routers normally push two labels. The inner label is 2 (it could 
be different if the advertising PE router is from another vendor), and the router label is the LSP label. 
Packets arrive at the PE router (egress of the UHP LSP) with two labels. The outer label is the transport 
label (S=O), and the inner label is the IPv6 explicit-null label (label 2). Lookup based on the inner label in 
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the mpls.O routing table redirects back to the mpls.O routing table. On MX 3D Series routers, the inner 
label (label 2) is stripped off and an IPv6 lookup is done using the inet6.0 routing table. 


e Enabling both PHP and UHP LSPs—You can configure both PHP and UHP LSPs over the same network 
paths. You can separate PHP and UHP traffic by selecting forwarding LSP next hops using a regular 
expression with the install-nexthop statement. You can also separate traffic by simply naming the LSPs 
appropriately. 


The following statements enable ultimate-hop popping for an LSP. You can enable this feature on a specific 
LSP or for all of the ingress LSPs configured on the router. Configure these statements on the router at 
the LSP ingress. 


1. To enable ultimate-hop popping, include the ultimate-hop-popping statement: 


ultimate-hop-popping; 


Include this statement at the [edit protocols mpls label-switched-path label-switched-path-name] 
hierarchy level to enable ultimate-hop popping on a specific LSP. Include this statement at the [edit 
protocols mpls] hierarchy level to enable ultimate-hop popping on all of the ingress LSPs configured 
on the router. You can also configure the ultimate-hop-popping statement under the equivalent [edit 
logical-routers] hierarchy levels. 


NOTE: When you enable ultimate-hop popping, RSVP attempts to resignal existing LSPs as 
ultimate-hop popping LSPs in a make-before-break fashion. If an egress router does not 
support ultimate-hop popping, the existing LSP is torn down (RSVP sends a PathTear message 
along an LSP’s path, removing the path state and dependent reservation state and releasing 
the associated networking resources). 


If you disable ultimate-hop popping, RSVP resignals existing LSPs as penultimate-hop popping 
LSPs in a make-before-break fashion. 


2. If you want to enable both ultimate-hop-popping and chained next hops on MX 3D Series routers only, 
you also need to configure the enhanced-ip option for the network-services statement: 


network-services enhanced-ip; 


You configure this statement at the [edit chassis] hierarchy level. Once you have configured the 
network-services statement, you need to reboot the router to enable UHP behavior. 
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Configuring Explicit-Path LSPs 


If you disable constrained-path label-switched path (LSP) computation, as described in “Disabling 
Constrained-Path LSP Computation” on page 483, you can configure LSPs manually or allow the LSPs to 
follow the IGP path. 


When explicit-path LSPs are configured, the LSP is established along the path you specified. If the path is 
topologically not feasible, either because the network is partitioned or insufficient resources are available 
along some parts of the path, the LSP will fail. No alternative paths can be used. If the setup succeeds, the 
LSP stays on the defined path indefinitely. 


To configure an explicit-path LSP, follow these steps: 


1. Configure the path information in a named path, as described in “Creating Named Paths” on page 488. 
To configure complete path information, specify every router hop between the ingress and egress 
routers, preferably using the strict attribute. To configure incomplete path information, specify only a 
subset of router hops, using the loose attribute in places where the path is incomplete. 


For incomplete paths, the MPLS routers complete the path by querying the local routing table. This 
query is done ona hop-by-hop basis, and each router can figure out only enough information to reach 
the next explicit hop. It might be necessary to traverse a number of routers to reach the next (loose) 
explicit hop. 


Configuring incomplete path information creates portions of the path that depend on the current 
routing table, and this portion of the path can reroute itself as the topology changes. Therefore, an 
explicit-path LSP that contains incomplete path information is not completely fixed. These types of 
LSPs have only a limited ability to repair themselves, and they tend to create loops or flaps depending 
on the contents of the local routing table. 


2. To configure the LSP and point it to the named path, use either the primary or secondary statement, 
as described in “Configuring Primary and Secondary LSPs” on page 570. 


3. Disable constrained-path LSP computation by including the no-cspf statement either as part of the 
LSP or as part of a primary or secondary statement. For more information, see “Disabling 
Constrained-Path LSP Computation” on page 483. 


4. Configure any other LSP properties. 
Using explicit-path LSPs has the following drawbacks: 


e More configuration effort is required. 


e Configured path information cannot take into account dynamic network bandwidth reservation, so the 
LSPs tend to fail when resources become depleted. 


e When an explicit-path LSP fails, you might need to manually repair it. 


Because of these limitations, we recommend that you use explicit-path LSPs only in controlled situations, 
such as to enforce an optimized LSP placement strategy resulting from computations with an offline 
simulation software package. 


Example: Configuring an Explicit-Path LSP 


On the ingress router, create an explicit-path LSP, and specify the transit routers between the ingress and 
egress routers. In this configuration, no constrained-path computation is performed. For the primary path, 
all intermediate hops are strictly specified so that its route cannot change. The secondary path must travel 
through router 14.1.1.1 first, then take whatever route is available to reach the destination. The remaining 
route taken by the secondary path is typically the shortest path computed by the IGP. 


[edit] 
interfaces { 
so-0/0/0 { 
unit O { 
family mpls; 


} 
protocols { 
rsvp { 
interface so-0/0/0; 
} 
mpls { 
path to-hastings { 
14.1.1.1 strict; 
13.1.1.1 strict; 
12.1.1.1 strict; 
11.1.1.1 strict; 
} 
path alt-hastings { 
14.1.1.1 strict; 
11.1.1.1 loose; # Any IGP route is acceptable 
} 
label-switched-path hastings { 
to 11.1.1.1; 
hop-limit 32; 
bandwidth 10m; # Reserve 10 Mbps 
no-cspf; # do not perform constrained-path computation 
primary to-hastings; 
secondary alt-hastings; 
} 
interface so-0/0/0; 
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LSP Bandwidth Oversubscription Overview 


LSPs are established with bandwidth reservations configured for the maximum amount of traffic you 
expect to traverse the LSP. Not all LSPs carry the maximum amount of traffic over their links at all times. 
For example, even if the bandwidth for link A has been completely reserved, actual bandwidth might still 
be available but not currently in use. This excess bandwidth can be used by allowing other LSPs to also 
use link A, oversubscribing the link. You can oversubscribe the bandwidth configured for individual class 
types or specify a single value for all of the class types using an interface. 


You can use oversubscription to take advantage of the statistical nature of traffic patterns and to permit 
higher utilization of links. 


The following examples describe how you might use bandwidth oversubscription and undersubscription: 


e Use oversubscription on class types where peak periods of traffic do not coincide in time. 


e Use oversubscription of class types carrying best-effort traffic. You take the risk of temporarily delaying 
or dropping traffic in exchange for making better utilization of network resources. 


e Give different degrees of oversubscription or undersubscription of traffic for the different class types. 
For instance, you configure the subscription for classes of traffic as follows: 


e Best effort—ct0 1000 


e Voice—ct3 1 


When you undersubscribe a class type for a multiclass LSP, the total demand of all RSVP sessions is always 
less than the actual capacity of the class type. You can use undersubscription to limit the utilization of a 
class type. 


The bandwidth oversubscription calculation occurs on the local router only. Because no signaling or other 
interaction is required from other routers in the network, the feature can be enabled on individual routers 
without being enabled or available on other routers which might not support this feature. Neighboring 
routers do not need to know about the oversubscription calculation, they rely on the IGP. 


The following sections describe the types of bandwidth oversubscription available in the Junos OS: 


e LSP Size Oversubscription on page 567 
e LSP Link Size Oversubscription on page 567 


e Class Type Oversubscription and Local Oversubscription Multipliers on page 567 
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LSP Size Oversubscription 


For LSP size oversubscription, you simply configure less bandwidth than the peak rate expected for the 
LSP. You also might need to adjust the configuration for automatic policers. Automatic policers manage 
the traffic assigned to an LSP, ensuring that it does not exceed the configured bandwidth values. LSP size 
oversubscription requires that the LSP can exceed its configured bandwidth allocation. 


Policing is still possible. However, the policer must be manually configured to account for the maximum 
bandwidth planned for the LSP, rather than for the configured value. 


LSP Link Size Oversubscription 


You can increase the maximum reservable bandwidth on the link and use the inflated values for bandwidth 
accounting. Use the subscription statement to oversubscribe the link. The configured value is applied to 
all class type bandwidth allocations on the link. For more information about link size oversubscription, see 
“Configuring the Bandwidth Subscription Percentage for LSPs” on page 568. 


Class Type Oversubscription and Local Oversubscription Multipliers 


Local oversubscription multipliers (LOMs) allow different oversubscription values for different class types. 
LOMs are useful for networks where the oversubscription ratio needs to be configured differently on 
different links and where oversubscription values are required for different classes. You might use this 
feature to oversubscribe class types handling best-effort traffic, but use no oversubscription for class types 
handling voice traffic. An LOM is calculated locally on the router. No information related to an LOM is 
signaled to other routers in the network. 


An LOM is configurable on each link and for each class type. The per-class type LOM allows you to increase 
or decrease the oversubscription ratio. The per-class-type LOM is factored into all local bandwidth 
accounting for admission control and IGP advertisement of unreserved bandwidths. 


The LOM calculation is tied to the bandwidth model (MAM, extended MAM, and Russian dolls) used, 
because the effect of oversubscription across class types must be accounted for accurately. 


NOTE: All LOM calculations are performed by the Junos OS and require no user intervention. 
The formulas related to the oversubscription of class types are described in the following sections: 
e Class Type Bandwidth and the LOM 

e LOM Calculation for the MAM and Extended MAM Bandwidth Models 


e LOM Calculation for the Russian Dolls Bandwidth Model 


e Example: LOM Calculation 
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Configuring the Bandwidth Subscription Percentage for LSPs 


By default, RSVP allows all of a class type’s bandwidth (100 percent) to be used for RSVP reservations. 
When you oversubscribe a class type for a multiclass LSP, the aggregate demand of all RSVP sessions is 
allowed to exceed the actual capacity of the class type. 


If you want to oversubscribe or undersubscribe all of the class types on an interface using the same 
percentage bandwidth, configure the percentage using the subscription statement: 


subscription percentage; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section. 


To undersubscribe or oversubscribe the bandwidth for each class type, configure a percentage for each 
class type (ctO, ct1, ct2, and ct3) option for the subscription statement. When you oversubscribe a class 
type, an LOM is applied to calculate the actual bandwidth reserved. See “Class Type Oversubscription and 
Local Oversubscription Multipliers” on page 567 for more information. 


subscription { 
ctO percentage; 
ct1 percentage; 
ct2 percentage; 
ct3 percentage; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section. 


percentage is the percentage of class type bandwidth that RSVP allows to be used for reservations. It can 
be a value from O through 65,000 percent. If you specify a value greater than 100, you are oversubscribing 
the interface or class type. 


The value you configure when you oversubscribe a class type is a percentage of the class type bandwidth 
that can actually be used. The default subscription value is 100 percent. 


You can use the subscription statement to disable new RSVP sessions for one or more class types. If you 
configure a percentage of O, no new sessions (including those with zero bandwidth requirements) are 
permitted for the class type. 


Existing RSVP sessions are not affected by changing the subscription factor. To clear an existing session, 
issue the clear rsvp session command. For more information on the clear rsvp session command, see the 
CLI Explorer. 


Constraints on Configuring Bandwidth Subscription 


Be aware of the following issues when configuring bandwidth subscription: 
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e If you configure bandwidth constraints at the [edit class-of-service interface interface-name] hierarchy 
level, they override any bandwidth configuration you specify at the [edit protocols rsvp interface 
interface-name bandwidth] hierarchy level for Diffserv-TE. Also note that either of the CoS or RSVP 
bandwidth constraints can override the interface hardware bandwidth constraints. 


e If you configure a bandwidth subscription value for a specific interface that differs from the value 
configured for all interfaces (by including different values for the subscription statement at the [edit 
protocols rsvp interface interface-name] and [edit protocols rsvp interface all] hierarchy levels), the 
interface-specific value is used for that interface. 


e You can configure subscription for each class type only if you also configure a bandwidth model. If no 
bandwidth model is configured, the commit operation fails with the following error message: 


user@host# commit check 


[edit protocols rsvp interface all] 

"subscription' 
RSVP: Must have a diffserv-te bandwidth model configured when configuring 
subscription per traffic class. 


error: configuration check-out failed 


e You cannot include the subscription statement both in the configuration for a specific class type and 
the configuration for the entire interface. The commit operation fails with the following error message: 


user@host# commit check 


[edit protocols rsvp interface all] 
Usui sereipitesome 
RSVP: Cannot configure both link subscription and per traffic class 
subscription. 


error: configuration check-out failed 


Release History Table 
Release Description 
14.1R9 Starting in Junos OS Release 14.1R9, 15.1R7, 16.1R5, 16.1X2, 16.2R3, and 17.2R2, all zero value 
bandwidth samples are considered as underflow samples, except for the zero value samples that 


arrive after an LSP comes up for the first time, and the zero value samples that arrive first after 


a Routing Engine switchover. 
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By default, an LSP routes itself hop-by-hop toward the egress router. The LSP tends to follow the shortest 
path as dictated by the local routing table, usually taking the same path as destination-based, best-effort 
traffic. These paths are “soft” in nature because they automatically re-route themselves whenever a change 
occurs in a routing table or in the status of a node or link. 


To configure the path so that it follows a particular route, create a named path using the path statement, 
as described in “Creating Named Paths” on page 488. Then apply the named path by including the primary 
or secondary statement. A named path can be referenced by any number of LSPs. 


To configure primary and secondary paths for an LSP, complete the steps in the following sections: 
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Configuring Primary and Secondary Paths for an LSP 
The primary statement creates the primary path, which is the LSP’s preferred path. The secondary statement 


creates an alternative path. If the primary path can no longer reach the egress router, the alternative path 
is used. 


To configure primary and secondary paths, include the primary and secondary statements: 


primary path-name { 


} 


secondary path-name { 


You can include these statements at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


When the software switches from the primary to a secondary path, it continuously attempts to revert to 
the primary path, switching back to it when it is again reachable, but no sooner than the retry time specified 
in the retry-timer statement. (For more information, see “Configuring the Connection Between Ingress 
and Egress Routers” on page 493.) 


You can configure zero or one primary path. If you do not configure a primary path, the first secondary 
path that is established is selected as the path. 


You can configure zero or more secondary paths. All secondary paths are equal. The software does not 

attempt to switch among secondary paths. If the current secondary path is not available, the next one is 
tried in no particular order. To create a set of equal paths, specify secondary paths without specifying a 

primary path. 


If you do not specify any named paths, or if the path that you specify is empty, the software makes all 
routing decisions necessary to reach the egress router. 


Configuring the Revert Timer for LSPs 


For LSPs configured with both primary and secondary paths, it is possible to configure the revert timer. If 
a primary path goes down and traffic is switched to the secondary path, the revert timer specifies the 
amount of time (in seconds) that the LSP must wait before it can revert traffic back to a primary path. If 
during this time, the primary path experiences any connectivity problems or stability problems, the timer 
is restarted. You can configure the revert timer for both static and dynamic LSPs. 


The Junos OS also makes a determination as to which path is the preferred path. The preferred path is 
the path that has not encountered any difficulty in the last revert timer period. If both the primary and 
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secondary paths have encountered difficulty, neither path is considered preferred. However, if one of the 
paths is dynamic and the other static, the dynamic path is selected as the preferred path. 


If you have configured BFD on the LSP, Junos OS waits until the BFD session comes up on the primary 
path before starting the revert timer counter. 


The range of values you can configure for the revert timer is O through 65,535 seconds. The default value 
is 60 seconds. 


If you configure a value of O seconds, the traffic on the LSP, once switched from the primary path to the 
secondary path, remains on the secondary path permanently (until the network operator intervenes or 
until the secondary path goes down). 


You can configure the revert timer for all LSPs on the router at the [edit protocols mpls] hierarchy level 
or for a specific LSP at the [edit protocols mpls label-switched-path Isp-name] hierarchy level. 


To configure the revert timer, include the revert-timer statement: 


revert-timer seconds; 


For a list of hierarchy levels at which you can include this statement, see the summary section for this 
statement. 

Specifying the Conditions for Path Selection 

When you have configured both primary and secondary paths for an LSP, you may need to ensure that 
only a specific path is used. 

The select statement is optional. If you do not include it, MPLS uses an automatic path selection algorithm. 


The manual and unconditional options do the following: 


e manual—The path is immediately selected for carrying traffic as long as it is up and stable. Traffic is sent 
to other working paths if the current path is down or degraded (receiving errors). This parameter overrides 
all other path attributes except the select unconditional statement. 


e unconditional—The path is selected for carrying traffic unconditionally, regardless of whether the path 
is currently down or degraded (receiving errors). This parameter overrides all other path attributes. 


Because the unconditional option switches to a path without regard to its current status, be aware of 
the following potential consequences of specifying it: 


e If a pathis not currently up when you enable the unconditional option, traffic can be disrupted. Ensure 
that the path is functional before specifying the unconditional option. 


e Once a path is selected because it has the unconditional option enabled, all other paths for the LSP 
are gradually cleared, including the primary and standby paths. No path can act as a standby to an 
unconditional path, so signaling those paths serves no purpose. 


573 


For a specific path, the manual and unconditional options are mutually exclusive. You can include the 
select statement with the manual option in the configuration of only one of an LSP’s paths, and the select 
statement with the unconditional option in the configuration of only one other of its paths. 


Enabling or disabling the manual and unconditional options for the select statement while LSPs and their 
paths are up does not disrupt traffic. 


To specify that a path be selected for carrying traffic if it is up and stable for at least the revert timer 


window, include the select statement with the manual option: 


select manual; 


To specify that a path should always be selected for carrying traffic, even if it is currently down or degraded, 
include the select statement with the unconditional option: 


select unconditional; 


You can include the select statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name] 


Configuring Hot Standby of Secondary Paths for LSPs 


By default, secondary paths are set up only as needed. To have the system maintain a secondary path in 
a hot-standby state indefinitely, include the standby statement: 


standby; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name secondary] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name secondary] 


The hot-standby state is meaningful only on secondary paths. Maintaining a path in a hot-standby state 
enables swift cutover to the secondary path when downstream routers on the current active path indicate 
connectivity problems. Although it is possible to configure the standby statement at the [edit protocols 
mpls label-switched-path Isp-name primary path-name] hierarchy level, it has no effect on router behavior. 


If you configure the standby statement at the following hierarchy levels, the hot-standby state is activated 
on all secondary paths configured beneath that hierarchy level: 


574 


e [edit protocols mpls] 
e [edit protocols mpls label-switched-path Isp-name] 
e [edit logical-systems logical-system-name protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 
The hot-standby state has two advantages: 


e It eliminates the call-setup delay during network topology changes. Call setup can suffer from significant 
delays when network failures trigger large numbers of LSP reroutes at the same time. 


e Accutover to the secondary path can be made before RSVP learns that an LSP is down. There can be 
significant delays between the time the first failure is detected by protocol machinery (which can be an 
interface down, a neighbor becoming unreachable, a route becoming unreachable, or a transient routing 
loop being detected) and the time an LSP actually fails (which requires a timeout of soft state information 
between adjacent RSVP routers). When topology failures occur, hot-standby secondary paths can usually 
achieve the smallest cutover delays with minimal disruptions to user traffic. 


When the primary path is considered to be stable again, traffic is automatically switched from the standby 
secondary path back to the primary path. The switch is performed no faster than twice the retry-timer 
interval and only if the primary path exhibits stability throughout the entire switch interval. 


The drawback of the hot-standby state is that more state information must be maintained by all the routers 
along the path, which requires overhead from each of the routers. 


NOTE: When viewed with inet.3, the same LSP may appear to be shown twice as the active 
route (both primary and secondary), even though traffic actually is being forwarded over the 
primary path LSP only. This is normal output, and reflects only that the secondary standby path 
is available. 


Configuring Static LSPs 
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To configure static LSPs, configure the ingress router and each router along the path up to and including 
the egress router. 


To configure static MPLS, perform the following tasks: 


Configuring the Ingress Router for Static LSPs 


The ingress router checks the IP address in the incoming packet’s destination address field and, if it finds 
a match in the routing table, applies the label associated with that address to the packets. The label has 
forwarding information associated with it, including the address of the next-hop router, and the route 
preference and CoS values. 


To configure static LSPs on the ingress router, include the ingress statement: 


ingress { 
bandwidth bps; 
class-of-service cos-value; 
description string; 
install { 
destination-prefix <active>; 
} 
link-protection bypass-name name; 
metric metric; 
next-hop (address | interface-name | address/interface-name); 
no-install-to-address; 
node-protection bypass-name name next-next-label label; 
policing { 
filter filter-name; 
no-auto-policing; 
} 
preference preference; 
push out-label; 
to address; 


You can include these statements at the following hierarchy levels: 
e [edit protocols mpls static-label-switched-path static-Isp-name] 
e [edit logical-systems logical-system-name protocols mpls static-label-switched-path static-Isp-name] 


When you configure a static LSP on the ingress router, the next-hop, push, and to statements are required; 
the other statements are optional. 
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The configuration for a static LSP on the ingress router requires you to configure the following parts: 
e Criteria for analyzing an incoming packet: 


e The install statement creates an LSP that handles IPv4 packets. All static MPLS routes created using 
the install statement are installed in inet.3 routing table, and the creating protocol is identified as static. 
This process is no different from creating static IPv4 routes at the [edit routing-options static] hierarchy 
level. 


e Inthe to statement, you configure the IP destination address to check when incoming packets are 
analyzed. If the address matches, the specified outgoing label (push out-label) is assigned to the packet, 
and the packet enters an LSP. Manually assigned outgoing labels can have values from O through 
1,048,575. Each prefix that you specify is installed as a static route in the routing table. 


The next-hop statement, which supplies the IP address of the next hop to the destination. You can 
specify this as the IP address of the next hop, the interface name (for point-to-point interfaces only), or 
as address/interface-name to specify an IP address on an operational interface. When the next hop is 
on a directly attached interface, the route is installed in the routing table. You cannot configure a LAN 
or nonbroadcast multiaccess (NBMA) interface as a next-hop interface. 


Properties to apply to the LSP (all are optional): 


e Bandwidth reserved for this LSP (bandwidth bps) 


e Link protection and node protection to apply to the LSP (bypass bypass-name, link-protection 
bypass-name name, node-protection bypass-name next-next-label label) 


e Metric value to apply to the LSP (metric) 

e Class-of-service value to apply to the LSP (class-of-service) 
e Preference value to apply to the LSP (preference) 

e Traffic policing to apply to the LSP (policing) 

e Text description to apply to the LSP (description) 

e Install or no-install policy (install or no-install-to-address) 


To determine whether a static ingress route is installed, use the command show route table inet.3 protocol 
static. Sample output follows. The push keyword denotes that a label is to be added in front of an IP packet. 


OPO RIOR “[Stecie/5] OOsoileas 
> ico tigi, wie so-O0/O0/O, jousin LOOOILZS 


Example: Configuring the Ingress Router 


Configure the ingress router for a static LSP that consists of three routers (see Figure 45 on page 577). 
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Figure 45: Static MPLS Configuration 


Ingress Intermediate Egress 
router router router 


10.0.0.0 db 11.1.1.1 SIL) 12.2.2.2 Gil 13.3.3.3 
ao oa ar 


Label applied: 1000123 Label removed: 1000123 Label removed 
Label applied: 1000456 


For packets addressed to 10.0.0.0, assign label 1000123 and transmit them to the next-hop router at 
11.1.1.1: 


[edit] 
interfaces { 
so-0/0/0 { 
unit O { 
family mpls; 


} 
protocols { 
mpls { 
static-label-switched-path path1 { 
ingress { 

next-hop 11.1.1.1; 
to 10.0.0.0; 
push 1000123; 


} 
interface so-0/0/0.0; 


} 
routing-options { 
static { 
route 10.0.0.0/8 { 
static-lsp-next-hop path1; 


To determine whether the static ingress route is installed, use the following command: 


user@host> show route table inet.0 protocol static 
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Sample output follows. The push 1000123 keyword identifies the route. 


OR OROptOra8 =[Siraicie/S]| OOsOileas 
> co digi, vila so-O/0/0.0, smsia LOOOIAS 


Configuring the Intermediate (Transit) and Egress Routers for Static LSPs 


Intermediate (transit) and egress routers perform similar functions—they modify the label that has been 
applied to a packet. An intermediate router can change the label. An egress router removes the label (if 
the packet still contains a label) and continues forwarding the packet to its destination. 


To configure static LSPs on intermediate and egress routers, include the transit statement: 


static-label-switched-path Isp-name { 
transit incoming-label { 
bandwidth bps; 
description string; 
link-protection bypass-name name; 
next-hop (address | interface-name | address/interface-name), 
node-protection bypass-name name next-next-label label; 
pop, 
swap out-label; 


You can include these statements at the following hierarchy levels: 


e [edit protocols mpls static-label-switched-path static-Isp-name] 


e [edit logical-systems logical-system-name protocols mpls static-label-switched-path static-Isp-name] 


For the transit statement configuration, the next-hop and pop | swap statements are required. The remaining 
statements are optional. 


Each statement within the transit statement consists of the following parts: 


e Packet label (specified in the transit statement) 


e The next-hop statement, which supplies the IP address of the next hop to the destination. The address 
is specified as the IP address of the next hop, or the interface name (for point-to-point interfaces only), 
or address and interface-name to specify an IP address on an operational interface. When the specified 
next hop is ona directly attached interface, this route is installed in the routing table. You cannot configure 
a LAN or NBMA interface as a next-hop interface. 
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e Operation to perform on the labeled packet: 


e For egress routers, you generally just remove the packet’s label altogether (pop) and continue forwarding 
the packet to the next hop. However, if the previous router removed the label, the egress router 
examines the packet’s IP header and forwards the packet toward its IP destination. 


e For intermediate (transit) routers only, exchange the label for another label (swap out-label). Manually 
assigned incoming labels can have values from 1,000,000 through 1,048,575. Manually assigned 
outgoing labels can have values from O through 1,048,575. 


e Label properties to apply to the packet (all are optional): 


e Bandwidth reserved for this route (bandwidth bps). 


e Link-protection and node-protection to apply to the LSP (bypass bypass-name, link-protection 
bypass-name name, node-protection bypass-name next-next-label label). 


e Text description to apply to the LSP (specified in the description statement). 


The static routes are installed in the default MPLS routing table, mpls.0, and the creating protocol is 
identified as static. To verify that a static route is properly installed, use the command show route table 
mpls.0 protocol static. Sample output follows: 


MOORS S[SeseLe/ Si) OOsOOs Ss 
> tO 12,2.2,8 Via SO-5/0/0.0, swe LdO0aS6 


You can configure a revert timer for a static LSP transiting an intermediate router. After traffic has been 
switched to a bypass static LSP, it is typically switched back to the primary static LSP when it comes back 
up. There is a configurable delay in the time (called the revert timer) between when the primary static LSP 
comes up and when traffic is reverted back to it from the bypass static LSP. This delay is needed because 
when the primary LSP comes back up, it is not certain whether all of the interfaces on the downstream 
node of the primary path have come up yet. You can display the revert timer value for an interface using 
the show mpls interface detail command. For more information, see “Configuring the Revert Timer for 
LSPs” on page 571. 


Example: Configuring an Intermediate Router 


For packets labeled 1000123 arriving on interface so-0/0/0, assign the label 1000456, and transmit them 
to the next-hop router at 12.2.2.2: 


[edit] 
interfaces { 
so-0/0/0 { 
unit O { 
family mpls; 
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} 
protocols { 
mpls { 
static-label-switched-path path1 { 
transit 1000123 { 
next-hop 12.2.2.2; 
swap 1000456; 


} 
interface so-0/0/0.0; 


To determine whether the static intermediate route is installed, use the following command: 


user@host> show route table mpls.0 protocol static 


Sample output follows. The swap 1000456 keyword identifies the route. 


OOO MEAS: “(Stacie / Si) OOcOils4e 
Se POmlZ nner O00) Ops wapmaO OO 4 SiG 


Example: Configuring an Egress Router 


For packets labeled 1000456 arriving on interface so-0/0/0, remove the label and transmit the packets 
to the next-hop router at 13.3.3.3: 


[edit] 
interfaces { 
so-0/0/0 { 
unit O { 
family mpls; 


} 
protocols { 
mpls { 
static-label-switched-path path1 { 
transit 1000456 { 
next-hop 13.3.3.3; 
pop, 
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} 
interface so-0/0/0.0; 


To determine whether the static egress route is installed, use the following command: 


user@host> show route table mpls.0 protocol static 


Sample output follows. The pop keyword identifies the egress route. 


1000456 “[Sicacie/ 5] OOsOlsas 
> t© 13,3335,3 Wia so-0/0/0, pos 


Configuring a Bypass LSP for the Static LSP 
To enable a bypass LSP for the static LSP, configure the bypass statement: 


bypass bypass-name { 
bandwidth bps; 
description string; 
next-hop (address | interface-name | address/interface-name); 
push out-label; 
to address; 


Configuring the Protection Revert Timer for Static LSPs 


For static LSPs configured with a bypass static LSP, it is possible to configure the protection revert timer. 
If a static LSP goes down and traffic is switched to the bypass LSP, the protection revert timer specifies 
the amount of time (in seconds) that the LSP must wait before it can revert back to the original static LSP. 


The range of values you can configure for the protection revert timer is O through 65,535 seconds. The 
default value is 5 seconds. 


If you configure a value of O seconds, the traffic on the LSP, once switched from the original static LSP to 
the bypass static LSP, remains on the bypass LSP permanently (until the network operator intervenes or 
until the bypass LSP goes down). 


You can configure the protection revert timer for all LSPs on the router at the [edit protocols mpls] hierarchy 
level or for a specific LSP at the [edit protocols mpls label-switched-path Isp-name] hierarchy level. 
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To configure the protection revert timer for static LSPs include the protection-revert-time statement: 


protection-revert-time seconds; 
For a list of hierarchy levels at which you can include this statement, see the summary section for this 
statement. 


Configuring Static Unicast Routes for Point-to-Multipoint LSPs 


You can configure a static unicast IP route with a point-to-multipoint LSP as the next hop. For more 
information about point-to-multipoint LSPs, see “Point-to-Multipoint LSPs Overview” on page 657, 
“Configuring Primary and Branch LSPs for Point-to-Multipoint LSPs” on page 686, and “Configuring CCC 
Switching for Point-to-Multipoint LSPs” on page 1345. 


To configure a static unicast route for a point-to-multipoint LSP, complete the following steps: 


1. On the ingress PE router, configure a static IP unicast route with the point-to-multipoint LSP name as 
the next hop by including the p2mp-Isp-next-hop statement: 


p2mp-Isp-next-hop point-to-multipoint-Isp-next-hop; 


You can include this statement at the following hierarchy levels: 


e [edit routing-options static route route-name] 
e [edit logical-systems logical-system-name routing-options static route route-name] 

2. Onthe egress PE router, configure a static IP unicast route with the same destination address configured 
in Step 1 (the address configured at the [edit routing-options static route] hierarchy level) by including 
the next-hop statement: 


next-hop address; 


You can include this statement at the following hierarchy levels: 


e [edit routing-options static route route-name] 


e [edit logical-systems logical-system-name routing-options static route route-name] 


NOTE: CCC and static routes cannot use the same point-to-multipoint LSP. 


For more information on static routes, see the Junos OS Routing Protocols Library. 


The following show route command output displays a unicast static route pointing to a point-to-multipoint 
LSP on the ingress PE router where the LSP has two branch next hops: 


user@host> show route 5.5.5.5 detail 


inet.0: 29 destinations, 30 routes (28 active, 0 holddown, 1 hidden) 
Seno 2a Glentiay aeleeaimnmoumne ec) 
*Static Preference: 5 
Next hop type: Flood 
Next hop: via so-0/3/2.0 weight 1 
Label operation: Push 100000 
Next hop: via t1-0/1/1.0 weight 1 
Label operation: Push 100064 
State: <Active Int Ext> 
Local AS: 10458 
Age: 2:41:15 
Weagsleg IRL 
Announcement bits (2): O-KRT 3-BGP.0.0.0.0+179 
AMS jOenclag I 








Configuring Static Label Switched Paths for MPLS (CLI Procedure) 


Configuring static label-switched paths (LSPs) for MPLS is similar to configuring static routes on individual 
switches. As with static routes, there is no error reporting, liveliness detection, or statistics reporting. 


To configure static LSPs, configure the ingress switch and each provider switch along the path up to and 
including the egress switch. 


For the ingress switch, configure which packets to tag (based on the packet’s destination IP address), 
configure the next switch in the LSP, and the tag to apply to the packet. Manually assigned labels can have 
values from O through 1,048,575. Optionally, you can apply preference, class-of-service (CoS) values, node 
protection, and link protection to the packets. 


For the transit switches in the path, configure the next switch in the path and the tag to apply to the packet. 
Manually assigned labels can have values from 1,000,000 through 1,048,575. Optionally, you can apply 
node protection and link protection to the packets. 


For the egress switch, you generally just remove the label and continue forwarding the packet to the IP 
destination. However, if the previous switch removed the label, the egress switch examines the packet's 
IP header and forwards the packet toward its IP destination. 


Before you configure an LSP, you must configure the basic components for an MPLS network: 


e Configure two PE switches. See “Configuring MPLS on Provider Edge EX8200 and EX4500 Switches 
Using Circuit Cross-Connect” on page 74. 


583 


584 


e Configure one or more provider switches. See “Configuring MPLS on EX8200 and EX4500 Provider 


Switches” on page 78. 


This topic describes how to configure an ingress PE switch, one or more provider switches, and an egress 
PE switch for static LSP: 


1. 


2; 


Configuring the Ingress PE Switch | 584 
Configuring the Provider and the Egress PE Switch | 585 


Configuring the Ingress PE Switch 


To configure the ingress PE switch: 


1. 


Configure an IP address for the core interfaces: 


[edit] 
user@switch# set interfaces interface-name unit logical-unit-number family inet address address 


user@switch# set interfaces interface-name unit logical-unit-number family inet address address 


. Configure the name and the traffic rate associated with the LSP: 


[edit] 


user@switch# set protocols mpls static-label-switched-path Isp-name ingress bandwidth rate 


. Configure the next hop switch for the LSP: 


[edit] 
user@switch# set protocols mpls static-label-switched-path Isp-name ingress next-hop 


address-of-next-hop 


. Enable link protection on the specified static LSP: 


[edit] 
user@switch# set protocols mpls static-label-switched-path Isp-name ingress link-protection 


bypass-name name 


. Specify the address of the egress switch for the LSP: 


[edit] 


user@switch# set protocols mpls static-label-switched-path path1 ingress to address-of-egress-switch 


. Configure the new label that you want to add to the top of the label stack: 


[edit] 
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user@switch# set protocols mpls static-label-switched-path path1 ingress push out-label 


7. Optionally, configure the next hop address and the egress router address that you want to bypass, for 
the static LSP: 


[edit] 





user@switch# set protocols mpls static-label-switched-path Isp-name by bypass next-hop 


address-of-next-hop 





user@switch# set protocols mpls static-label-switched-path Isp-name by bypass to 


address-of-the-egress-switch 











user@switch# set protocols mpls static-label-switched-path Isp-name bypass push out-label 
Configuring the Provider and the Egress PE Switch 


To configure a static LSP for MPLS on the provider and egress provider edge switch: 


1. Configure a transit static LSP: 


[edit] 
user@switch# set protocols mpls static-label-switched-path path1 transit incoming-label 


2. Configure the next hop switch for the LSP: 


[edit] 
user@switch# set protocols mpls static-label-switched-path Isp-name transit incoming-label next-hop 














address-of-next-hop 


3. Only for provider switches, remove the label at the top of the label stack and replace it with the specified 
label: 


[edit] 
user@switch# set protocols mpls static-label-switched-path Isp-name transit incoming-label swap 


out-label 


4. Only for the egress provider edge switch, remove the label at the top of the label stack: 


NOTE: If there is another label in the stack, that label becomes the label at the top of the 
label stack. Otherwise, the packet is forwarded as a native protocol packet (typically, as an 
IP packet). 


[edit] 
user@switch# set protocols mpls static-label-switched-path Isp-name transit incoming-label pop 
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Configuring Static Label Switched Paths for MPLS 


Configuring static label-switched paths (LSPs) for MPLS is similar to configuring static routes on individual 
switches. As with static routes, there is no error reporting, liveliness detection, or statistics reporting. 


To configure static LSPs, configure the ingress PE switch and each provider switch along the path up to 
and including the egress PE switch. 


For the ingress PE switch, configure which packets to tag (based on the packet’s destination IP address), 
configure the next switch in the LSP, and the tag to apply to the packet. Manually assigned labels can have 
values from O through 1,048,575. 


For the transit switches in the path, configure the next switch in the path and the tag to apply to the packet. 
Manually assigned labels can have values from 1,000,000 through 1,048,575. 


The egress PE switch removes the label and forwards the packet to the IP destination. However, if the 
previous switch removed the label, the egress switch examines the packet's IP header and forwards the 
packet toward its IP destination. 


Before you configure a static LSP, you must configure the basic components for an MPLS network: 


e Configure two PE switches. See “Configuring MPLS on Provider Edge Switches” on page 64. 


NOTE: Do not configure LSPs at the [edit protocols mpls label-switched-path] hierarchy level 
on the PE switches. 


e Configure one or more provider switches. See “Configuring MPLS on Provider Switches” on page 63. 


This topic describes how to configure an ingress PE switch, one or more provider switches, and an egress 
PE switch for static LSP: 


1. Configuring the Ingress PE Switch | 587 
2. Configuring the Provider and the Egress PE Switch | 587 
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Configuring the Ingress PE Switch 


To configure the ingress PE switch: 


1. Configure an IP address for every core interface: 


[edit interfaces] 


user@switch# set interface-name unit logical-unit-number family inet address address 


NOTE: You cannot use routed VLAN interfaces (RVIs) or Layer 3 subinterfaces as core 


interfaces. 


. Configure the name associated with the static LSP: 


[edit protocols mpls] 
user@switch# set static-label-switched-path Isp-name 


. Configure the next hop switch for the LSP: 


[edit protocols mpls] 
user@switch# set static-label-switched-path Isp-name ingress next-hop address-of-next-hop 


. Specify the address of the egress switch for the LSP: 


[edit protocols mpls] 
user@switch# set static-label-switched-path Isp-name ingress to address-of-egress-switch 


. Configure the new label that you want to add to the top of the label stack: 


[edit protocols mpls] 
user@switch# set static-label-switched-path Isp-name ingress push out-label 


Configuring the Provider and the Egress PE Switch 


To configure a static LSP for MPLS on the provider and egress PE switch: 


1. 


Configure a transit static LSP: 


[edit protocols mpls] 
user@switch# set static-label-switched-path Isp-name transit incoming-label 


. Configure the next hop switch for the LSP: 


[edit protocols mpls] 
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user@switch# set static-label-switched-path Isp-name transit incoming-label next-hop 


address-of-next-hop 


3. Only for provider switches, remove the label at the top of the label stack and replace it with the specified 
label: 


[edit protocols mpls] 


user@switch# set static-label-switched-path Isp-name transit incoming-label swap out-label 


4. Only for the egress PE switch, remove the label at the top of the label stack: 


NOTE: If there is another label in the stack, that label becomes the label at the top of the 
label stack. Otherwise, the packet is forwarded as a native protocol packet (typically, as an 
IP packet). 


[edit protocols mpls] 


user@switch# set static-label-switched-path Isp-name transit incoming-label pop 


RELATED DOCUMENTATION 
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Adaptive LSP Configuration 


An LSP occasionally might need to reroute itself for these reasons: 


e The continuous reoptimization process is configured with the optimize-timer statement. 
e The current path has connectivity problems. 
e The LSP is preempted by another LSP configured with the priority statement and is forced to reroute. 


e The explicit-path information for an active LSP is modified, or the LSP’s bandwidth is increased. 


You can configure an LSP to be adaptive when it is attempting to reroute itself. When it is adaptive, the 
LSP holds onto existing resources until the new path is successfully established and traffic has been cut 
over to the new LSP. To retain its resources, an adaptive LSP does the following: 


e Maintains existing paths and allocated bandwidths—This ensures that the existing path is not torn down 
prematurely and allows the current traffic to continue flowing while the new path is being set up. 
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e Avoids double-counting for links that share the new and old paths—Double-counting occurs when an 
intermediate router does not recognize that the new and old paths belong to the same LSP and counts 
them as two separate LSPs, requiring separate bandwidth allocations. If some links are close to saturation, 
double-counting might cause the setup of the new path to fail. 


By default, adaptive behavior is disabled. You can include the adaptive statement in two different hierarchy 
levels. 


If you specify the adaptive statement at the LSP hierarchy levels, the adaptive behavior is enabled on all 
primary/secondary paths of the LSP. This means both the primary and secondary paths share the same 
bandwidth on common links. 


To configure adaptive behavior for all LSP paths, include the adaptive statement in the LSP configuration: 


adaptive; 


You can include this statement at the following hierarchy levels: 
e [edit protocols mpls label-switched-path Isp-name] 
e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


If you specify the adaptive statement at the [edit protocols mpls label-switched-path Isp-name (primary 
| secondary) path-name] hierarchy level, adaptive behavior is enabled only on the path on which it is 
specified. Bandwidth double-counting occurs between different paths. However, if you also have the 
adaptive statement configured at the [edit protocols mpls label-switched-path Isp-name] hierarchy level, 
it overrides the adaptive behavior of each individual path. 


To configure adaptive behavior for either the primary or secondary level, include the adaptive statement: 


adaptive; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name] 
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Dynamic Bandwidth Management Using Container LSP Overview 


IN THIS SECTION 


Understanding RSVP Multipath Extensions | 590 

Junos OS RSVP Multipath Implementation | 591 

Current Traffic Engineering Challenges | 592 

Using Container LSP as a Solution | 595 

Junos OS Container LSP Implementation | 597 

Configuration Statements Supported for Container LSPs | 614 


Impact of Configuring Container LSPs on Network Performance | 618 


Supported and Unsupported Features | 619 


RSVP LSPs with the autobandwidth feature are increasingly deployed in networks to meet traffic engineering 
needs. However, the current traffic engineering solutions for point-to-point LSPs are inefficient in terms 
of network bandwidth utilization, mainly because the ingress routers originating the RSVP LSPs either try 
to fit the LSPs along a particular path without creating parallel LSPs, or do not interact with the other 
routers in the network and probe for additional available bandwidth. 


This feature provides an ingress router with the capability of acquiring as much network bandwidth as 
possible by creating parallel LSPs dynamically. 


Understanding RSVP Multipath Extensions 


The RSVP multipath extensions proposed in the IETF [KOMPELLA-MLSP] allow the setup of traffic 
engineered multipath label-switched paths (container LSPs). The container LSPs, in addition to conforming 
to traffic engineering constraints, use multiple independent paths from a source to a destination, thereby 
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facilitating load balancing of traffic. The multipath extensions require changes to the RSVP-TE protocol 
and allow for merging of labels at the downstream nodes (similar to LDP), which also helps in preserving 
forwarding resources. 


The multipath extensions to RSVP provide the following benefits: 


Ease of configuration. Typically, multiple RSVP LSPs are configured for either load balancing or bin 
packing. With a container LSP, there is a single entity to provision, manage, and monitor LSPs. Changes 
in topology are handled easily and autonomously by the ingress LSP, by adding, changing, or removing 
member LSPs to rebalance traffic, while maintaining the same traffic engineering constraints. 


RSVP equal-cost multipath (ECMP) inherits the standard benefits of ECMP by absorbing traffic surges. 


Multipath traffic engineering allows for better and complete usage of network resources. 


Knowing the relationship among LSPs helps in computing diverse paths with constraint-based routing. 


It allows adjustment of member LSPs while other member LSPs continue to carry traffic. 


The intermediate routers have an opportunity to merge the labels of member LSPs. This reduces the 


number of labels that need to get added to the forwarding plane and in turn reduces the convergence 
time. 


If the number of independent ECMP paths is huge, label merging overcomes the platform limitations on 
maximum (ECMP) next hops. With point-to-point RSVP LSPs that require link or node protection, the 
next hops are doubled as each LSP is programmed with both primary and backup next hops. RSVP 
multipath (or ECMP) obviates the need for backup next hops. 


When there is a link failure, the router upstream to the link failure can distribute traffic from the failed 
link to the remaining ECMP branches, obviating the need for bypass LSPs. The bypass LSP approach not 
only requires more state when signaling backup LSPs, but also suffers from scaling issues that result in 
merge-point timing out a protected path state block (PSB) before point of local repair (PLR) gets a chance 
to signal the backup LSP. 


Junos OS RSVP Multipath Implementation 


In order to deploy RSVP multipath (ECMP) in a network, all the nodes through which ECMP LSPs pass 
must understand RSVP ECMP protocol extensions. This can be a challenge, especially in a multivendor 
networks. 


Junos OS implements the RSVP multipath extensions without the need for protocol extensions. A single 
container LSP, which has the characteristics of ECMP and RSVP TE, is provisioned. A container LSP consists 
of several member LSPs and is set up between the ingress and egress routing device. Each member LSP 
takes a different path to the same destination. The ingress routing device is configured with all the required 
parameters to compute the RSVP ECMP LSP. The parameters configured to compute a set of RSVP 
point-to-point LSPs can be used by the ingress routing device to compute the container LSP as well. 
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Current Traffic Engineering Challenges 


The main challenge for traffic engineering is to cope with the dynamics of both topology and traffic 
demands. Mechanisms are needed that can handle traffic load dynamics in scenarios with sudden changes 
in traffic demand and dynamically distribute traffic to benefit form available resources. 


Figure 46 on page 592 illustrates a sample network topology with all the LSPs having the same hold and 
setup priorities, and admission control restricted on the ingress router. All the links are annotated with a 
tuple (cost and capacity). 


Figure 46: Sample Topology 


A 


ae C=1, B=10bps 
C=1, B=5bps 
- =~ @}: 
ae C=1, B=10bps C=1, B=10bps & C=1, B=10bps 


B D 


C Cost 
B_ Bandwidth in bits per second (bps) 


g042458 


593 


Some of the traffic engineering problems seen in Figure 46 on page 592 are listed here: 


e Bin Packing 


This problem arises because of a particular order in which LSPs are signaled. The ingress routers might 
not be able to signal some LSPs with required demands although bandwidth is available in the network, 
leading to under-utilization of link capacity. 


For example, the following LSPs arrive in the sequence mentioned in Table 15 on page 593. 


Table 15: LSP Sequence Order for Bin Packing 


Time Source Destination Demand ERO 
1 A E 5 A-C-D-E 
2 B E 10 No ERO 


The LSP originating at Router B is not routable as constraint-based routing fails to find a feasible path. 
However, if Router B is signaled first, both the LSPs are routable. Bin packing happens because of lack 
of visibility of individual per-LSP, per-device bandwidth demands at the ingress routing device. 


Bin packing can also happen when there is no requirement for ordering of LSPs. For example, if there is 
an LSP with demand X and there are two different paths to the destination from the ingress router with 
available bandwidths Y1 and Y2, such that Y11 is less than X, Y2 is less than X, and Y1 plus Y2 is greater 
than or equal to X. 


In this case, even though there are enough network resources in terms of available bandwidth to satisfy 
the aggregate LSP demand X, the LSP might not be signaled or re-optimized with the new demand. In 
Figure 46 on page 592, with container LSP support, the ingress B creates two LSPs each of size 5 when 
demand 10 is posed. One LSP is routed along B-C-E and another one along B-C-D-E. 


Deadlock 


Considering Figure 46 on page 592, the LSPs follow the sequence mentioned in Table 16 on page 593. 
Table 16: LSP Sequence Order for Deadlock 


Time Source Destination Demand ERO Event 

1 A E 2 A-C-D-E Constraint-based routing with RSVP 
signaling 

2 B E 2 B-C-D-E Constraint-based routing with RSVP 
signaling 

3 A E 2 to 20 A-C-D-E Constraint-based routing fails, no RSVP 


signaling 
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At time 3, the demand on LSP from A to E increases from 2 to 20. If autobandwidth is configured, the 
change does not get detected until the adjustment timer expires. In the absence of admission control at 
A, the increased traffic demand might cause traffic to drop on other LSPs that share common links with 
the mis-behaving LSP. 


This happens due to the following reasons: 


e Lack of global state at all the ingress routers 
e Signaling of mis-behaving demands 


e Tearing down of mis-behaving demands 


With container LSP configured, ingress A has more chances of splitting the load (even incrementally if 
not fully) across multiple LSPs. So, LSP from A is less likely to see prolonged traffic loss. 


Latency Inflation 


Latency inflation is caused by the autobandwidth and other LSPs parameters. Some of the other factors 
that contribute to latency inflation include: 


e LSP priority 


LSPs choose longer paths because shorter paths between data centers located in the same city can 
be congested. The bandwidth on the shorter paths can get exhausted by equal or higher priority LSPs. 
Due to periodic LSP optimization by autobandwidth, LSP can get rerouted to a higher delay path. 
When many LSPs undergo less than optimal path selection, they can potentially form a chain of 
dependencies. Modifing the LSP priorities dynamically is a workaround to the issue; however, 
dynamically adjusting LSP priorities to find shorter paths is a challenging task. 


e All or Nothing policy 


When the demand on an LSP increases and at least one of the links along the shorter path is close to 
its reservation limit, LSP optimization can force the LSP to move to a longer latency path. LSP has to 
traverse a long path even though the short path is capable of carrying most of the traffic. 


Minimum and maximum bandwidth 


Minimum and maximum bandwidth specify the boundaries for LSP sizes. If minimum bandwidth is 
small, an LSP is more prone to autobandwidth adjustment because a small change in bandwidth is 
enough to cross the threshold limits. LSPs might reroute although bandwidth is available. On the other 
hand, if the minimum bandwidth is large, network bandwidth might be wasted. If the maximum 
bandwidth value is small, a large number of LSPs might be needed at the ingress router to accommodate 
the application demand. If the maximum bandwidth is large, the LSPs can grow larger in size. Such 
LSPs can suffer because of an all or nothing policy. 


Autobandwidth adjustment threshold 


Bandwidth threshold dictates if LSPs need to be re-optimized and resized. If the value is small, LSPs 
are frequently re-optimized and rerouted. That might cause CPU spike because applications or protocols, 
such as BGP resolving over the LSPs, might keep the Routing Engine busy doing next-hop resolution. 
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A large value might make an LSP immobile. With container LSP configured, an LSP is less likely to get 
subjected to one or no policy. An ingress router originates multiple LSPs, although not all LSPs potentially 
traverse high latency paths. 


e Predictability 


Service providers often want predictable behavior in terms of how LSPs get signaled and routed. Currently, 
without any global coordination, it is difficult to set up the same set of LSPs in a predictable way. Consider 
the two different orderings in Table 17 on page 595 and Table 18 on page 595. The ERO that an LSP uses 
depends on its signaling time. 


Table 17: LSP Sequence Order for Predictability 


Time Source Destination Demand ERO 
1 A E 5 A-C-D-E 
2 B E 5 B-C-E 


Table 18: LSP Sequence Order for Predictability 


Time Source Destination Demand ERO 
1 B E 5 B-C-E 
2 A E 5 A-C-D-E 


Container LSP does not directly help LSPs find predictable EROs. If LSPs are getting rerouted because of 
an all or no policy without container LSP configured, such LSPs might see less churn if container LSPs are 
configured, because smaller LSPs have better chances of finding a shorter or same path. 


Using Container LSP as a Solution 


IN THIS SECTION 


Accommodating the New Demand X | 596 
Creating New LSPs to Meet Demand X | 596 
Assigning Bandwidth to the New LSPs | 596 


Controlling the LSP Paths | 596 


Accontainer LSP can be used as a solution to the challenges faced by the current traffic engineering features. 
Considering Figure 46 on page 592, when the demand X ona container LSP increases with the network 
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capacity (max-flow) being more than the demand, the following approaches come into effect with a 
container LSP: 


Accommodating the New Demand X 


In the current implementation, autobandwidth attempts to re-signal an LSP with the new demand X and 
follows the all or nothing policy as mentioned earlier. 


The container LSP approach computes several small (smaller than demand X) bandwidth LSPs such that 
the aggregate bandwidth is not less than X, and the ingress router performs this adjustment periodically. 
One of the triggers to create new LSPs or to delete old LSPs can be changed in aggregate bandwidth. The 
ingress router then load-balances the incoming traffic across the newly created LSPs. 


Creating New LSPs to Meet Demand X 


Although the number of new LSPs created can be a maximum of the allowed configurable limit, there is 
not much benefit from these LSPs once the number of LSPs exceeds the number of possible diverse paths 
or equal-cost multipaths (ECMPs). The benefit of creating the smaller LSPs is seen when an ingress router 
uses the newly created LSPs for load-balancing traffic. This, however, depends on the network topology 
and state. 


Creating multiple parallel LSPs by all the ingress routers in the network can lead to scaling issues at the 
transit routers. Thus, the number of new LSPs to be created depends on the size of the individual LSPs 
and the given aggregate demand, X in this case. 


Assigning Bandwidth to the New LSPs 


In general, there can be anumber of heuristics to allocate bandwidths to the newly created LSPs. An ingress 
router can solve an optimization problem in which it can maximize a given utility function. The output of 
an optimization problem is assigning optimal bandwidth values. However, to solve an optimization problem, 
the number of newly created LSPs has to be fixed. Therefore, it is complex to optimize the number and 
size of each LSP. Thus, to simplify the problem, the same amount of bandwidth is assumed for all the newly 
created LSPs, and then the number of required LSPs is computed. 


Controlling the LSP Paths 


The flexibility to control the LSP paths is expressed in terms of the configuration for point-to-point LSPs 
and container LSPs. Controlling the LSP paths using the configuration parameters can be applied under 
two different aspects: 


e Topology—There are no topology constraints with this feature. Each member LSP is treated like a 
point-to-point LSP and is re-optimized individually. An ingress router does not try to compute equal IGP 
cost paths for all its LSPs, but instead it computes paths for all the LSPs using current traffic engineering 
database information. While computing a path, constraint-based routing adheres to any constraints 
specified through the configuration, although there is no change in the constraint-based routing method 
for path computation. 


e When to create a new LSP—When to create a new LSP can be explicitly specified. By default, an ingress 
router periodically computes the aggregate traffic rate by adding up the traffic rate of all the individual 
LSPs. Looking at the aggregate bandwidth and configuration, the ingress router recomputes the number 


of LSPs and the bandwidths of the LSPs. The new LSPs are then signaled or the existing LSPs are 
re-signaled with the updated bandwidth. Instead of looking at the instantaneous aggregate rate, the 
ingress routers can compute an average (of aggregates) over some duration by removing outlier samples 
(of aggregates). Managing the LSPs that remain outstanding and active by considering aggregate bandwidth 
is more scalable than creating the new LSPs based on the usage of a particular LSP. The intervals and 
thresholds can be configured to track the aggregate traffic and trigger adjustment. These dynamic LSPs 
co-exist and interoperate with per-LSP autobandwidth configuration. 


Junos OS Container LSP Implementation 


IN THIS SECTION 


Container LSP Terminology | 597 

LSP Splitting | 598 

LSP Merging | 601 

Node and Link Protection | 602 

Naming Convention | 603 

Normalization | 603 

Constraint-Based Routing Path Computation | 609 
Sampling | 610 


Support for NSR, IPG-FA, and Static Routes | 610 


A container LSP is an ECMP TE LSP that acts like a container LSP consisting of one or more member LSPs. 
A point-to-point TE LSP is equivalent to a container LSP with a single member LSP. Member LSPs are 
added to the container LSP through a process called splitting, and removed from the container LSP through 
a process called merging. 


Container LSP Terminology 


The following terms are defined in the context of a container LSP: 


e Normalization—An event occurring periodically when an action is taken to adjust the member LSPs, 
either to adjust their bandwidths, their number, or both. A normalization process is associated with a 
sampling process and periodically estimates aggregate utilization of a container LSP. 


e Nominal LSP—The instance of a container LSP that is always present. 


e Supplementary LSP—The instances or sub-LSPs of a container LSP, which are dynamically created or 
removed. 
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Autobandwidth is run over each of the member LSPs, and each LSP is resized according to the traffic it 
carries and the autobandwidth configuration parameters. The aggregate demand on a container LSP is 
tracked by adding up the bandwidth across all the member LSPs. 


Minimum signaling-bandwidth—The minimum bandwidth with which a member LSP is signaled at the 
time of normalization or initialization. This could be different from the minimum-bandwidth defined 
under autobandwidth. 


Maximum signaling-bandwidth —The maximum bandwidth with which a member LSP is signaled at the 
time of normalization or initialization. This could be different from the maximum-bandwidth defined 
under autobandwidth. 


Merging-bandwidth —Specifies the lower bandwidth threshold on the aggregate bandwidth usage, such 
that if the aggregate usage falls below this value, the ingress router merges the member LSPs at the time 
of normalization. 


Splitting-bandwidth —Specifies the upper bandwidth threshold on the aggregate bandwidth usage, such 
that if the aggregate usage exceeds this value, the ingress router splits the member LSPs at the time of 
normalization. 


Aggregate minimum-bandwidth —Sum of merging-bandwidth of the current active member LSPs. This 
minimum bandwidth is different from the autobandwidth minimum-bandwidth. 


Aggregate maximum-bandwidth—Sum of the splitting-bandwidth of the current active member LSPs. 
This maximum bandwidth is different from the autobandwidth maximum-bandwidth. 


LSP Splitting 


IN THIS SECTION 


@ Operational Overview | 598 

@ Operational Constraints | 599 

@ Supported Criteria | 599 

@ = Splitting Triggers | 600 
Operational Overview 


The LSP splitting mechanism enables an ingress router to create new member LSPs or to re-signal existing 
LSPs with different bandwidths within a container LSP when a demand X is placed on the container LSP. 
With LSP splitting enabled, an ingress router periodically creates a number of LSPs (by signaling new ones 


or re-signaling existing ones) to accommodate a new aggregate demand X. In the current implementation, 


an ingress router tries to find an LSP path satisfying a demand X and other constraints. If no path is found, 


either the LSP is not signaled or it remains up, but with the old reserved bandwidth. 
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Between two normalization events (splitting or merging), individual LSPs might get re-signaled with different 
bandwidths due to the autobandwidth adjustments. If a container LSP is not configured with autobandwidth, 
then the member LSPs are signaled with the static bandwidth value, if configured. There is no dynamic 
splitting in this case, as there is no dynamic estimation of aggregate bandwidth. The splitting adjustments 
with a specific bandwidth value can be manually triggered. 


NOTE: 


Be aware of the following considerations for LSP splitting: 


e After LSP splitting, the ingress router continues to inject one forwarding adjacency. Forwarding 
adjacencies are not supported in IGP for this feature. 


e Between two normalization events, two LSPs might have different bandwidths subjected to 
autobandwidth constraints. 


e After LSPs are split (or merged), make-before-break uses the fixed filter (FF) style sharing 
unless the adaptive option is configured. However, two different LSPs do not do the shared 
explicit (SE) style sharing for this feature. 


e When LSPs are re-signaled with modified bandwidths, some of the LSPs might not get signaled 
successfully, leading to failover options. 


Operational Constraints 


LSP splitting has the following operational constraints: 


e LSP bandwidth—Although there are a number of ways to allocate bandwidth values to the LSPs, the 
Junos OS implementation supports only an equal-bandwidth allocation policy when normalization is 
done, wherein all the member LSPs are signaled or re-signaled with equal bandwidth. 


e Number of LSPs—If an ingress router is configured to have a minimum number of LSPs, it maintains the 
minimum number of LSPs even if the demand can be satisfied with less than the minimum number of 
LSPs. In case the ingress router is unable to do constraint-based routing for computations on the sufficient 
number of LSPs or signal sufficient number of LSPs, the ingress router resorts to a number of failback 
options. 


By default, an incremental approach is supported as a fallback option (unless configured differently), 
where an ingress router makes attempts to bring up the sufficient number of LSPs, such that the new 
aggregate bandwidth exceeds the old aggregate bandwidth (and is as close to the desired demand as 
possible). The ingress router then load-balances traffic using the LSPs. The LSPs that could not be brought 
up are removed by the ingress router. 


Supported Criteria 


When a container LSP signals a member LSP, the member LSP gets signaled with 
minimum-signaling-bandwidth. Since each member LSP is configured with autobandwidth, between two 
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normalization events, each LSP can undergo autobandwidth adjustment multiple times. As the traffic 
demand increases, the ingress router creates additional supplementary LSPs . All member LSPs are used 
for ECMP, so they should roughly have the same reserved bandwidth after normalization. 


For example, if there are K LSPs signaled after normalization, each LSP is signaled with equal bandwidth 
B. The total aggregate bandwidth reserved is B.K, where B satisfies the following condition: 


e Minimum signaling-bandwidth is less than or equal to B, which is turn is less than or equal to the maximum 
signaling-bandwidth 


(minimum-signaling-bandwidth < B < maximum-signaling-bandwidth) 


Until the next normalization event, each member LSP undergoes several autobandwidth adjustments. After 
any autobandwidth adjustment, if there are N LSPs with reserved bandwidths bi, where i=1,2,.., N, each 
bi should satisfy the following the condition: 


e Minimum bandwidth is less than or equal to bi, which in turn is less than or equal to the maximum 
bandwidth 


(minimum-bandwidth < bi < maximum-bandwidth) 


Both the above-mentioned conditions are applicable for per member LSP (nominal and supplementary), 
and essentially have the reserved bandwidth to exist within a range. 


Splitting Triggers 


Every time the normalization timer expires, the ingress router decides if LSP splitting is required. The 
ingress router works with the aggregate bandwidth instead of the individual LSP bandwidths. The following 
two variables are defined for aggregate bandwidth: 


e Current-Aggr-Bw—Sum of reserved bandwidths of all current member LSPs. 


e New-Aggr-Bw—Sum of traffic rates on all current member LSPs based on sampling. 


Taking for example, if there are N member LSPs in the network at the time of normalization, the two 
approaches to trigger LSP splitting are as follows: 


e Absolute trigger—LSP splitting is performed when New-Aggr-Bw is greater than 
Aggregate-maximum-bandwidth. 


(New-Aggr-Bw > Aggregate-maximum-bandwidth) 


e Relative trigger—The Current-Aggr-Bw is compared with New-Aggr-Bw at the ingress routing device. 
LSP splitting is performed when the difference in the bandwidth amount is off by a threshold. 


([1-a] x Current-Aggr-Bw < New-Aggr-Bw < [1+a] x Current-Aggr-Bw, where 0 </= a </= 1) 


When New-Aggr-Bw is greater than or equal to [1+a] multiplied by Current-Aggr-Bw, the ingress routing 
device does not perform normalization, but instead LSP splitting is done. However, when both LSP 
splitting and LSP merging are configured on the ingress router, LSP splitting is triggered on the ingress 
router when one of the two conditions is satisfied. 


LSP Merging 


IN THIS SECTION 


@ Operational Overview | 601 
@ = Operational Constraints | 601 
@ Merging Triggers | 602 


Operational Overview 


Junos OS supports two kinds of LSPs - CLI-configured LSPs and dynamically created LSPs. The 
CLI-configured LSPs are created manually and remain in the system until the configuration is modified. 
The dynamic LSPs are created dynamically by next generation MVPN, BGP virtual private LAN service 
(VPLS), or LDP, based on a template configuration, and are removed from the system when not used by 
any application for a certain duration. LSP merging follows a similar approach as dynamic LSPs. 


LSP merging enables an ingress routing device to dynamically eliminate some member LSPs of the container 
LSP so less state information is maintained in the network. If an ingress router provisions several member 
LSPs between the ingress and egress routers, and there is an overall reduction in aggregate bandwidth 
(resulting in some LSPs being under-utilized), the ingress router distributes the new traffic load among 
fewer LSPs. 


Although there are a number of ways to merge the member LSPs, Junos OS supports only overall-merge 
when normalization is being performed. An ingress router considers the aggregate demand and the minimum 
(or maximum) number of LSPs and revises the number of LSPs that should be active at an ingress routing 
device. As a result, the following can take place periodically as the normalization timer fires: 


e Re-signaling some of the existing LSPs with updated bandwidth 
e Creating new LSPs 


e Removing some of the existing LSPs 


Operational Constraints 


If a container LSP is not configured with autobandwidth, then the member LSPs are signaled with the static 
bandwidth value, if configured. LSP merging does not happen because there is no dynamic estimation of 
aggregate bandwidth. However, a manual trigger for splitting and adjusting with a specific bandwidth value 
can be configured. 
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NOTE: 
e Nominal LSPs are never deleted as part of LSP merging. 


e Before deleting an LSP, the LSP is made inactive, so that traffic shifts to other LSPs before 
removing the LSP. This is because RSVP sends PathTear before deleting routes and next hops 
from the Packet Forwarding Engine. 


e When member LSPs are re-signaled with modified bandwidth, it might happen that some LSPs 
do not get signaled successfully. 


Merging Triggers 


Every time the normalization timer expires, the ingress router decides if LSP merging is required. The 
ingress router works with the aggregate bandwidth instead of the individual LSP bandwidths. The following 
two variables are defined for aggregate bandwidth: 


e Current-Aggr-Bw—Sum of reserved bandwidths of all current member LSPs. 
e New-Aggr-Bw—Sum of traffic rates on all current member LSPs based on sampling. 


For example, if there are N member LSPs in the network at the time of normalization, the two approaches 
to trigger LSP merging are as follows: 


e Absolute trigger—LSP merging is performed when New-Aggr-Bw is less than 
Aggregate-minimum-bandwidth. 


(New-Aggr-Bw < Aggregate-maximum-bandwidth) 


Relative trigger—The Current-Aggr-Bw is compared with New-Aggr-Bw at the ingress routing device. 
LSP merging is performed when the difference in the bandwidth amount is off by a threshold. 


([1-a] x Current-Aggr-Bw < New-Aggr-Bw < [1+a] x Current-Aggr-Bw, where 0 </= a </= 1) 


When the New-Aggr-Bw value is less than or equal to [1+a] multiplied by the Current-Aggr-Bw value, 
the ingress routing device does not perform normalization, but instead LSP merging is done. However, 
when both LSP splitting and LSP merging are configured on the ingress router, LSP splitting is triggered 
on the ingress router when one of the two conditions is satisfied. 


Node and Link Protection 
Junos OS supports the following mechanisms for node and link protection: 


e Fast-reroute 
e Link protection 


e Node-link protection 
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Only one of the above-mentioned modes of protection can be configured on an ingress routing device at 
any given time. All member LSPs (nominal and supplementary) use the same mode of protection that is 
configured. 


Naming Convention 


While configuring a container LSP, a name is assigned to the LSP. The name of a nominal and a 
supplementary LSP is formed by adding the configured-name suffix and an auto-generated suffix to the 
name of the container LSP. The name of the container LSP is unique and is checked for accuracy during 
the configuration parsing. The container LSP name should uniquely identify parameters, such as the ingress 
and egress router names. 


NOTE: A container LSP member LSP and a point-to-point LSP on an ingress routing device 
cannot have the same LSP name. 


The container LSPs follow a number-based LSP naming convention. For example, if the nominal LSP's 
configured name is bob and the number of member LSPs is N, the member LSPs are named 
bob-<configured-suffix>-1, bob-<configured-suffix>-2, ..., and bob-<configured-suffix>-N. 


After a normalization event, the number of member LSPs can change. For example, if the number of 
member LSPs increases from six to eight, then the ingress routing device keeps the first six LSPs named 
bob-<configured-suffix>-1, bob-<configured-suffix>-2, ..., and bob-<configured-suffix>-6. The two additional 
LSPs are named bob-7 and bob-8. The original LSPs might need to be re-optimized if their signaled 
bandwidth changes. 


Similarly, if the number of member LSPs reduces from eight to six, the ingress routing device re-signals 
the member LSPs in such as a way that the remaining active LSPs in the system are named 
bob-<configured-suffix>-1, bob-<configured-suffix>-2, ..., and bob-<configured-suffix>-6. 


In the process of creating new LSPs, an RSVP LSP named bob-<configured-suffix>-7 can be configured. 


Normalization 


IN THIS SECTION 


@ Operational Overview | 604 
@ = Operational Constraints | 604 
@ —_Inter-Operation with Autobandwidth | 605 
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Operational Overview 


Normalization is an event that happens periodically. When it happens, a decision is made on the number 
of member LSPs that should remain active and their respective bandwidths in a container LSP. More 
specifically, the decision is made on whether new supplementary LSPs are to be created, or any existing 
LSPs are required to be re-signaled or deleted during the normalization event. 


Between two normalization events, a member LSP can undergo several autobandwidth adjustments. A 
normalization timer, similar to re-optimization timer, is configured. The normalization timer interval should 
be no less than the adjustment interval or optimization timer. 


NOTE: Normalization is not triggered based on network events, such as topology changes. 


Operational Constraints 


Normalization has the following operational constraints: 


e Normalization happens only when none of the member LSPs are undergoing re-optimization or 
make-before-break. Normalization starts when all the member LSPs complete their ongoing 
make-before-break. If normalization is pending, new optimization should not be attempted until the 
normalization is complete. 


e After normalization, an ingress routing device first computes a set of bandwidth-feasible paths using 
constraint-based routing computations. If enough constraint-based routing computed paths are not 
brought up with an aggregate bandwidth value that exceeds the desired bandwidth, several failover 
actions are taken. 


e After aset of bandwidth-feasible paths are available, the ingress routing device signals those paths while 
keeping the original set of paths up with the old bandwidth values. The make-before-break is done with 
shared explicit (SE) sharing style, and when some of the LSPs do not get successfully re-signaled, a 
bounded number of retries is attempted for a specified duration. Only when all the LSPs are successfully 
signaled does the ingress router switch from the old instance of the container LSP to the newer instance. 
If all LSPs could not be successfully signaled, the ingress router keeps those instances of members that 
are up with higher bandwidth values. 


For example, if the bandwidth of an old instance of a member LSP (LSP-1) is 1G, the LSP is split into 
LSP-1 with bandwidth 2G and LSP-2 with bandwidth 2G. If the signaling of LSP-1 with bandwidth 2G 
fails, the ingress router keeps LSP-1 with bandwidth 1G and LSP-2 with bandwidth 2G. 


When there is a signaling failure, the ingress routing device stays in the error state, where some LSPs 
have updated bandwidth values only if the aggregate bandwidth has increased. The ingress router makes 
an attempt to bring up those LSPs that could not be successfully signaled, resulting in minimum traffic 
loss. 


If an LSP goes down between two normalization events, it can increase the load on other LSPs that are 


up. In order to prevent overuse of other LSPs, premature normalization can be configured in case of LSP 
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failure. LSPs can go down because of pre-emption or lack of node or link protection. It might not be 


necessary to bring up the LSPs that are down because the normalization process re-runs the 


constraint-based routing path computations. 


Inter-Operation with Autobandwidth 


IN THIS SECTION 


@ = Changes in Per-LSP Autobandwidth Adjustments | 605 


@ ~~ Changes in Traffic Growth | 607 


@ Computed Range and Configured Feasible Ranges | 607 


Taking as an example, there is one nominal LSP named LSP-1 configured with the following parameters: 


e Splitting-bandwidth and maximum-signaling-bandwidth of 1G 


e Merging-bandwidth and minimum-signaling-bandwidth of 0.8G 


e Autobandwidth 


Normalization is performed differently in the following scenarios: 


Changes in Per-LSP Autobandwidth Adjustments 


Table 19 on page 605 illustrates how normalization splits and merges member LSPs as autobandwidth 


adjustments change per-LSP bandwidth with unconditional normalization. 


Table 19: Normalization with Per-LSP Autobandwidth Adjustment Changes 


Normalization 


Time Current State 

TO No state. 

T1 LSP-1 usage increases 
to 1.5G 

T2 LSP-1 usage increase to 
2G 


LSP-2 usage increases 
to 0.9G (within limits) 


Events 


Initialization 


Multiple autobandwidth adjustments since 
TO is possible. 


The ingress router decides to split LSP-1 
into two LSPs, and creates LSP-2. 


Aggregate bandwidth is 2.9G, which 
exceeds aggregate splitting maximum of 
2G. 


The ingress router decides to split LSP-1 
into three LSPs, and creates LSP-3. 


Adjusted State 


LSP-1 is signaled with 
bandwidth of 0.8G 


LSP-1 = 0.8G 


LSP-2 = 0.8G 


LSP-1=1G 
LSP-2 = 1G 


LSP-3 = 1G 


Table 19: Normalization with Per-LSP Autobandwidth Adjustment Changes (continued) 


Normalization 


Time Current State Events Adjusted State 
T3 LSP-3 usage increases e Aggregate bandwidth is 3.5G with a LSP-1=1G 
to 1.5G maximum aggregate splitting of 3G. 
LSP-2=1G 
e The ingress router decides to split LSP-1 
into four LSPs, and creates LSP-4. LSP-3 = 1G 
LSP-4=1G 
T4 LSP-2 usage drops to e Aggregate bandwidth is 3G. LSP-1=1G 


0.5G 


The ingress router decides to merge LSP-1 LSP-2=1G 
and removes LSP-4. 


LSP-3 = 1G 


Because autobandwidth is configured on a per-LSP basis, every time there is an auttobandwidth adjustment, 
the ingress router re-signals each LSP with Max Avg Bw. 


Another approach to handling the changes in per-LSP autobandwidth adjustments is to not allow individual 
LSPs to run autobandwidth on the ingress router, but to run autobandwidth in passive (monitor) mode. 
This way, sampling is done at every statistics interval for member LSPs only, and normalization is performed 
for the container LSP alone instead of acting on individual LSPs adjustment timer expiry. 


As a result, the number of re-signaling attempts and bandwidth fluctuations for a given member LSP is 
reduced. Only the computed bandwidth-values per-member LSP is used by the ingress router to find an 
aggregate bandwidth to be used during normalization. Configuring autobandwidth adjustment followed 
by normalization (adjustments and normalization intervals are comparable) can lead to considerable overhead 
because of re-signaling. 


Taking the same example, and applying the second approach, LSP-1 goes from 0.8G to 1.5G and then back 
to 0.8G. If the normalization timer is of the same order as the adjustment interval, the ingress router leaves 
LSP-1 alone with its original 0.8G and only signals LSP-2 with 0.8G. This helps achieve the final result of 
normalization, thus avoiding the extra signaling attempt on LSP-1 with 1.5G at adjustment timer expiry. 


Because member LSPs always use equal bandwidth, any adjustment done on member LSPs is undone. The 
member LSPs are re-signaled with reduced bandwidth when compared to the reserved capacity in 
adjustment trigger with normalization trigger. Therefore, avoiding adjustment trigger for member LSPs 
might be useful assuming that normalization and adjustment intervals are of the same order. 
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NOTE: We recommend that the normalization timer be higher than the autobandwidth adjustment 
interval and regular optimization duration, as the traffic trends are observed at a longer time 
scale and normalization is performed one-to-three times per day. An LSP can undergo optimization 
for the following reasons: 


e Normal optimization 
e Autobandwidth adjustment 


e Normalization 


Changes in Traffic Growth 


Table 20 on page 607 illustrates how normalization is performed when traffic grows in large factor. 
Table 20: Normalization with Traffic Growth 


Normalization 


Time Current State Events Adjusted State 
TO No state LSP-1 is signaled with 
bandwidth of 0.8G 
T1 LSP-1 usage increase | e Aggregate usage exceeds maximum LSP-1=1G 
to 3G splitting bandwidth 
LSP-2 = 1G 


e The ingress router decides to split 
LSP-1, and creates two more LSP-3 =1G 
supplementary LSPs 


Having fewer LSPs is preferred over signaling four LSPs each with 0.8G bandwidth, unless there is a 
constraint on the minimum number of LSPs. 


Computed Range and Configured Feasible Ranges 


When an ingress router is configured with the minimum and maximum number of LSPs, and per LSP 
splitting-bandwidth and merging-bandwidth values, the bandwidth thresholds are used for splitting and 
merging. For this, the number of LSPs (N) should satisfy the following constraints: 

minimum-member-lsps < N < maximum-member-lsps 


At the time of normalization, based on the aggregate demand X: 


[X/splitting-bandwidth] < N < [X/merging-bandwidth] 
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The above-mentioned constraints provide two ranges for N to work from. If the two ranges for N are 
overlapping, N will be selected from the overlapping interval (lowest possible N) to keep the number of 
LSPs small in the network. 


Otherwise, if maximum-member-lsps is less than [X/splitting-bandwidth], the ingress router keeps (at 
maximum) the maximum-member-lsps in the system, and the bandwidth of each LSP is 
[X/maximum-member-lsps] or the maximum-signaling-bandwidth, whichever is less. It is possible that 
some LSPs might not get signaled successfully. 


Similarly, if minimum-member-lsps is greater than [X/merging-bandwidth], the ingress router keeps (at 
minimum) the minimum-member-lsps in the system, and the bandwidth of each LSP is 
[X/minimum-member-lsps] or the minimum-signaling-bandwidth, whichever is less. 


Taking as an example, normalization is performed as following in these cases: 


e Case 1 
e minimum-member-lsps = 2 
e maximum-member-lsps = 10 
e aggregate demand = 10G 
e merging-bandwidth = 1G 
e splitting-bandwidth = 2.5G 
In this case, the ingress routing device signals four member LSPs each with a bandwidth of 2G. 
e Case 2 
e minimum-member-lsps = 5 
e maximum-member-lsps = 10 
e aggregate demand = 10G 
e merging-bandwidth = 2.5G 
e splitting-bandwidth = 10G 


In this case, the ingress routing device signals five member LSPs each with a bandwidth of 2G. Here, the 
static configuration on the number of member LSPs takes precedence. 


e Case 3 
e minimum-signaling-bandwidth = 5G 
e maximum-signaling-bandwidth = 40G 
e merging-bandwidth = 10G 
e splitting-bandwidth = 50G 
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When a container LSP comes up, the nominal LSP is signaled with minimum-signaling-bandwidth. At the 
time of normalization, the new-aggregate-bandwidth is 100G. To find N and the bandwidth of each LSP, 
N should satisfy the following constraint: 


100/50 < N < 100/10, which gives 2 < N < 10 


Therefore, N is equal to: 


e N = 2, bandwidth = min {100/2G, 40G} = 40G 
This option does not satisfy the new aggregate of 100G. 
e N = 3, bandwidth = min {100/3G, 40G} = 33.3G 
This option makes the aggregate bandwidth equal to 100G. 


In this case, the ingress routing device signals three LSPs each with a bandwidth of 33.3G. 


NOTE: The ingress router does not signal an LSP smaller than the 
minimum-signaling-bandwidth. 


Constraint-Based Routing Path Computation 


Although there are no changes in the general constraint-based routing path computation, with a container 
LSP, there is a separate module that oversees the normalization process, schedules constraint-based routing 
events, and schedules switchover from an old instance to a new instance, when appropriate. An ingress 
routing device has to handle the constraint-based routing path computation periodically. When normalization 
occurs, an ingress router has to compute constraint-based routing paths, if the number of LSPs or the 
bandwidth of the LSPs needs to be changed. 


For example, there are K LSPs at the ingress router with bandwidth values X-1, X-2, ..., and X-K. The current 
aggregate bandwidth value is Y, which is the sum of X-1 plus X-2 plus X-K. If there is a new demand of 
W, the ingress router first computes how many LSPs are required. If the ingress router only needs N LSPs 
(LSP-1, LSP-2, .., and LSP-N) each with bandwidth value B, the task of the constraint-based routing module 
is to provide a set of bandwidth-feasible LSPs that can accommodate the new aggregate demand which 
is not less than Y. 


The ingress router then tries to see if the constraint-based routing paths can be computed successfully 
for all N LSPs. If the paths for all the LSPs are found successfully, the constraint-based routing module 
returns the set to the normalization module. 


It is possible that the constraint-based routing computation is not successful for some LSPs. In this case, 
the ingress routing device takes the following action: 


e If the configuration allows for incremental-normalization, implying if the ingress router has enough LSPs 
whose aggregate exceeds Y, the constraint-based routing module returns that set of paths. 


e Whether increment-normalization is configured or not, if constraint-based routing paths could not be 
computed for a sufficient number of LSPs, the ingress router has to repeat the process of finding a new 
set of LSPs. Initially, the ingress router starts with the lowest value of N from the feasible region. Every 
time, the ingress router has to revise the number, it linearly increases it by 1. As a result, per LSP 
bandwidth becomes less and therefore, there is a greater chance of successful signaling. The process is 
repeated for all feasible values of N (or some bounded number of times or duration as configured). 


The ingress router signals the LSPs after successful computations of the constraint-based routing path 
computation. It might happen that when the LSPs are signaled, signaling of many LSPs fail. In addition 
to the constraint-based routing path computations to be successful, the RSVP signaling should also 
succeed, such that the new aggregate is not less than the old aggregate bandwidth. 


Sampling 

Sampling is important for normalization to function. With sampling configured, an ingress routing device 
is able to make a statistical estimate of the aggregate traffic demands. Every time the sampling timer fires, 
the ingress routing device can consider traffic rates on different LSPs and compute an aggregate bandwidth 
sample. This sampling timer is different from the statistics sampling done periodically by RSVP on all LSPs. 
The aggregate bandwidth is a sample to be used at the time of normalization. An ingress routing device 
can save past samples to compute an average (or some other statistical measure) and use it the next time 
normalization happens. 


To remove any outlier samples, a sampling token is configured. In other words, from all the aggregate 
samples collected during the configured time, the bottom and top outliers are ignored before computing 
a statistical measure from the remaining samples. 


The following two methods of computing an aggregate bandwidth value are supported: 


e Average—All the aggregate bandwidth samples are considered by the ingress routing device, and then 
all the outlier samples are removed. The average bandwidth value is computed from the remaining 
samples to be used during normalization. 


e Max—All the aggregate bandwidth samples are considered by the ingress routing device, and then all 
the outlier samples are removed. The maximum bandwidth value is picked from the remaining samples 
to be used during normalization. 


The time duration, the number of past aggregate samples to store, the percentile value to determine, and 
the ignore outliers are user-configurable parameters. 


Support for NSR, IPG-FA, and Static Routes 


IN THIS SECTION 


@  NSR Support | 611 
@  IPG-FA Support | 612 
@ Static Route Support | 613 
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Starting with Junos OS Release 15.1, container label-switched paths (LSPs) provide support for nonstop 
active routing (NSR), IGP forwarding adjacency (FA), and static routes to address the requirements of wider 
business cases. 


NSR Support 


A container LSP has the characteristics of ECMP and RSVP traffic engineering. Because a container LSP 
consists of several member LSPs between an ingress and an egress router, with each member LSP taking 
a different path to the same destination, the ingress router is configured with all the parameters necessary 
to compute an RSVP ECMP LSP. These parameters along with the forwarding state information have to 
be synchronized between the master and backup Routing Engines to enable the support for nonstop active 
routing (NSR) for container LSPs. While some of the forwarding state information on the backup Routing 
Engine is locally built based on the configuration, most of it is built based on periodic updates from the 
master Routing Engine. The container LSPs are created dynamically using the replicated states on the 
backup Routing Engine. 


By default, normalization occurs once in every 6 hours and during this time, a number of autobandwidth 
adjustments happen over each member LSP. A member LSP is resized according to the traffic it carries 
and the configured autobandwidth configuration parameters. The aggregate demand on a container LSP 
is tracked by summing up the bandwidth across all the member LSPs. 


For RSVP point-to-point LSPs, a Routing Engine switchover can be under any one of the following: 


e Steady state 


In the steady state, the LSP state is up and forwards traffic; however, no other event, such as the 
make-before-break (MBB), occurs on the LSP. At this stage, the RPD runs on both the Routing Engines, 
and the switchover event toggles between the master and backup Routing Engine. The backup Routing 
Engine has the LSP information replicated already. After the switchover, the new master uses the 
information of the replicated structure to construct the container LSP and en-queues the path (ERO) of 
LSP in the retrace mode. RSVP signals and checks if the path mentioned in the ERO is reachable. If the 
RSVP checks fail, then the LSP is restarted. If the RSVP checks succeed, the LSP state remains up. 


Action leading to make-before-break (MBB) 


A container LSP can be optimized with updated bandwidth, and this change is done in a MBB fashion. 
During an MBB process, there are two path instances for a given LSP, and the LSP switches from one 
instance to another. For every Routing Engine switchover, the path is checked to find out where in the 
MBB process the path is. If the path is in the middle of the MBB process, with the main instance being 
down and the re-optimized path being up, then MBB can switch over to the new instance. The show 
mpls Isp extensive command output, in this case, is as follows: 


13 Dec 3 01:33:38.941 Make-before-break: Switched to new instance 
12 Dac 33 Wile sdea7 94s IRecowel RoweSss  10,1,i1.1 
li Dac 2 Wilesses7.942 Wis) 
10 Dec 3 01:33:37.942 Automatic Autobw adjustment succeeded: BW changes from 
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100 bps to 281669 bps 
9 Dec 3 01:33:37.932 Originate make-before-break call 
3 exe 3 Wlssses7/ .Osil CSTs Couiotiesciom wesule acecierecl 10 1.1.1 
7 Dec 3 M1328 944. 228 CPS WING RACKEOCS Was SuccesSiml iI0.,i1,i.i 
6 Dee F MileiSes.9s IO,1,1,2 Dewiae wlolo/seoyeie 
5 Dec 3 01:18:29.286 Up: mbb/reopt 
4 ijxe 3 Oilsidedy 1S IO.1,1.2 Werins wmldio/eeoysic 
3 Dec 3 01:13:29.285 Up: mbb/reopt 
2 Dec 3 01:10:59.755 Selected as active path: selected by master RE 


A similar behavior is retained for member LSPs during bandwidth optimization. 


A Routing Engine switchover under the steady state (when normalization is not in progress), keeps the 
container LSPs up and running without any traffic loss. Events, such as an MBB due to autobandwidth 
adjustments, link status being down, or double failure, in the steady state are similar to a normal RSVP 
point-to-point LSP. 


If the container LSP is in the process of normalization, and the normalization event is triggered either 
manually or periodically, it goes through the computation and execution phase. In either of the cases, 
zero percent traffic loss is not guaranteed. 


e Normalization in the computation phase 


During the computation phase, the master Routing Engine calculates the targeted member LSP count 
and bandwidth with which each member LSP should be re-signaled. The backup Routing Engine has 
limited information about the container LSP, such as the LSP name, LSP ID, current bandwidth of its 
member LSP, member LSP count, and the normalization retry count. If the switchover happens during 
the computation phase, then the backup Routing Engine is not aware of the targeted member LSP 
count and the bandwidth to be signaled. Since traffic statistics are not copied to the backup Routing 
Engine, it cannot compute the targeted member count and bandwidth. In this case, the new master 
Routing Engine uses the old data stored in the targeted member LSP count and the targeted bandwidth 
to signal the LSPs. 


Normalization in the execution phase 


During the execution phase, RSVP of the master Routing Engine tries to signal the LSPs with the newly 
calculated bandwidth. If the switchover occurs during the signaling of LSPs with greater bandwidth 
or during LSP splitting or merging, then the new master Routing Engine uses the information of the 
targeted member count and bandwidth value to be signaled with, to bring up the LSPs. 


IPG-FA Support 


A forwarding adjacency (FA) is a traffic engineering label-switched path (LSP) that is configured between 
two nodes and used by an interior gateway protocol (IGP) to forward traffic. By default, an IGP does not 
consider MPLS traffic-engineering tunnels between sites, for traffic forwarding. Forwarding adjacency 

treats a traffic engineering LSP tunnel as a link in an IGP topology, thus allowing the nodes in the network 
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also to forward the IP traffic to reach the destination over this FA LSP. A forwarding adjacency can be 
created between routing devices regardless of their location in the network. 


To advertise a container LSP as an IGP-FA, the LSP name needs to be configured either under IS-IS or 
OSPF. For example: 


IS-IS 
[edit] 
protocols { 
isis { 
label-switched-path container-Isp-name; 
} 
} 
OSPF 


[edit] 
protocols { 
ospf { 
area 0.0.0.0 { 
label-switched-path container-Isp-name; 


NOTE: The IGP-FA is applied to both container LSPs and regular point-to-point LSPs. If a container 
LSP and a point-to-point LSP share the same name, the point-to-point LSP is given preference 
for FA. 


Static Route Support 


Static routes often include only one or very few paths to a destination and generally do not change. These 
routes are used for stitching services when policies and other protocols are not configured. 


To advertise a container LSP as a static route, the LSP name needs to be configured under the static route 
configuration. For example: 


Static Route 
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[edit] 
routing-options { 
static { 
route destination { 
Isp-next-hop container-Isp-name; 


NOTE: The static route support is applied to both container LSPs and regular point-to-point 
LSPs. If a container LSP and a point-to-point LSP share the same name, the point-to-point LSP 
is given preference for static routing. 


Configuration Statements Supported for Container LSPs 


Table 21 on page 614 lists the MPLS LSP configuration statements that apply to RSVP LSP and a container 
LSP (nominal and supplementary). 


The configuration support is defined using the following terms: 


e Yes—The configuration statement is supported for this type of LSP. 
e No—The configuration statement is not supported for this type of LSP. 


e N/A-—The configuration statement is not applicable for this type of LSP. 


Table 21: Applicability of RSVP LSPs Configuration to a Container LSP 


RSVP LSP Member LSP 
Configuration Statement (Ingress) (Ingress) 
adaptive Yes Yes 
(Default: non-adaptive) 
admin-down Yes Yes 
admin-group Yes Yes 
admin-groups-except Yes Yes 


apply-groups Yes Yes 


Table 21: Applicability of RSVP LSPs Configuration to a Container LSP (continued) 


Configuration Statement 


apply-groups-except 


associate-backup-pe-groups 


associate-Isp 


(No bidirectional support) 


auto-bandwidth 


backup 


bandwidth 


class-of-service 


corouted-bidirectional 


(No bidirectional support) 


corouted-bidirectional-passive 


(No bidirectional support) 


description 


disable 


egress-protection 


exclude-srlg 


fast-reroute 


(Same fast reroute for all member LSPs) 


from 


hop-limit 


install 


RSVP LSP 
(Ingress) 


Yes 
Yes 


Yes 


Yes 
Yes 
Yes 
Yes 


Yes 


Yes 


Yes 
Yes 
Yes 
Yes 


Yes 


Yes 
Yes 


Yes 


Member LSP 
(Ingress) 


Yes 
No 


No 


Yes 
No 

Yes 
Yes 


No 


No 


Yes 
Yes 
No 

Yes 


Yes 


Yes 
Yes 


Yes 
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Table 21: Applicability of RSVP LSPs Configuration to a Container LSP (continued) 


Configuration Statement 


inter-domain 


(Same termination router) 


secondary 


(All LSPs are primary) 


Idp-tunneling 


(All LSPs do tunneling) 


least-fill 


link-protection 


(All LSPs share same link protection mechansim) 


Isp-attributes 


Isp-external-controller 


metric 


(All LSPs are same) 


most-fill 


no-cspf 


(LSPs use IGP) 


no-decrement-ttl 


(All LSPs share same TTL behavior) 


no-install-to-address 


no-record 


node-link-protection 


(Al LSPs share same node-link protection mechanism) 


RSVP LSP 
(Ingress) 


Yes 


Yes 


Yes 


Yes 


Yes 


Yes 
Yes 


Yes 


Yes 


Yes 


Yes 


Yes 
Yes 


Yes 


Member LSP 
(Ingress) 


Yes 


No 


Yes 


Yes 


Yes 


Yes 
No 


Yes 


Yes 


Yes 


Yes 


Yes 
Yes 


Yes 
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Table 21: Applicability of RSVP LSPs Configuration to a Container LSP (continued) 


RSVP LSP Member LSP 
Configuration Statement (Ingress) (Ingress) 
oam Yes Yes 
optimize-hold-dead-delay Yes Yes 
(All LSPs have same value) 
optimize-switchover-delay Yes Yes 
(All LSPs have same value) 
optimize-timer Yes Yes 
(All LSPs have same value) 
p2mp Yes N/A 
policing Yes No 
(Variable traffic) 
preference Yes Yes 
primary Yes No 
(All paths are primary) 
random Yes Yes 
record Yes Yes 
retry-limit Yes Yes 
(Applicable to members) 
retry-timer Yes Yes 
(Applicable to members) 
revert-timer Yes No 


(No secondary LSP) 
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Table 21: Applicability of RSVP LSPs Configuration to a Container LSP (continued) 


RSVP LSP Member LSP 

Configuration Statement (Ingress) (Ingress) 
secondary Yes No 

(All LSPs are primary) 

soft-preemption Yes Yes 
standby Yes No 

(All LSPs are standby) 

template Yes No 

to Yes Yes 
traceoptions Yes Yes 
ultimate-hop-popping Yes Yes 


Impact of Configuring Container LSPs on Network Performance 


A container LSP is a container LSP that allows multiple member LSPs to co-exist and be managed as a 
bundle. The member LSPs are similar to independent point-to-point RSVP LSPs. As a result, resource 
consumption is similar to the sum of resources consumed by each point-to-point RSVP LSP. However, 
provisioning a container LSP is more efficient, as under-utilized member LSPs are dynamically removed, 
thus saving memory and CPU resources. 


The container LSP features are dependent on the presence of a functional base MPLS RSVP implementation. 
As a result, a container LSP does not introduce any security considerations beyond the existing 
considerations for the base MPLS RSVP functionality. The categories of possible attacks and 
countermeasures are as follows: 


Interaction with processes and router configuration 


No new communication mechanisms with external hosts are required for a container LSP. Data arrives 
at the RSVP module through local software processes and router configuration, other than RSVP neighbor 
adjacency. Junos OS provides security controls on access to the router and router configuration. 


Communication with external RSVP neighbors 


RSVP signaled MPLS LSPs depend on the services of RSVP and IGP to communicate RSVP messages 
among neighboring routers across the network . Because the RSVP sessions involve communication 
outside of the local router, they are subject to many forms of attack, such as spoofing of peers, injection 
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of falsified RSVP messages and route updates, and attacks on the underlying TCP/UDP transport for 
sessions. Junos OS provides countermeasures for such attack vectors. 


Resource limits and denial of service 


Junos OS provides several mechanisms through policers and filters to protect against denial-of-service 
attacks based on injecting higher than the expected traffic demands. At the MPLS LSP level, Junos OS 
allows operators to configure limits on the LSP bandwidth and the number of LSPs. However, like 
point-to-point RSVP LSPs, container LSPs do not enforce limits on the volume of traffic forwarded over 
these LSPs. 


Supported and Unsupported Features 


Junos OS supports the following container LSP features: 


Equal-bandwidth-based LSP splitting mechanism 

Aggregate-bandwidth-based LSP splitting and merging in a make-before-break way 
LSP-number-based naming mechanism for dynamically created member LSPs 
Periodic sampling mechanisms to estimate aggregate bandwidth 

Interoperability with auto-bandwidth feature 

ECMP using the dynamically created LSPs 

LDP-tunneling on the dynamically created LSP 

Configuring container LSP using IGP shortcuts 

Aggregated Ethernet links 


Logical systems 


Junos OS does not support the following container LSP functionality: 


Node and link disjoint paths for different LSPs between an ingress and an egress routing device 
Bandwidth allocation policy different from equal bandwidth policy at the normalization event 
Constraint-based routing path computation to find equal IGP cost paths for different LSPs 


RSVP objects, such as MLSP_TUNNEL Sender Template, and MLSP_TUNNEL Filter Specification defined 
in [KOMPELLA-MLSP] 


Change in topology as a trigger for LSP splitting and merging 

Change in topology and link failure as a trigger for normalization, unless member LSPs go down 
Egress protection on container LSP 

Container LSP as a backup LSP for IGP interface 

Container LSP as provider tunnel for multicast VPNs 


Dynamic LSPs for normalization 
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CCC using container LSP 

Secondary paths for container LSP 

Bidirectional container LSP 

Policing 

Static routes using container LSPs as next hops on a best-effort basis 
External path computing entity, such as PCE 

Multichassis 


IPvé 


Example: Configuring Dynamic Bandwidth Management Using Container LSP 


IN THIS SECTION 


Requirements | 620 
Overview | 621 
Configuration | 621 


Verification | 633 


This example shows how to enable dynamic bandwidth management by configuring container label-switched 


paths (LSPs) that enable load balancing across multiple point-to-point member LSPs. 


Requirements 


This example uses the following hardware and software components: 


Five routers that can be a combination of M Series, MX Series, or T Series routers, out of which two 
routers are provider edge (PE) routers and three routers are provider (P) routers 


e Junos OS Release 14.2 or later running on all the routers 


Before you begin: 


1. 
2. 


Configure the device interfaces. 


Configure the autonomous system numbers and router IDs for the devices. 


. Configure the following protocols: 


e RSVP 
e MPLS 
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e BGP 
e OSPF 


Overview 


Starting with Junos OS Release 14.2, a new type of LSP, called a container LSP, is introduced to enable 
load balancing across multiple point-to-point LSPs. A container LSP includes one or more member LSPs 
between the same ingress and egress routing devices. The member LSPs are similar to independent 
point-to-point LSPs, and each member LSP takes a different path to the same destination and can be 
routed along a different IGP cost path. 


A container LSP provides support for dynamic bandwidth management by enabling the ingress router to 
dynamically add and remove member LSPs through a process called LSP splitting and LSP merging, 
respectively, based on configuration and aggregate traffic. Besides addition and deletion, member LSPs 
can also be re-optimized with different bandwidth values in a make-before-break way. 


Topology 
Figure 47 on page 621 is a sample topology configured with container LSPs. 


Figure 47: Dynamic Bandwidth Management Using Container LSP 


40.40.40.2/24 P3 70.70.70.2/24 
ge-0/0/2 ge-0/0/3 


ge-0/0/0 ge-0/0/1 
50.50.50.2/24 60.60.60.2/24 


40.40.40.1/24 50.50.50.1/24 60.60.60.1/24 70.70.70.1/24 
ge-0/0/2 ge-0/0/0 ge-0/0/1 ge-0/0/3 
10.10.10.1/24 — 10.10.10.2/24 20.20.20.1/24 20.20.20.2/24 30.30.30.1/24 30.30.30.2/24 
ge-0/0/1 ge-0/0/1 ge-0/0/2 ge-0/0/2 ge-0/0/0 ge-0/0/0 
PE 1} 1.1.1.1/24 Pl P2 2.2.2.1/24| PE 2 
ge-0/0/0 ge-0/0/1 
loO: 


PE1 10.255.102.166/32 
Pl 10.255.102.152/32 
P2 10.255.102.29/32 
P3  10.255.102.182/32 
PE 2 10.255.102.128/32 
Host 1 Host 2 
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In this example, Routers PE1 and PE2 are the PE routers connected to hosts Host1 and Host2, respectively. 
The core routers, Routers P1, and P2, and P3 connect to the PE routers. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


PE1 


set interfaces ge-0/0/0 unit 0 family inet address 1.1.1.1/24 

set interfaces ge-0/0/1 unit 0 family inet address 10.10.10.1/24 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 40.40.40.1/24 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.102.166/32 

set interfaces loO unit O family mpls 

set routing-options router-id 10.255.102.166 

set routing-options autonomous-system 1234 

set routing-options forwarding-table export pplb 

set protocols rsvp preemption aggressive 

set protocols rsvp interface all aggregate 

set protocols rsvp interface fxp0.0 disable 

set protocols rsvp interface ge-0/0/1.0 

set protocols rsvp interface ge-0/0/2.0 

set protocols mpls statistics file auto-bw 

set protocols mpls statistics file size 10m 

set protocols mpls statistics interval 10 

set protocols mpls statistics auto-bandwidth 

set protocols mpls label-switched-path PE1-to-PE2-template1 template 

set protocols mpls label-switched-path PE1-to-PE2-template1 optimize-timer 30 

set protocols mpls label-switched-path PE1-to-PE2-template1 link-protection 

set protocols mpls label-switched-path PE1-to-PE2-template1 adaptive 

set protocols mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth adjust-interval 300 

set protocols mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth adjust-threshold 5 

set protocols mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth minimum-bandwidth 
10m 

set protocols mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth maximum-bandwidth 
10m 

set protocols mpls container-label-switched-path PE1-PE2-container-100 label-switched-path-template 
PE1-to-PE2-template1 

set protocols mpls container-label-switched-path PE1-PE2-container-100 to 10.255.102.128 

set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
maximum-member-lsps 20 

set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
minimum-member-Isps 2 
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P1 


set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
splitting-bandwidth 40m 

set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
merging-bandwidth 6m 

set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
maximum-signaling-bandwidth 10m 

set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
minimum-signaling-bandwidth 10m 

set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
normalization normalize-interval 400 

set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
normalization failover-normalization 

set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
normalization normalization-retry-duration 20 

set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
normalization normalization-retry-limits 3 

set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging sampling 
cut-off-threshold 1 

set protocols mpls container-label-switched-path PE1-PE2-container-100 splitting-merging sampling 
use-percentile 90 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp group to-PE2 type internal 

set protocols bgp group to-PE2 local-address 10.255.102.166 

set protocols bgp group to-PE2 family inet-vpn unicast 

set protocols bgp group to-PE2 export direct 

set protocols bgp group to-PE2 neighbor 10.255.102.128 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 metric 100 

set policy-options policy-statement direct term 1 from protocol direct 

set policy-options policy-statement direct term 1 then accept 

set policy-options policy-statement pplb then load-balance per-packet 

set routing-instances vpn1 instance-type vrf 

set routing-instances vpn1 interface ge-0/0/0.0 

set routing-instances vpn1 route-distinguisher 10.255.102.166:1 

set routing-instances vpn1 vrf-target target:1:1 

set routing-instances vpn1 vrf-table-label 
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P2 


P3 


set interfaces ge-0/0/0 unit 0 family inet address 50.50.50.1/24 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 10.10.10.2/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 20.20.20.1/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.102.152/32 
set protocols rsvp interface all aggregate 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 metric 100 


set interfaces ge-0/0/0 unit 0 family inet address 30.30.30.1/24 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 60.60.60.1/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 20.20.20.2/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.102.29/32 
set protocols rsvp interface all aggregate 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls statistics file auto_bw 

set protocols mpls statistics file size 10m 

set protocols mpls statistics interval 5 

set protocols mpls statistics auto-bandwidth 

set protocols mpls icmp-tunneling 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 metric 100 
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PE2 


set interfaces ge-0/0/0 unit 0 family inet address 50.50.50.2/24 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 60.60.60.2/24 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 40.40.40.2/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 70.70.70.2/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.102.182/32 
set protocols rsvp interface all aggregate 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls icmp-tunneling 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


set interfaces ge-0/0/0 unit 0 family inet address 30.30.30.2/24 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 2.2.2.1/24 

set interfaces ge-0/0/3 unit 0 family inet address 70.70.70.1/24 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.102.128/32 
set interfaces loO unit O family mpls 

set routing-options router-id 10.255.102.128 

set routing-options autonomous-system 1234 

set protocols rsvp interface all aggregate 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp group to-PE1 type internal 

set protocols bgp group to-PE1 local-address 10.255.102.128 
set protocols bgp group to-PE1 family inet-vpn unicast 

set protocols bgp group to-PE1 neighbor 10.255.102.166 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 
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set policy-options policy-statement direct from protocol direct 
set policy-options policy-statement direct then accept 

set routing-instances vpn1 instance-type vrf 

set routing-instances vpn1 interface ge-0/0/1.0 

set routing-instances vpn1 route-distinguisher 10.255.102.128:1 
set routing-instances vpn1 vrf-target target:1:1 

set routing-instances vpn1 vrf-table-label 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Router PE1: 


1. Configure the Router PE1 interfaces. 


[edit interfaces] 

user@PE1# set ge-0/0/0 unit O family inet address 1.1.1.1/24 
user@PE1# set ge-0/0/1 unit 0 family inet address 10.10.10.1/24 
user@PE1# set ge-0/0/1 unit O family mpls 

user@PE1# set ge-0/0/2 unit O family inet address 40.40.40.1/24 
user@PE1# set ge-0/0/2 unit O family mpls 

user@PE1# set loO unit O family inet address 10.255.102.166/32 
user@PE1# set loO unit 0 family mpls 


2. Configure the router ID and autonomous system number for Router PE1. 
[edit routing-options] 


user@PE1# set router-id 10.255.102.166 
user@PE1# set autonomous-system 1234 


3. Enable the policy to load-balance traffic. 
[edit routing-options] 


user@PE1# set forwarding-table export pplb 


4. Enable RSVP on all Router PE1 interfaces (excluding the management interface). 
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[edit protocols] 

user@PE1# set rsvp preemption aggressive 
user@PE11# set rsvp interface all aggregate 
user@PE1# set rsvp interface fxp0.0 disable 
user@PE1# set rsvp interface ge-0/0/1.0 
user@PE1# set rsvp interface ge-0/0/2.0 


5. Enable MPLS on all the interfaces of Router PE1 (excluding the management interface). 


[edit protocols] 
user@PE1# set mpls interface all 
user@PE1# set mpls interface fxp0.0 disable 


6. Configure the MPLS statistics parameters. 


[edit protocols] 

user@PE1# set mpls statistics file auto-bw 
user@PE1# set mpls statistics file size 10m 
user@PE1# set mpls statistics interval 10 
user@PE1# set mpls statistics auto-bandwidth 


7. Configure the label-switched path (LSP) template parameters. 


[edit protocols] 

user@PE1# set mpls label-switched-path PE1-to-PE2-template1 template 

user@PE1# set mpls label-switched-path PE1-to-PE2-template1 optimize-timer 30 

user@PE1# set mpls label-switched-path PE1-to-PE2-template1 link-protection 

user@PE1# set mpls label-switched-path PE1-to-PE2-template1 adaptive 

user@PE1# set mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth adjust-interval 300 
user@PE1# set mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth adjust-threshold 5 
user@PE1# set mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth minimum-bandwidth 10m 
user@PE1# set mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth maximum-bandwidth 10m 


8. Configure a container LSP between Router PE1 and Router PE2, and assign the PE1-to-PE2-template1 
LSP template. 


[edit protocols] 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 to 10.255.102.128 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 label-switched-path-template 
PE1-to-PE2-template1 
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9. Configure the container LSP parameters. 


[edit protocols] 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
maximum-member-Isps 20 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
minimum-member-lIsps 2 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
splitting-bandwidth 40m 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
merging-bandwidth 6m 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
maximum-signaling-bandwidth 10m 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
minimum-signaling-bandwidth 10m 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization 
normalize-interval 400 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization 
failover-normalization 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization 
normalization-retry-duration 20 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization 
normalization-retry-limits 3 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging sampling 
cut-off-threshold 1 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging sampling 
use-percentile 90 


10. Configure the BGP group, and assign the local and neighbor IP addresses. 


[edit protocols] 

user@PE1# set bgp group to-PE2 type internal 

user@PE1# set bgp group to-PE2 local-address 10.255.102.166 
user@PE1# set bgp group to-PE2 neighbor 10.255.102.128 
user@PE1# set bgp group to-PE2 family inet-vpn unicast 
user@PE1# set bgp group to-PE2 export direct 


11. Enable OSPF on all the interfaces of Router PE1 (excluding the management interface) along with traffic 
engineering capabilities. 


[edit protocols] 
user@PE1# set ospf traffic-engineering 
user@PE1# set ospf area 0.0.0.0 interface all 
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user@PE1# set ospf area 0.0.0.0 interface fxp0.0 disable 
user@PE1# set ospf area 0.0.0.0 interface ge-0/0/2.0 metric 100 


12. Configure the policy statement to load-balance traffic. 


[edit policy-options] 

user@PE1# set policy-statement direct term 1 from protocol direct 
user@PE11# set policy-statement direct term 1 then accept 
user@PE1# set policy-statement pplb then load-balance per-packet 


13. Configure a routing instance on Router PE1, and assign the routing instance interface. 


[edit routing-instances] 
user@PE1# set vpni instance-type vrf 
user@PE1# set vpn1 interface ge-0/0/0.0 


14. Configure the route distinguisher, vrf target, and vrf-table label values for the VRF routing instance. 


[edit routing-instances] 

user@PE1# set vpni route-distinguisher 10.255.102.166:1 
user@PE1# set vpn1 vrf-target target:1:1 

user@PE1# set vpn1 vrf-table-label 


Results 

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 
show protocols, show policy-options, and show routing-options commands. If the output does not display 
the intended configuration, repeat the instructions in this example to correct the configuration. 


user@PE1# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 1.1.1.1/24, 


} 
ge-0/0/1 { 
unit O { 
family inet { 


address 10.10.10.1/24; 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 40.40.40.1/24; 
} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 10.255.102.166/32; 
} 


family mpls; 


user@PE1# show routing-options 
router-id 10.255.102.166; 
autonomous-system 1234; 
forwarding-table { 

export pplb; 


user@PE1# show protocols 
rsvp { 
preemption aggressive; 
interface all { 
aggregate; 
} 
interface fxp0.0 { 
disable; 
} 
interface ge-0/0/1.0; 
interface ge-0/0/2.0; 
} 
mpls { 
statistics { 
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file auto-bw size 10m; 
interval 10; 
auto-bandwidth; 
} 
label-switched-path PE1-to-PE2-template1 { 
template; 
optimize-timer 30; 
link-protection; 
adaptive; 
auto-bandwidth { 
adjust-interval 300; 
adjust-threshold 5; 
minimum-bandwidth 10m; 
maximum-bandwidth 10m; 


} 
container-label-switched-path PE1-PE2-container-100 { 
label-switched-path-template { 
PE1-to-PE2-template1; 
} 
to 10.255.102.128; 
splitting-merging { 
maximum-member-Isps 20; 
minimum-member-lsps 2; 
splitting-bandwidth 40m; 
merging-bandwidth 6m; 
maximum-signaling-bandwidth 10m; 
minimum-signaling-bandwidth 10m; 
normalization { 
normalize-interval 400; 
failover-normalization; 
normalization-retry-duration 20; 
normalization-retry-limits 3; 
} 
sampling { 
cut-off-threshold 1; 


use-percentile 90; 


} 

interface all; 

interface fxp0.0 { 
disable; 


631 


} 
bgp { 
group to-PE2 { 
type internal; 
local-address 10.255.102.166; 
family inet-vpn { 
unicast; 

} 
export direct; 
neighbor 10.255.102.128; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 
} 
interface ge-0/0/2.0 { 
metric 100; 


user@PE1# show policy-options 
policy-statement direct { 
term 1 { 
from protocol direct; 
then accept; 


} 
policy-statement pplb { 
then load-balance { 
per-packet; 


user@PE1# show routing-instances 
vpni { 
instance-type vrf; 
interface ge-0/0/0.0; 
route-distinguisher 10.255.102.166:1; 
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vrf-target target:1:1; 
vrf-table-label; 


Verification 


IN THIS SECTION 


Verifying the Container LSP Status Without Bandwidth | 633 

Verifying the Container LSP Status with Increased Bandwidth (Before Normalization) | 637 
Verifying the Container LSP Status with Increased Bandwidth (After Normalization) | 639 
Verifying the Container LSP Splitting Process | 644 

Verifying the Container LSP Statistics | 644 

Verifying the Container LSP Status with Decreased Bandwidth (Before Normalization) | 645 
Verifying the Container LSP Status with Decreased Bandwidth (After Normalization) | 645 
Verifying the Container LSP Merging Process | 646 


Verifying Failover Normalization | 647 


Verifying Incremental Normalization | 648 


Confirm that the configuration is working properly. 


Verifying the Container LSP Status Without Bandwidth 


Purpose 


Verify the status of the container LSP. 
Action 


From operational mode, run the show mpls container-Isp extensive command. 








user@PE1> show mpls container-lsp extensiv 


Ingress LSP: 1 sessions 














Container LSP name: PE1-PE2-container-100, State: Up, Member count: 2 
Normalization 

Min LSPs: 2, Max LSPs: 20 

Aggregate bandwidth: 20Mbps, Sampled Aggregate bandwidth: Obps 


NormalizeTimer: 400 secs, NormalizeThreshold: 10% 


Max Signaling BW: 10Mbps, Min Signaling BW: 10Mbps, Splitting BW: 40Mbps, Merging 
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BW: 6Mbps 





Mode: incremental-normalization, failover-normalization 
Sampling: Outlier cut-off 1, Percentile 90 of Aggregate 
Normalization in 143 second(s) 


36 dina 3 W!gi2cily7 497 Cleare Maisiomy Bincl SracisicLess Cin COmeciinere 








(PE1—-PE2-container-100) 








35 Jun 5 04:12:17.497 Avoid normalization: not needed with bandwidth 0 bps 

34 Jun 5 04:05:37.484 Clear history and statistics: on container 
(PE1-PE2-container-100) 

33 Jun 5 04:05:37.484 Avoid normalization: not needed with bandwidth 0 bps 

















32 gua 5 OssSe8ies7.4A70 Clear inigtomy aincl SiteiciSsitiess Cin COME ine 
(PE1—-PE2-container-100) 
31 Jun 5 03:58:57.470 Avoid normalization: not needed with bandwidth 0 bps 
50 guia 8 OSeSz2Zc17 455 Cileeie InisSitemy Glncl SiGe S2 Cin CwimecisinSic 
(PE1—-PE2-container-100) 
29 Jun 5 03:52:17.455 Avoid normalization: not needed with bandwidth 0 bps 














As doa 8 WSsgtoe37 440 Clear IMScOrmy Eine SIEAIISENMCS2 Cm COME iMSie 








(PE1-PE2-container-100) 











27 Jun 5 03:45:37.440 Avoid normalization: not needed with bandwidth 0 bps 














26 Jun 5 03:38:59.013 Normalization complete: container (PE1-PE2-container-100) 





with 2 members 





25 Jun 5 03:38:57.423 Delete member LSPs: PE1-PE2-container-100-3 through 




















PE1-PE2-container-100-7 











24 Jun 5 03:38:57.423 Normalize: container (PEI1-PE2-container-100) create 2 


LSPs, min bw 10000000bps, member count 7 











23 Jun 5 03:38:57.423 Normalize: normalization with aggregate bandwidth 0 bps 














22 Jun 5 03:32:19.019 Normalization complete: container (PE1-PE2-container-100) 





with 7 members 
ai som B OSss2si7) 404 Clear inmisitery incl SIEAEISIENeSs Om COME MSc 
(PE1-PE2-container-100) 
20 Jun 5 03:32:17.403 Normalize: container (PE1—PE2-container-100) into 7 
members — each with bandwidth 10000000 bps 
19 Jun 5 03:32:17.403 Normalize: normalization with aggregate bandwidth 62914560 


























bps 
18 Jun 5 03:32:17.403 Normalize: normalizaton with 62914560 bps 











17 Jun 5 03:32:09.219 Normalization complete: container (PE1-PE2-container-100) 





with 7 members 
16 win 8 OSsS2°907,600 Cleee Iniistomy anc StecLsindess OM CoOMraLiMee 
(PE1—-PE2-container-100) 
15 Jun 5 03:32:07.600 Normalize: container (PE1—-PE2-container-100) into 7 
members — each with bandwidth 10000000 bps 
14 Jun 5 03:32:07.599 Normalize: normalization with aggregate bandwidth 62914560 


























bps 
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13 Jun 5 03:32:07.599 Normalize: normalizaton with 62914560 bps 
12 iia 8 OS¢26S57,295 Clea Inistory aimcl SECIELSIELOSs Oi CoOiMirALinSie 
(PE1—-PE2-container-100) 











11 Jun 5 03:26:57.295 Avoid normalization: not needed with bandwidth 0 bps 








10 Jun 5 03:20:18.297 Normalization complete: container (PE1-PE2-container-100) 











with 2 members 





9 Jun 5 03:20:17.281 Normalize: container (PE1-PE2-container-100) create 2 
LSPs, min bw 10000000bps, member count 0 











8 Jun 5 03:20:17.281 Normalize: normalization with aggregate bandwidth 0 bps 





















































7 wun 4 OS9il7s43.218 Clear Mistery ging StAcISELeSs Om CoOMEcLMaIe 
(PE1—-PE2-container-100) 

6 Jun 5 03:17:43.218 Avoid normalization: not needed with bandwidth 0 bps 

DEJ Unm om OS cise eNO mmcalekac em CoOnt ances (DE e Eh — COnmtcHimcts—k0\0) meiacecun ice! 
PathErr on member PE1—-PE2-container-100-2 

AS Juno O0s Ase le Nommnalazemcontatmcwa (DE Pla —ContcHmecis— 00) meineecunica 
PathErr on member PE1—-PE2-container-100-1 














3 Jun 5 03:12:47.323 Normalization complete: container (PE1-PE2-container-100) 














with 2 members 





2 Jun 5 03:12:16.555 Normalize: container (PE1—-PE2-container-100) create 2 
LSPs, min bw 10000000bps, member count 0 











1 Jun 5 03:12:16.555 Normalize: normalization with aggregate bandwidth 0 bps 


10.255 ¢ LOZ. 128) 
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1—-PE2-container-100-1 














ActivePath: (primary) 
LSPtype: Dynamic Configured, Penultimate hop popping 





LoadBalance: Random 

Autobandwidth 

inBW: 10Mbps, MaxBW: 10Mbps 

AdjustTimer: 300 secs 

Max AvgBW util: Obps, Bandwidth Adjustment in 12 second(s). 

Overflow limit: 0, Overflow sample count: 0 

Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: Obps 
Encoding type: Packet, Switching type: Packet, GPID: IPv4 





— 


Primary Siedler mo 
IiealonesicalLeysj3 7 (0) 
Bandwidth: 10Mbps 


SmartOptimizeTimer: 180 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
10.10.1052 8 20,20.20.2 S S0.30.30.2 8 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID): 
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1M 10.10.82 20,20.20.2 30.30.30 .2 
17 Jun 5 03:38:59.013 Make-before-break: Switched to new instance 
16 Jum 8 OSssse5S.,.005 Racord Reowcres 10.,.10,10.2 20.20.2022 30.30.30.2 
LS OU OMmOS 59 ocr 00S mu 
14 Jun 5 03:38:57.423 Originate make-before-break call 


is vpn 5 USs3tiea/],.423 Css cemoucacaem masmlc accsececl 10, 10,10,.2 20,20 .,20.,2 
SU Ore Ore 


12 Jun 5 03:33:30.400 CSPF: computation result ignored, new path no benefit 
11 Jun 5 03:32:17.403 Pending old path instance deletion 

10 Jun 5 03:32:09.218 Make-before-break: Switched to new instance 

9 sum 5 OF332808.202 Record ikowtres 10,10.10.2 20.20.20.2 30.30.50.2 

S ou 2 OSFS2908.,202 Wye 

7 Jun 5 03:32:07.603 Originate make-before-break call 








6 Jun 5 OSesz2507. 603 Ces conjowiecicilem mesmilc acceorecl 10,.10.10.2 20.20 20.2 
SOR ORS OR 


5 Jun 5 03:20:18.278 Selected as active path 

A dom «89S OS8Z20elS 277 Reco Rouse I0.10,10,2 20,20,20.2 30.30.3042 
3 Jue 5 OS3SZ0sls.277 We 

2 dum 85 OSs20cly., 281 Oragameacre Calli 


i gun 5 OSe20eil7/ 291 CSeus Coniowicetiem mesulli: aoceocecd I0,10.10,.2 20.20.20.2 
SOs ORS OR2 
Created: Thu Jun 5 03:20:16 2014 


10.255 ¢ OZ . 128) 
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1—-PE2-container-100-2 














ActivePath: (primary) 
LSPtype: Dynamic Configured, Penultimate hop popping 





LoadBalance: Random 

Autobandwidth 

inBW: 10Mbps, MaxBW: 10Mbps 

AdjustTimer: 300 secs 

Max AvgBW util: Obps, Bandwidth Adjustment in 76 second(s). 

Overflow limit: 0, Overflow sample count: 0 

Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: Obps 
Encoding type: Packet, Switching type: Packet, GPID: IPv4 





— 


Primary Siedler mo 
IiealonesicalLeysj3 7 (0) 
Bandwidth: 10Mbps 


SmartOptimizeTimer: 180 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
10.10.1052 8 20,20.20.2 S S0.30.30.2 8 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID): 





ale; 
16 
1S 
14 
13 


SOURS OR SU 


12 
il 
10 
$) 
8 
7 
6 
SOR 
5 
4 
3 
2 
iL 


Created: 


Jun 
Jun 
Jun 
Jun 


Jun 


Jun 
Jun 
Jun 
Jun 


Jun 





Jun 


Jun 


ORSS0R 


Jun 
Jun 
Jun 
Jun 


Jun 


Gl Sm Gal Any eS) 


oll. 
OS 
Oss 
Ose 
OBE 
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LO 64 20,20 .20.2 30.30.5054 


38 


S88 
Bor 
Siok 


£59. 
58. 
Se 
BT. 


013 Make-before-break: Switched to new instance 

O02 iracowe Rowtes LOO I10.2 20,20, 20.2 S0.30.30.2 
002 Up 

423 Originate make-before-break call 





DROSS Sov See SPE Complliscie HOnmEe Stllemac CepiEc Caml Onel Opal Or me O re] 0br a0) be 


2 


5 03:33:26.189 CSPF: computation result ignored, new path no benefit 


5 
5 
5) 
S) 
eS) 


Oss 
Oss 
OBE: 
OB 
OBE 


B25 
B28 
S25 
Sak 
Se 


Lys 
09. 
08. 
08. 
Oe 


403 Pending old path instance deletion 

219 Make-before-break: Switched to new instance 

AMA ineeerel IneurSes 10 ,10.10,2 20.20.20.2 30.30.50.2 
204 Up 

603 Originate make-before-break call 





5 OS332907.60S CSPNs coaiomratiem mesuli aceeorecl 10,10.10,2 20.20,.20.2 


2 


5 
S) 
5) 
eS) 


OS 
OS 
ORE: 
OBE 


210) 8 
0) § 
AOS 
eae: 


18 
18 
18 
7 


.297 Selected as active path 

A995 ISCO IRewESs I0.10.10,.2 20,20.20.2 30.30.3062 
5295 Wis 

.281 Originate Call 


5 OSe2O0sl7 28 CSPrs Conomration mesult acceoeced 10 .,10.10,2 20,20.20.2 
SOs ORS OR2 


Thu Jun 


5 


WSeA0sio 2ole 


Total 2 displayed, Up 2, Down 0 








Meaning 


CES SS INS. s 


ISeioSalic, ISPs 


0 sessions 


Total 0 displayed, Up 0, Down 0 


0 sessions 


Total 0 displayed, Up 0, Down 0 


The container LSP is established between Routers PE1 and PE2. 


Verifying the Container LSP Status with Increased Bandwidth (Before Normalization) 


Purpose 


Verify the status of the container LSP with increased bandwidth before normalization happens. 


Action 


From operational mode, run the show mpls container-Isp extensive command. 





user@P! 





E1> show mpls container-lsp extensiv 


638 


Ingress LSP: 1 sessions 














Container LSP name: PE1-PE2-container-100, State: Up, Member count: 2 


Normalization 

Min LSPs: 2, Max LSPs: 20 

Aggregate bandwidth: 20Mbps, Sampled Aggregate bandwidth: 42.6984Mbps 
NormalizeTimer: 400 secs, NormalizeThreshold: 10% 


Max Signaling BW: 10Mbps, Min Signaling BW: 10Mbps, Splitting BW: 40Mbps, Merging 
BW: 6Mbps 





Mode: incremental-normalization, failover-normalization 
Sampling: Outlier cut-off 1, Percentile 90 of Aggregate 


Normalization in 321 second(s) 





3 Jun 5 21:22:34.731 Normalization complete: container (PE1-PE2-container-100) 











with 2 members 





2 Jun 5 21:22:15.503 Normalize: container (PEI1—-PE2-container-100) create 2 
LSPs, min bw 10000000bps, member count 0 











1 Jun 5 21:22:15.503 Normalize: normalization with aggregate bandwidth 0 bps 


IO) s BDS 6 M4 5 WAS) 





From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1—-PE2-container-100-1 











ActivePath: (primary) 
Link protection desired 


LSPtype: Dynamic Configured, Penultimate hop popping 





LoadBalance: Random 

Autobandwidth 

MinBW: 10Mbps, MaxBW: 10Mbps 

AdjustTimer: 300 secs AdjustThreshold: 5% 

Max AvgBW util: 23.9893Mbps, Bandwidth Adjustment in 221 second(s). 
Overflow limit: 0, Overflow sample count: 6 

Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: Obps 
Encoding type: Packet, Switching type: Packet, GPID: IPv4 

Primary State: Up 

Iiealonedlic dese 7 (0) 


Bandwidth: 10Mbps 


+ 





OptimizeTimer: 30 
SmartOptimizeTimer: 180 


Reoptimization in 9 second(s). 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
LO .LO.10,2 S 20.-20,.20.2 S S0,30.30.2 S 





Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID): 
10.255.102.166(flag=0x20) 10.10.10.2 (Label=303440) 


ORAZ Dior Oza  cedlecig — Ox 0) ae On AOrAOren (i alo cil 0) 254 4) OFZ > OPO Zr aban Erlkaig—O57\0)) 
505505 MO 54 (ihetove1L=3))) 


ID ASS o OZ Las 





From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1—-PE2-container-100-2 











ActivePath: (primary) 
Link protection desired 


LSPtype: Dynamic Configured, Penultimate hop popping 





LoadBalance: Random 

Autobandwidth 

MinBW: 10Mbps, MaxBW: 10Mbps 

AdjustTimer: 300 secs AdjustThreshold: 5% 

ax AvgBW util: 22.1438Mbps, Bandwidth Adjustment in 221 second(s). 
Overflow limit: 0, Overflow sample count: 6 

Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: Obps 
Encoding type: Packet, Switching type: Packet, GPID: IPv4 

Primary Siesieee Wis 





+ 


Picwouesicaiese 7 O 
Bandwidth: 10Mbps 
OptimizeTimer: 30 
SmartOptimizeTimer: 180 


Reoptimization in 9 second(s). 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
1O.10.10,2 S 20.20.20.2 S 30.30.30.2 8 


Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID): 





IM 2555102. 166 GElacg=Ox20)) 10, 10, 10.4 Chaloel=s0 3456) 


IM ASS 6102. AD (elac=O>220) 20.20.2054 (heloSsl=S04L60)) 10.2555 104. LAG (Gt ilec=Os<20)) 
310 2 50) 5 MO, 2 Chaloe l= 3) 


Total 2 displayed, Up 2, Down 0 


Meaning 


Because normalization has not happened, the member LSP count remains at 2. 
Verifying the Container LSP Status with Increased Bandwidth (After Normalization) 


Purpose 


Verify the status of the container LSP with increased bandwidth after normalization happens. 


Action 


From operational mode, run the show mpls container-Isp extensive command. 








user@PE1> show mpls container-lsp extensiv 
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I 
ic 
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ngress LSP: 1 sessions 














ontainer LSP name: PE1-PE2-container-100, State: Up, Member count: 5 
Normalization 

MELioy ISIS 25 INGe UNS o 210) 

Aggregate bandwidth: 50Mbps, Sampled Aggregate bandwidth: 45.8873Mbps 
NormalizeTimer: 400 secs, NormalizeThreshold: 10% 


Max Signaling BW: 10Mbps, Min Signaling BW: 10Mbps, Splitting BW: 40Mbps, Merging 


BW: 6Mbps 





Mode: incremental-normalization, failover-normalization 
Sampling: Outlier cut-off 1, Percentile 90 of Aggregate 


Normalization in 169 second(s) 





7 Jun 5 21:29:02.921 Normalization complete: container (PE1-PE2-container-100) 











with 5 members 


6 dutin § Bile2schs. 505 Clear MiSitomy MAG SEACUSELCSs Oi COMcaLineic 











(PE1—-PE2-container-100) 








5 Jun 5 21:28:55.505 Normalize: container (PE1—-PE2—container-100) into 5 











members — each with bandwidth 10000000 bps 


4 Jun 5 21:28:55.504 Normalize: normalization with aggregate bandwidth 45281580 


bps 














3 Jun 5 21:22:34.731 Normalization complete: container (PE1—-PE2-container-100) 


with 2 members 





2 Jun 5 21:22:15.503 Normalize: container (PE1—-PE2-container-100) create 2 











LSPs, min bw 10000000bps, member count 0 


1 Jun 5 21:22:15.503 Normalize: normalization with aggregate bandwidth 0 bps 


ID -A55 ¢O2 . Las 


+ 





From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1—-PE2-container-100-1 











ActivePath: (primary) 
Link protection desired 


LSPtype: Dynamic Configured, Penultimate hop popping 





LoadBalance: Random 

Autobandwidth 

MinBW: 10Mbps, MaxBW: 10Mbps 

AdjustTimer: 300 secs AdjustThreshold: 5% 

ax AvgBW util: 11.0724Mbps, Bandwidth Adjustment in 129 second(s). 
Overflow limit: 0, Overflow sample count: 1 

Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: Obps 
Encoding type: Packet, Switching type: Packet, GPID: IPv4 

Primary Sieslces Wis 





Priorities: 7 0 
Bandwidth: 10Mbps 
OptimizeTimer: 30 


SmartOptimizeTimer: 180 
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Reoptimization in 12 second(s). 

Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
10,10,.10,2 S 20.20.20.2 8S 50.30.3062 § 

Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 








20=Node-ID): 
10.255.102.166(flag=0x20) 10.10.10.2 (Label=303488) 
OZ SSO 22 o Calkag— 020) meee 0m Ona (haloelk— 302 24) ean oll Oi euler sa Gilkarg— Ose210)) 


50.505 M054 (hase 13) 


10.255. 102 , 123 
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1—-PE2-container-100-2 














ActivePath: (primary) 
Link protection desired 


LSPtype: Dynamic Configured, Penultimate hop popping 





LoadBalance: Random 

Autobandwidth 

MinBW: 10Mbps, MaxBW: 10Mbps 

AdjustTimer: 300 secs AdjustThreshold: 5% 

Max AvgBW util: 8.50751Mbps, Bandwidth Adjustment in 189 second(s). 
Overflow limit: 0, Overflow sample count: 0 


Underflow limit: 0, Underflow sample count: 11, Underflow Max AvgBW: 8.50751Mbps 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 
ee INE Seaces Ws 
Iiealonedicaeysye 7 (0) 
Bandwidth: 10Mbps 
OptimizeTimer: 30 
SmartOptimizeTimer: 180 
Reoptimization in 6 second(s). 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
LO.1O.10,2 S 20.20.20.2 § S0.30,30.2 § 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID): 
10.255.102.166 (flag=0x20) 10.10.10.2 (Labe1l=303504) 
10.255.102.29(flag=0x20) 20.20.20.2 (Label=302240) 10.255.102.128 (flag=0x20) 
30.30.30.2 (Label=3) 








10.255) 6 IM0Z 2's 
From: 110.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1—-PE2-container-100-3 














ActivePath: (primary) 


Link protection desired 





LSPtype: Dynamic Configured, Penultimate hop popping 
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LoadBalance: Random 

Autobandwidth 

MinBW: 10Mbps, MaxBW: 10Mbps 

AdjustTimer: 300 secs AdjustThreshold: 5% 

ax AvgBW util: 9.59422Mbps, Bandwidth Adjustment in 249 second(s). 
Overflow limit: 0, Overflow sample count: 0 


Underflow limit: 0, Underflow sample count: 5, Underflow Max AvgBW: 9.59422Mbps 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


+ 





Primary SieeieSe Wis) 
Priorities: 7 
Bandwidth: 10Mbps 
OptimizeTimer: 30 
SmartOptimizeTimer: 180 
Reoptimization in 25 second(s). 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
LO 10.1052 S 20.20.2022 S S0.30,.30.2 § 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 








20=Node-ID): 

10.255.102.166 (flag=0x20) 10.10.10.2 (Labe1l=303472) 
10.255.102.29(flag=0x20) 20.20.20.2 (Label=302176) 10.255.102.128 (flag=0x20) 
30.30.30.2 (Label=3) 


10.255 - LOZ. 128) 
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1—-PE2-container-100-4 














ActivePath: (primary) 
Link protection desired 


LSPtype: Dynamic Configured, Penultimate hop popping 





LoadBalance: Random 

Autobandwidth 

MinBW: 10Mbps, MaxBW: 10Mbps 

AdjustTimer: 300 secs AdjustThreshold: 5% 

Max AvgBW util: 9.16169Mbps, Bandwidth Adjustment in 9 second(s). 
Overflow limit: 0, Overflow sample count: 0 


Underflow limit: 0, Underflow sample count: 29, Underflow Max AvgBW: 9.16169Mbps 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





+ 


Primary State: Up 
Pig o te tese sis 70) 
Bandwidth: 10Mbps 
OptimizeTimer: 30 
SmartOptimizeTimer: 180 


Reoptimization in 1 second(s). 
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Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
LO 10-102 S$ 20,.20,.20.2 S S0.30.30,.2 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 








20=Node-ID): 
10.255.102.166(flag=0x20) 10.10.10.2 (Label=303520) 
ORAS Srl) 2062195 (Gea —0sc2.0) ZO 0m Oma (haloeie— oO) 7sk9 2) Oe Sop lOe Eales (Gileag— Ose210)) 


SOS One iOr an Ckalloeile—3)) 


10.255 ¢ 102 . 128 
From: 10.255.102.166, State: Up, ActiveRoute: 0, LSPname: PE1—-PE2-—container-100-5 














ActivePath: (primary) 
Link protection desired 


LSPtype: Dynamic Configured, Penultimate hop popping 





LoadBalance: Random 

Autobandwidth 

MinBW: 10Mbps, MaxBW: 10Mbps 

AdjustTimer: 300 secs AdjustThreshold: 5% 

Max AvgBW util: 8.39908Mbps, Bandwidth Adjustment in 69 second(s). 
Overflow limit: 0, Overflow sample count: 0 


Underflow limit: 0, Underflow sample count: 23, Underflow Max AvgBW: 8.39908Mbps 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





bo 


Primary Seaces Wo 
Pirio@milries3s 7 
Bandwidth: 10Mbps 
OptimizeTimer: 30 
SmartOptimizeTimer: 180 
Reoptimization in 17 second(s). 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
LO 1O.L052 S 20.20.2022 S S0.30,.30.2 § 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 








20=Node-ID): 

10.255.102.166(flag=0x20) 10.10.10.2 (Label=303536) 
10.255.102.29(flag=0x20) 20.20.20.2 (Label=302208) 10.255.102.128 (flag=0x20) 
30.30.30.2 (Label=3) 
Total 5 displayed, Up 5, Down 0 


Egress LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 
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Meaning 
At the expiry of the normalization timer, the container LSP is split into five member LSPs, each with 10 
Mbps (minimum and maximum signaling bandwidth). As a result, the aggregate bandwidth is 50 Mbps. 


Verifying the Container LSP Splitting Process 


Purpose 


Verify the container LSP splitting process after normalization happens. 
Action 


From operational mode, run the show route 2.2.2 command. 





user@PE1> show route 2.2.2 


vpnl.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) 


+ = Active Route, Last Active, * = Both 








2 D562 O/ Ze ePXEP/L7O]| OMsl2gla, ocelot 100, trom 10.255,102,128 





AS path: I, validation-state: unverified 
>to 10.10.10.2 via ge-0/0/1.0,label-switched-path PE1-PE2-container100-1 
EO IO,10.10.2 wia ge-0/0/ 1 label-switched-path PE1-PE2-container100-2 


oO, 

COMO LO OMe mavacege— 0/0 ele O 

to 10.10.10.2 via ge-0/0/1.0, label-switched-path PE1-PE2-container100-4 
5 O, 




















label-switched-path PE1-PE2-container100-3 


to 10.10.10.2 via ge-0/0/1 label-switched-path PE1-PE2-container100-5 


Meaning 
After LSP splitting, Router PE1 has injected the forwarding adjacency. 


Verifying the Container LSP Statistics 


Purpose 


Verify the container LSP statistics after normalization happens. 
Action 


From operational mode, run the show mpls container-Isp statistics command. 





user@PE1> show mpls container-lsp statistics 


Ingress LSP: 1 sessions 














Container LSP name State Member LSP count 
PE1—-PE2-container-100 Up 5 
To From State Packets Bytes LSPname 


ID A556 LOZ , ILAals LO 25851025166 wie TESCO ZW/el 2062612856 
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PE1—-PE2-container-100-1 

IO 2555102. 12s LO, 259>o102.166 Up 12239902 1671428032 
PE1-PE2-container-100-2 
10.255 5102 .12¢ LO 259,102,166 We 13866911 1885899896 
PE1-PE2-—container-100-3 
10.255 .102, 128 LO 255,102,166 Ws 12553707 1707984152 
PE1-PE2-container-100-4 
10.255 4102 128 LO 2590102 .166 Wp LU5SI21 51 1565552536 


PEIS-Pr2 Container 00>5 

































































Meaning 


Traffic is load-balanced across the newly created member LSPs. 


Verifying the Container LSP Status with Decreased Bandwidth (Before Normalization) 


Purpose 


Verify the status of the container LSP with decreased bandwidth before normalization happens. 
Action 


From operational mode, run the show mpls container-Isp detail command. 





user@PE1> show mpls container-lsp detail 


Ingress LSP: 1 sessions 











Container LSP name: PE1—-PE2-container-100, State: Up, Member count: 5 





Normalization 

Min LSPs: 2, Max LSPs: 20 

Aggregate bandwidth: 50Mbps, Sampled Aggregate bandwidth: 2.0215Mbps 

NormalizeTimer: 400 secs, NormalizeThreshold: 10% 

Max Signaling BW: 10Mbps, Min Signaling BW: 10Mbps, Splitting BW: 40Mbps, Merging 
BW: 6Mbps 





Mode: incremental-normalization, failover-normalization 
Sampling: Outlier cut-off 1, Percentile 90 of Aggregate 
Normalization in 384 second(s) 


——— Oulu meEruUMCateC a 


Meaning 


Because normalization has not happened, the member LSP count remains at 5. 


Verifying the Container LSP Status with Decreased Bandwidth (After Normalization) 


Purpose 


Verify the status of the container LSP with decreased bandwidth after normalization happens. 
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Action 


From operational mode, run the show mpls container-Isp detail command. 





user@PE1> show mpls container-lsp detail 


Ingress LSP: 1 sessions 





Container LSP name: PE1-PE2-container-100, State: Up, Member count: 2 











Normalization 

MGKey ISISSSS 2 ING be TASES a 2710) 

Aggregate bandwidth: 20Mbps, Sampled Aggregate bandwidth: Obps 

NormalizeTimer: 400 secs, NormalizeThreshold: 10% 

Max Signaling BW: 10Mbps, Min Signaling BW: 10Mbps, Splitting BW: 40Mbps, Merging 
BW: 6Mbps 


Mode: incremental-normalization, failover-normalization 





Sampling: Outlier cut-off 1, Percentile 90 of Aggregate 


Normalization in 397 second(s) 
an som BF 22230637 W094 Clear iInistory incl SIEAICISELeSs Gm COME TiMaic 








(PE1-PE2-container-100) 
21 Jun 5 22:30:37.094 Delete member LSPs: PE1-PE2-container-100-3 through 








PE1-PE2-container-100-5 
20 Jun 5 22:30:37.090 Normalize: container (PHEI—-PE2-container-100) into 2 














members — each with bandwidth 10000000 bps 
19 Jun 5 22:30:37.090 Normalize: normalization with aggregate bandwidth 2037595 


bps 
i: vita 8 22630837 ,090 Nommelives mormalliveicom wwaltin 2Z0S7aIS loos 


OUD U EEE UMeateCd aaa 


Meaning 
At the expiry of the normalization timer, the container LSP merging takes place because there is an overall 
reduction in bandwidth. The member LSPs are merged, and the member LSP count is 2 after normalization. 


Verifying the Container LSP Merging Process 


Purpose 
Verify the container LSP splitting process after normalization happens. 


Action 


From operational mode, run the show route 2.2.2 command. 





user@PE1> show route 2.2.2 
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vpnl.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) 


+ = Active Route, Last Active, * = Both 








222. Of BE =(WE2/L7O]| OLeO@sas, loceilowet 100, trom 10.255. 102,128 
AS path: I, validation-state: unverified 
> to 10.10.10.2 via ge-0/0/1.0, label-switched-path 
PE1-PE2-container-100-1 
TO hOn Om hOnAavaltcmge— 0/10), ba OPeelabci— swaeclice—pciein 
PRI-PH2-Contalner— 10052 























Meaning 
After LSP merging, Router PE1 has deleted the merged member LSPs. 


Verifying Failover Normalization 


Purpose 


Verify load redistribution when traffic is sent at 35 Mbps and the link between Routers P1 and P2 is 
disabled. Arrival of PathErr on link failure triggers immediate normalization. 


To enable failover normalization, include the failover-normalization configuration statement at the [edit 
protocols mpls container-label-switched-path container-Isp-name splitting-merging normalization] 
hierarchy level. 


Action 


From operational mode, run the show mpls container-Isp command. 





user@PE1> show mpls container-lsp 


Ingress LSP: 1 sessions 


Container LSP name State Member LSP count 





PE1-PE2-container-100 Up 2 











(e) From State Rt P ActivePath LSPname 
10.255 102,128 10 .255,102,166 Wp @) + 

PE1-PE2-container-100-1 

10.255 ,102, 128 10.2559 5,102.166 Wp Ome 

PE1-PE2-container-100-2 























Total 2 displayed, Up 2, Down 0 


After the ge-0/0/2 link between Routers P1 and P2 goes down, normalization is immediately triggered. 


From operational mode, run the show mpls container-Isp detail command. 





user@PE1> show mpls container-lsp detail 
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Ingress LSP: 1 sessions 








Container LSP name: PE1-PE2-container-100, State: Up, Member count: 4 








Normalization 

Min ESPs; 2, Max LSPs; 20 

Aggregate bandwidth: 40Mbps, Sampled Aggregate bandwidth: 34.5538Mbps 
NormalizeTimer: 3000 secs, NormalizeThreshold: 10% 

Max Signaling BW: 10Mbps, Min Signaling BW: 10Mbps, Splitting BW: 40Mbps, Merging 
BW: 6Mbps 





Mode: incremental-normalization, failover-normalization 

Sampling: Outlier cut-off 1, Percentile 90 of Aggregate 

Normalization in 2970 second(s) 

11 Jun 5 19:28:27.564 Normalization complete: container (PE1-—PE2-container-100) 
with 4 members 

10 Jun 5 19:28:20.315 Normalize: container (PE1-PE2-container-100) received PathErr on member 
PE1-PE2-container-100-2[2 times] 

OS Uunw See se 20 esse Normals ear c ont amines (SE PE comtcemmer— 010) mereeer weal 



































PathErr on member PE1—-PE2-container-100-1[2 times] 
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(PE1—-PE2-container-100) 














7 Jun 5 19:28:20.311 Normalize: container (PE1—PE2-container-100) into 4 members 
— each with bandwidth 10000000 bps 
6 Jun 5 19:28:20.311 Normalize: normalization with aggregate bandwidth 33665020 





bps 
Seecunmeo le Nes Ose Normalize: Cont atncaan (EEE Pio come quince —l)\0)) mameeerave ck 




















PathErr on member PE1—-PE2-container-100-2 

















4 Jun 5 19:28:20.308 Normalize: container (PE1-PE2-container-100) received 














PathErr on member PE1—-PE2-container-100-1 

















3 Jun 5 19:27:48.574 Normalization complete: container (PE1-PE2-container-100) 





with 2 members 

















2 Jun 5 19:27:28.644 Normalize: container (PE1—-PE2-container-100) create 2 
LSPs, min bw 10000000bps, member count 0 

1 Jun 5 19:27:28.644 Normalize: normalization with aggregate bandwidth 0 bps 
=———OUEowIE iciebineeleeicl=——— 


Meaning 


Arrival of PathErr message on link failure triggers immediate normalization. 


Verifying Incremental Normalization 


Purpose 


Verify incremental normalization when enough bandwidth is not available. 


On Router PE1, the RSVP interfaces static bandwidth is restricted to 22 Mbps each. 


Action 


From operational mode, run the show rsvp interface command. 





user@PE1> show rsvp interface 


RSVP interface: 


Interface 
ge-0/0/2.0 
ge-0/0/1.0 


4 active 


Active 


State resv 


Up 
Up 


Before normalization happens: 


Sb siGis= 


iption 


100% 
100% 


Siealteslne 


BW 


22Mbps 
22Mbps 


Available 


BW 


22Mbps 
12Mbps 


From operational mode, run the show mpls container-Isp command. 





user@PE1> show mpls container-lsp 


IMCs IWS! 


1 sessions 


Container LSP name 





PE1-PE2-container-100 











To 


10.255 102, 128 
PE Pie Comecianc ras KO Oca: 
10.255 ,102, 128 
PE1-PE2-container-100-2 




















From 


LO) 5 ADS 


LO > 255 


After normalization happens: 


slO2 5 LOS 


OZR EGG 


State 


Up 


Up 


0 


0 


State 


Up 
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Reserved Highwater 
BW mark 

Obps 21.4031Mbps 
10Mbps AL, WO Misisss 


Member LSP count 


ActivePath 


From operational mode, run the show mpls container-Isp command. 





user@PE1> show mpls container-lsp 


Isle petessitsy ISIE" S 


1 sessions 


Container LSP name 





PE1—-PE2-container-100 
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oO gd 
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6 eo) Oie de 
aio oral 
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Oza! 
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02.61 
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28 
28 
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LO 52555 Wl 
LO 259.5 
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LO 259) 
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W251 
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State 


Up 


Active 


2 


LSPname 


Member LSP count 


9 


Path LSPname 


Dp 
Dp 


Dp 
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1) Oral 
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tainer-100-1 
tainer-100-2 
tainer-100-3 
tainer-100-4 
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Total 7 displayed, Up 6, Down 1 











From operational mode, run the show mpls container-Isp detail command. 





user@PE1> show mpls container-lsp detail 


Ingress LSP: 1 sessions 











Container LSP name: PE1-PE2-container-100, State: Up, Member count: 7 





Normalization 

Min SPs 2, Max iSes.)) 20 

Aggregate bandwidth: 40.8326Mbps, Sampled Aggregate bandwidth: 50.129Mbps 
NormalizeTimer: 9000 secs, NormalizeThreshold: 10% 

Max Signaling BW: 10Mbps, Min Signaling BW: 5Mbps, Splitting BW: 40Mbps, Merging 
BW: 5Mbps 





Mode: incremental-normalization, failover-normalization 
Sampling: Outlier cut-off 1, Percentile 90 of Aggregate 


Normalization in 8072 second(s) 














10 Jun 5 18:40:17.812 Normalization complete: container (PE1-PE2-container-100) 





with 7 members, retry-limit reached 


9 Jun 5 18:40:08.028 Normalize: container (PE1—-PE2-container-100) for target 





member count 7, member bandwidth 6805439 bps 











8 Jun 5 18:39:58.301 Normalize: container (PEI1-PE2—-container—-100) for target 
member count 6, member bandwidth 7939679 bps 





7 Jun 5 18:39:48.470 Clear history and statistics: on container 
(PE1—-PE2-container-100) 




















6 Jun 5 18:39:48.470 Normalize: container (PE1—-PE2-container-100) into 5 members 
—- each with bandwidth 9527615 bps 
5 Jun 5 18:39:48.469 Normalize: normalization with aggregate bandwidth 47638076 








bps 
4 Jun 5 18:39:48.469 Normalize: normalizaton with 47638076 bps 











3 Jun 5 18:39:09.471 Normalization complete: container (PE1—-PE2-container-100) 





with 2 members 





2 Jun 5 18:38:59.822 Normalize: container (PE1—-PE2-container-100) create 2 
LSPs, min bw 5000000bps, member count 0 











1 Jun 5 18:38:59.822 Normalize: normalization with aggregate bandwidth 0 bps 


Meaning 


After normalization, the aggregate bandwidth after three retries is 40.8326 Mbps. 
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Configuring Dynamic Bandwidth Management Using Container LSP 


You can configure a container LSP to enable load balancing across multiple point-to-point LSPs dynamically. 
A container LSP includes one or more member LSPs between the same ingress and egress routing devices. 
The member LSPs are similar to independent point-to-point LSPs, and each member LSP takes a different 
path to the same destination and can be routed along a different IGP cost path. 


A container LSP provides support for dynamic bandwidth management by enabling the ingress router to 
dynamically add and remove member LSPs through a process called LSP splitting and LSP merging, 
respectively, based on configuration and aggregate traffic. Besides addition and deletion, member LSPs 
can also be re-optimized with different bandwidth values in a make-before-break way. 


Before you begin: 


1. Configure the device interfaces. 
2. Configure the device router ID and autonomous system number. 
3. Configure the following protocols: 
e RSVP 
e BGP 
Configure a BGP group to peer device with remote provider edge (PE) device. 
e OSPF 


Enable traffic engineering capabilities. 
4. Configure a VRF routing instance. 
To configure the PE device: 


1. Enable MPLS on all the interfaces (excluding the management interface). 


[edit protocols] 
user@PE1# set mpls interface all 
user@PE1# set mpls interface fxp0.0 disable 


2. Configure the MPLS statistics parameters. 


[edit protocols] 

user@PE1# set mpls statistics file file-name 
user@PE1# set mpls statistics file size size 
user@PE1# set mpls statistics interval seconds 
user@PE1# set mpls statistics auto-bandwidth 
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3. Configure the label-switched path (LSP) template parameters. 


[edit protocols] 

user@PE1# set mpls label-switched-path template-name template 

user@PE1# set mpls label-switched-path template-name optimize-timer seconds 

user@PE1# set mpls label-switched-path template-name link-protection 

user@PE1# set mpls label-switched-path template-name adaptive 

user@PE1# set mpls label-switched-path template-name auto-bandwidth adjust-interval seconds 
user@PE1# set mpls label-switched-path template-name auto-bandwidth adjust-threshold seconds 
user@PE1# set mpls label-switched-path template-name auto-bandwidth minimum-bandwidth mbps 
user@PE1# set mpls label-switched-path template-name auto-bandwidth maximum-bandwidth mbps 


4. Configure a container LSP between the two PE routers, and assign the LSP template. 


[edit protocols] 

user@PE1# set mpls container-label-switched-path container-Isp-name to remote-PE-ip-address 

user@PE1# set mpls container-label-switched-path container-Isp-name label-switched-path-template 
template-name 


5. Configure the container LSP parameters. 


[edit protocols] 

user@PE1# set mpls container-label-switched-path container-Isp-name splitting-merging 
maximum-member-lsps number 

user@PE1# set mpls container-label-switched-path container-Isp-name splitting-merging 
minimum-member-lsps number 

user@PE1# set mpls container-label-switched-path container-Isp-name splitting-merging splitting-bandwidth 
mbps 

user@PE1# set mpls container-label-switched-path container-Isp-name splitting-merging merging-bandwidth 
mbps 

user@PE1# set mpls container-label-switched-path container-Isp-name splitting-merging 
maximum-signaling-bandwidth mbps 

user@PE1# set mpls container-label-switched-path container-Isp-name splitting-merging 
minimum-signaling-bandwidth mbps 

user@PE1# set mpls container-label-switched-path container-Isp-name splitting-merging normalization 
normalize-interval seconds 

user@PE1# set mpls container-label-switched-path container-Isp-name splitting-merging normalization 
failover-normalization 

user@PE1# set mpls container-label-switched-path container-Isp-name splitting-merging normalization 
normalization-retry-duration seconds 

user@PE1# set mpls container-label-switched-path container-Isp-name splitting-merging normalization 
normalization-retry-limits number 
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user@PE1# set mpls container-label-switched-path container-Isp-name splitting-merging sampling 
cut-off-threshold number 

user@PE1# set mpls container-label-switched-path container-Isp-name splitting-merging sampling 
use-percentile number 


6. Configure the policy statement to load-balance traffic. 


[edit policy-options] 

user@PE1# set policy-statement first-policy-name term 1 from protocol direct 
user@PE1# set policy-statement first-policy-name term 1 then accept 

user@PE1# set policy-statement second-policy-name then load-balance per-packet 


NOTE: The policy to load-balance traffic should be assigned to the forwarding table 
configuration under the [edit routing-options] hierarchy level. 


user@PE1# set forwarding-table export pplb 


7. Verify and commit the configuration. 


For example: 


[edit protocols] 

user@PE1# set rsvp preemption aggressive 

user@PE11# set rsvp interface all aggregate 

user@PE1# set rsvp interface fxp0.0 disable 

user@PE1# set rsvp interface ge-0/0/1.0 

user@PE1# set rsvp interface ge-0/0/2.0 

user@PE1# set mpls statistics file auto-bw 

user@PE1# set mpls statistics file size 10m 

user@PE1# set mpls statistics interval 10 

user@PE1# set mpls statistics auto-bandwidth 

user@PE1# set mpls label-switched-path PE1-to-PE2-template1 template 

user@PE1# set mpls label-switched-path PE1-to-PE2-template1 optimize-timer 30 

user@PE1# set mpls label-switched-path PE1-to-PE2-template1 link-protection 

user@PE1# set mpls label-switched-path PE1-to-PE2-template1 adaptive 

user@PE1# set mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth adjust-interval 300 
user@PE1# set mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth adjust-threshold 5 
user@PE1# set mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth minimum-bandwidth 10m 
user@PE1# set mpls label-switched-path PE1-to-PE2-template1 auto-bandwidth maximum-bandwidth 10m 
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user@PE1# set mpls label-switched-path PE1-PE2-template-1 template 

user@PE1# set mpls label-switched-path PE1-PE2-template-1 auto-bandwidth adjust-interval 8000 

user@PE1# set mpls label-switched-path PE1-PE2-template-1 auto-bandwidth minimum-bandwidth 5m 

user@PE1# set mpls label-switched-path PE1-PE2-template-1 auto-bandwidth maximum-bandwidth 10m 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 label-switched-path-template 
PE1-to-PE2-template1 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 to 10.255.102.128 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
maximum-member-lsps 20 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
minimum-member-lIsps 2 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
splitting-bandwidth 40m 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
merging-bandwidth 6m 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
maximum-signaling-bandwidth 10m 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging 
minimum-signaling-bandwidth 10m 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization 
normalize-interval 400 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization 
failover-normalization 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization 
normalization-retry-duration 20 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging normalization 
normalization-retry-limits 3 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging sampling 
cut-off-threshold 1 

user@PE1# set mpls container-label-switched-path PE1-PE2-container-100 splitting-merging sampling 
use-percentile 90 

user@PE1# set mpls interface all 

user@PE1# set mpls interface fxp0.0 disable 

user@PE1# set bgp group to-PE2 type internal 

user@PE1# set bgp group to-PE2 local-address 10.255.102.166 

user@PE1# set bgp group to-PE2 family inet-vpn unicast 

user@PE1# set bgp group to-PE2 export direct 

user@PE1# set bgp group to-PE2 neighbor 10.255.102.128 

user@PE1# set ospf traffic-engineering 

user@PE1# set ospf area 0.0.0.0 interface all 

user@PE1# set ospf area 0.0.0.0 interface fxp0.0 disable 

user@PE1# set ospf area 0.0.0.0 interface ge-0/0/2.0 metric 100 


[edit policy-options] 
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user@PE1# set policy-statement direct term 1 from protocol direct 
user@PE1# set policy-statement direct term 1 then accept 
user@PE1# set policy-statement pplb then load-balance per-packet 


[edit] 
user@PE1# commit 
commit complete 
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Multiclass LSP Overview 


A multiclass LSP is an LSP that can carry several class types. One multiclass LSP can be used to support 
up to four class types. On the packets, the class type is specified by the EXP bits (also known as the 
class-of-service bits) and the per-hop behavior (PHB) associated with the EXP bits. The mapping between 
the EXP bits and the PHB is static, rather than being signaled in RSVP. 


Once a multiclass LSP is configured, traffic from all of the class types can: 


e Follow the same path 
e Be rerouted along the same path 


e Be taken down at the same time 
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Class types must be configured consistently across the Differentiated Services domain, meaning the class 
type configuration must be consistent from router to router in the network. 


You can unambiguously map a class type to a queue. On each node router, the CoS queue configuration 
for an interface translates to the available bandwidth for a particular class type on that link. 


The combination of a class type and a priority level forms a traffic engineering class. The IGPs can advertise 
up to eight traffic engineering classes for each link. 


For more information about the EXP bits, see “MPLS Label Allocation” on page 422. 


For more information about forwarding classes, see the Class of Service User Guide (Routers and EX9200 
Switches). 


Multiclass LSPs 


Multiclass LSPs function like standard LSPs, but they also allow you to configure multiple class types with 
guaranteed bandwidth. The EXP bits of the MPLS header are used to distinguish between class types. 
Multiclass LSPs can be configured for a variety of purposes. For example, you can configure a multiclass 
LSP to emulate the behavior of an ATM circuit. An ATM circuit can provide service-level guarantees to a 
class type. A multiclass LSP can provide a similar guaranteed level of service. 


The following sections discuss multiclass LSPs: 


e Multiclass LSP Overview on page 655 


e Establishing a Multiclass LSP on the Differentiated Services Domain on page 656 


Establishing a Multiclass LSP on the Differentiated Services Domain 


The following occurs when a multiclass LSP is established on the differentiated services domain: 


1. The IGPs advertise how much unreserved bandwidth is available for the traffic engineering classes. 


2. When calculating the path for a multiclass LSP, CSPF is used to ensure that the constraints are met for 
all the class types carried by the multiclass LSP (a set of constraints instead of a single constraint). 


3. Once a path is found, RSVP signals the LSP using an RSVP object in the path message. At each node 
in the path, the available bandwidth for the class types is adjusted as the path is set up. The RSVP 
object is a hop-by-hop object. Multiclass LSPs cannot be established through routers that do not 
understand this object. Preventing routers that do not understand the RSVP object from carrying traffic 
helps to ensure consistency throughout the differentiated services domain by preventing the multiclass 
LSP from using a router that is incapable of supporting differentiated services. 


By default, multiclass LSPs are signaled with setup priority 7 and holding priority O. A multiclass LSP 
configured with these values cannot preempt another LSP at setup time and cannot be preempted. 


It is possible to have both multiclass LSPs and regular LSPs configured at the same time on the same 
physical interfaces. For this type of heterogeneous environment, regular LSPs carry best-effort traffic by 
default. Traffic carried in the regular LSPs must have the correct EXP settings. 
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Point-to-Multipoint LSPs Overview 


A point-to-multipoint MPLS LSP is an LSP with a single source and multiple destinations. By taking advantage 
of the MPLS packet replication capability of the network, point-to-multipoint LSPs avoid unnecessary 
packet replication at the ingress router. Packet replication takes place only when packets are forwarded 
to two or more different destinations requiring different network paths. 
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This process is illustrated in Figure 48 on page 658. Router PE1 is configured with a point-to-multipoint 
LSP to Routers PE2, PE3, and PE4. When Router PE1 sends a packet on the point-to-multipoint LSP to 

Routers P1 and P2, Router P1 replicates the packet and forwards it to Routers PE2 and PE3. Router P2 
sends the packet to Router PE4. 


This feature is described in detail in the Internet drafts draft-raggarwa-mpls-p2mp-te-02.txt (expired 
February 2004), Establishing Point to Multipoint MPLS TE LSPs, draft-ietf-mpls-rsvp-te-p2mp-02.txt, Extensions 
to Resource Reservation Protocol-Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label-Switched Paths 
(LSPs), and RFC 6388, Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint 
Label Switched Paths (only point-to-multipoint LSPs are supported). 


Figure 48: Point-to-Multipoint LSPs 
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The following are some of the properties of point-to-multipoint LSPs: 


e A point-to-multipoint LSP enables you to use MPLS for point-to-multipoint data distribution. This 
functionality is similar to that provided by IP multicast. 


e You can add and remove branch LSPs from a main point-to-multipoint LSP without disrupting traffic. 
The unaffected parts of the point-to-multipoint LSP continue to function normally. 


e You can configure a node to be both a transit and an egress router for different branch LSPs of the same 


point-to-multipoint LSP. 


e You can enable link protection on a point-to-multipoint LSP. Link protection can provide a bypass LSP 
for each of the branch LSPs that make up the point-to-multipoint LSP. If any of the primary paths fail, 
traffic can be quickly switched to the bypass. 


e You can configure branch LSPs either statically, dynamically, or as a combination of static and dynamic 
LSPs. 


e You can enable graceful Routing Engine switchover (GRES) and graceful restart for point-to-multipoint 
LSPs at ingress and egress routers. The point-to-multipoint LSPs must be configured using either static 
routes or circuit cross-connect (CCC). GRES and graceful restart allow the traffic to be forwarded at the 
Packet Forwarding Engine based on the old state while the control plane recovers. Feature parity for 
GRES and graceful restart for MPLS point-to-multipoint LSPs on the Junos Trio chipset is supported in 
Junos OS Releases 11.1R2, 11.2R2, and 11.4. 


Understanding Point-to-Multipoint LSPs 


A point-to-multipoint MPLS label-switched path (LSP) is an LDP-signaled or RSVP-signaled LSP with a 
single source and multiple destinations. By taking advantage of the MPLS packet replication capability of 
the network, point-to-multipoint LSPs avoid unnecessary packet replication at the inbound (ingress) router. 
Packet replication takes place only when packets are forwarded to two or more different destinations 
requiring different network paths. 


This process is illustrated in Figure 49 on page 660. Device PE1 is configured with a point-to-multipoint 
LSP to Routers PE2, PE3, and PE4. When Device PE1 sends a packet on the point-to-multipoint LSP to 

Routers P1 and P2, Device P1 replicates the packet and forwards it to Routers PE2 and PE3. Device P2 
sends the packet to Device PE4. 
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Figure 49: Point-to-Multipoint LSPs 
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e A point-to-multipoint LSP allows you to use MPLS for point-to-multipoint data distribution. This 


functionality is similar to that provided by IP multicast. 


e You can add and remove branch LSPs from a main point-to-multipoint LSP without disrupting traffic. 
The unaffected parts of the point-to-multipoint LSP continue to function normally. 


e You can configure a node to be both a transit and an outbound (egress) router for different branch LSPs 


of the same point-to-multipoint LSP. 


e You can enable link protection on a point-to-multipoint LSP. Link protection can provide a bypass LSP 
for each of the branch LSPs that make up the point-to-multipoint LSP. If any primary paths fail, traffic 


can be quickly switched to the bypass. 
e You can configure subpaths either statically or dynamically. 


e You can enable graceful restart on point-to-multipoint LSPs. 
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Point-to-Multipoint LSP Configuration Overview 


To set up a point-to-multipoint LSP: 
1. Configure the primary LSP from the ingress router and the branch LSPs that carry traffic to the egress 


routers. 


2. Specify a pathname on the primary LSP and this same path name on each branch LSP. 


NOTE: By default, the branch LSPs are dynamically signaled by means of Constrained Shortest 
Path First (CSPF) and require no configuration. You can alternatively configure the branch LSPs 
as static paths. 


Example: Configuring a Collection of Paths to Create an RSVP-Signaled Point-to-Multipoint 
LSP 


IN THIS SECTION 


Requirements | 661 
Overview | 661 
Configuration | 662 


Verification | 684 


This example shows how to configure a collection of paths to create an RSVP-signaled point-to-multipoint 
label-switched path (LSP). 
Requirements 


In this example, no special configuration beyond device initialization is required. 


Overview 


In this example, multiple routing devices serve as the transit, branch, and leaf nodes of a single 
point-to-multipoint LSP. On the provider edge (PE), Device PE1 is the ingress node. The branches go from 
PE1 to PE2, PE1 to PE3, and PE11 to PE4. Static unicast routes on the ingress node (PE1) point to the egress 


nodes. 


This example also demonstrates static routes with a next hop that is a point-to-multipoint LSP, using the 
p2mp-lsp-next-hop statement. This is useful when implementing filter-based forwarding. 


NOTE: Another option is to use the Isp-next-hop statement to configure a regular point-to-point 
LSP to be the next hop. Though not shown in this example, you can optionally assign an 
independent preference and metric to the next hop. 


Topology Diagram 
Figure 50 on page 662 shows the topology used in this example. 


Figure 50: RSVP-Signaled Point-to-Multipoint LSP 





Configuration 


CLI Quick Configuration 

To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


Device PE1 


set interfaces ge-2/0/2 unit 0 description PE1-to-CE1 

set interfaces ge-2/0/2 unit 0 family inet address 10.0.244.10/30 
set interfaces fe-2/0/10 unit 1 description PE1-to-P2 

set interfaces fe-2/0/10 unit 1 family inet address 2.2.2.1/24 
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set interfaces fe-2/0/10 unit 1 family mpls 

set interfaces fe-2/0/9 unit 8 description PE1-to-P3 

set interfaces fe-2/0/9 unit 8 family inet address 6.6.6.1/24 

set interfaces fe-2/0/9 unit 8 family mpls 

set interfaces fe-2/0/8 unit 9 description PE1-to-P4 

set interfaces fe-2/0/8 unit 9 family inet address 3.3.3.1/24 

set interfaces fe-2/0/8 unit 9 family mpls 

set interfaces loO unit 1 family inet address 100.10.10.10/32 

set protocols rsvp interface fe-2/0/10.1 

set protocols rsvp interface fe-2/0/9.8 

set protocols rsvp interface fe-2/0/8.9 

set protocols rsvp interface lo0.1 

set protocols mpls traffic-engineering bgp-igp 

set protocols mpls label-switched-path PE1-PE2 to 100.50.50.50 
set protocols mpls label-switched-path PE1-PE2 link-protection 
set protocols mpls label-switched-path PE1-PE2 p2mp p2mp1 
set protocols mpls label-switched-path PE1-PE3 to 100.70.70.70 
set protocols mpls label-switched-path PE1-PE3 link-protection 
set protocols mpls label-switched-path PE1-PE3 p2mp p2mp1 
set protocols mpls label-switched-path PE1-PE4 to 100.40.40.40 
set protocols mpls label-switched-path PE1-PE4 link-protection 
set protocols mpls label-switched-path PE1-PE4 p2mp p2mp1 
set protocols mpls interface fe-2/0/10.1 

set protocols mpls interface fe-2/0/9.8 

set protocols mpls interface fe-2/0/8.9 

set protocols mpls interface lo0.1 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-2/0/2.0 

set protocols ospf area 0.0.0.0 interface fe-2/0/10.1 

set protocols ospf area 0.0.0.0 interface fe-2/0/9.8 

set protocols ospf area 0.0.0.0 interface fe-2/0/8.9 

set protocols ospf area 0.0.0.0 interface lo0.1 

set routing-options static route 5.5.5.0/24 p2mp-lsp-next-hop p2mp1 
set routing-options static route 7.7.7.0/24 p2mp-lsp-next-hop p2mp1 
set routing-options static route 4.4.4.0/24 p2mp-lsp-next-hop p2mp1 
set routing-options router-id 100.10.10.10 


Device CE1 


set interfaces ge-1/3/2 unit 0 family inet address 10.0.244.9/30 
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set interfaces ge-1/3/2 unit 0 description CE1-to-PE1 

set routing-options static route 10.0.104.8/30 next-hop 10.0.244.10 
set routing-options static route 10.0.134.8/30 next-hop 10.0.244.10 
set routing-options static route 10.0.224.8/30 next-hop 10.0.244.10 


Device CE2 


set interfaces ge-1/3/3 unit 0 family inet address 10.0.224.9/30 
set interfaces ge-1/3/3 unit 0 description CE2-to-PE2 
set routing-options static route 10.0.244.8/30 next-hop 10.0.224.10 


Device CE3 


set interfaces ge-2/0/1 unit 0 family inet address 10.0.134.9/30 
set interfaces ge-2/0/1 unit 0 description CE3-to-PE3 
set routing-options static route 10.0.244.8/30 next-hop 10.0.134.10 


Device CE4 


set interfaces ge-3/1/3 unit 0 family inet address 10.0.104.10/30 
set interfaces ge-3/1/3 unit 0 description CE4-to-PE4 
set routing-options static route 10.0.244.8/30 next-hop 10.0.104.9 


Configuring the Ingress Label-Switched Router (LSR) (Device PE1) 


Step-by-Step Procedure 


To configure Device PE1: 


1. Configure the interfaces, interface encapsulation, and protocol families. 


[edit interfaces] 

user@PE1# set ge-2/0/2 unit 0 description PE1-to-CE1 
user@PE1# set ge-2/0/2 unit 0 family inet address 10.0.244.10/30 
user@PE1# set fe-2/0/10 unit 1 description PE1-to-P2 
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user@PE1# set fe-2/0/10 unit 1 family inet address 2.2.2.1/24 
user@PE1# set fe-2/0/10 unit 1 family mpls 

user@PE1# set fe-2/0/9 unit 8 description PE1-to-P3 
user@PE1# set fe-2/0/9 unit 8 family inet address 6.6.6.1/24 
user@PE1# set fe-2/0/9 unit 8 family mpls 

user@PE1# set fe-2/0/8 unit 9 description PE1-to-P4 
user@PE1# set fe-2/0/8 unit 9 family inet address 3.3.3.1/24 
user@PE1# set fe-2/0/8 unit 9 family mpls 

user@PE1# set loO unit 1 family inet address 100.10.10.10/32 


2. Enable RSVP, MPLS, and OSPF on the interfaces. 


[edit protocols] 

user@PE1# set rsvp interface fe-2/0/10.1 
user@PE1# set rsvp interface fe-2/0/9.8 

user@PE1# set rsvp interface fe-2/0/8.9 

user@PE1# set rsvp interface lo0.1 

user@PE1# set mpls interface fe-2/0/10.1 
user@PE1# set mpls interface fe-2/0/9.8 

user@PE1# set mpls interface fe-2/0/8.9 

user@PE1# set mpls interface lo0.1 

user@PE1# set ospf area 0.0.0.0 interface ge-2/0/2.0 
user@PE1# set ospf area 0.0.0.0 interface fe-2/0/10.1 
user@PE1# set ospf area 0.0.0.0 interface fe-2/0/9.8 
user@PE1# set ospf area 0.0.0.0 interface fe-2/0/8.9 
user@PE1# set ospf area 0.0.0.0 interface lo0.1 


3. Configure the MPLS point-to-multipoint LSPs. 


[edit protocols] 

user@PE1# set mpls label-switched-path PE1-PE2 to 100.50.50.50 
user@PE1# set mpls label-switched-path PE1-PE2 p2mp p2mp1 
user@PE1# set mpls label-switched-path PE1-PE3 to 100.70.70.70 
user@PE1# set mpls label-switched-path PE1-PE3 p2mp p2mp1 
user@PE1# set mpls label-switched-path PE1-PE4 to 100.40.40.40 
user@PE1# set mpls label-switched-path PE1-PE4 p2mp p2mp1 


4. (Optional) Enable link protection on the LSPs. 


Link protection helps to ensure that traffic sent over a specific interface to a neighboring router can 
continue to reach the router if that interface fails. 
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[edit protocols] 

user@PE1# set mpls label-switched-path PE1-PE2 link-protection 
user@PE1# set mpls label-switched-path PE1-PE3 link-protection 
user@PE1# set mpls label-switched-path PE1-PE4 link-protection 


5. Enable MPLS to perform traffic engineering for OSPF. 


[edit protocols] 
user@PE1# set mpls traffic-engineering bgp-igp 


This causes the ingress routes to be installed in the inet.0 routing table. By default, MPLS performs 
traffic engineering for BGP only. You need to enable MPLS traffic engineering on the ingress LSR only. 


6. Enable traffic engineering for OSPF. 


[edit protocols] 
user@PE1# set ospf traffic-engineering 


This causes the shortest-path first (SPF) algorithm to take into account the LSPs configured under 
MPLS. 


7. Configure the router ID. 


[edit routing-options] 
user@PE1# set router-id 100.10.10.10 


8. Configure static IP unicast routes with the point-to-multipoint LSP name as the next hop for each route. 


[edit routing-options] 

user@PE1# set static route 5.5.5.0/24p2mp-Isp-next-hop p2mp1 
user@PE1# set static route 7.7.7.0/24 p2mp-Isp-next-hop p2mp1 
user@PE1# set static route 4.4.4.0/24 p2mp-Isp-next-hop p2mp1 


9. If you are done configuring the device, commit the configuration. 


[edit] 
user@PE1# commit 
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Configuring the Transit and Egress LSRs (Devices P2, P3, P4, PE2, PE3, and PE4) 


Step-by-Step Procedure 


To configure the transit and egress LSRs: 


1. Configure the interfaces, interface encapsulation, and protocol families. 


[edit] 

user@P2# set interfaces fe-2/0/10 unit 2 description P2-to-PE1 
user@P2# set interfaces fe-2/0/10 unit 2 family inet address 2.2.2.2/24 
user@P2# set interfaces fe-2/0/10 unit 2 family mpls 

user@P2# set interfaces fe-2/0/9 unit 10 description P2-to-PE2 
user@P2# set interfaces fe-2/0/9 unit 10 family inet address 5.5.5.1/24 
user@P2# set interfaces fe-2/0/9 unit 10 family mpls 

user@P2# set interfaces loO unit 2 family inet address 100.20.20.20/32 
user@PE2# set interfaces ge-2/0/3 unit 0 description PE2-to-CE2 
user@PE2# set interfaces ge-2/0/3 unit O family inet address 10.0.224.10/30 
user@PE2# set interfaces fe-2/0/10 unit 5 description PE2-to-P2 
user@PE2# set interfaces fe-2/0/10 unit 5 family inet address 5.5.5.2/24 
user@PE2# set interfaces fe-2/0/10 unit 5 family mpls 

user@PE2# set interfaces loO unit 5 family inet address 100.50.50.50/32 
user@P3# set interfaces fe-2/0/10 unit 6 description P3-to-PE1 
user@P3# set interfaces fe-2/0/10 unit 6 family inet address 6.6.6.2/24 
user@P3# set interfaces fe-2/0/10 unit 6 family mpls 

user@P3# set interfaces fe-2/0/9 unit 11 description P3-to-PE3 
user@P3# set interfaces fe-2/0/9 unit 11 family inet address 7.7.7.1/24 
user@P3# set interfaces fe-2/0/9 unit 11 family mpls 

user@P3# set interfaces loO unit 6 family inet address 100.60.60.60/32 
user@PE3# set interfaces ge-2/0/1 unit O description PE3-to-CE3 
user@PE3# set interfaces ge-2/0/1 unit 0 family inet address 10.0.134.10/30 
user@PE3# set interfaces fe-2/0/10 unit 7 description PE3-to-P3 
user@PE3# set interfaces fe-2/0/10 unit 7 family inet address 7.7.7.2/24 
user@PE3# set interfaces fe-2/0/10 unit 7 family mpls 

user@PE3# set interfaces loO unit 7 family inet address 100.70.70.70/32 
user@P4# set interfaces fe-2/0/10 unit 3 description P4-to-PE1 
user@P4# set interfaces fe-2/0/10 unit 3 family inet address 3.3.3.2/24 
user@P4# set interfaces fe-2/0/10 unit 3 family mpls 

user@P4# set interfaces fe-2/0/9 unit 12 description P4-to-PE4 
user@P4# set interfaces fe-2/0/9 unit 12 family inet address 4.4.4.1/24 
user@P4# set interfaces fe-2/0/9 unit 12 family mpls 

user@P4# set interfaces loO unit 3 family inet address 100.30.30.30/32 
user@PE4# set interfaces ge-2/0/0 unit 0 description PE4-to-CE4 
user@PE4# set interfaces ge-2/0/0 unit O family inet address 10.0.104.9/30 
user@PE4# set interfaces fe-2/0/10 unit 4 description PE4-to-P4 
user@PE4# set interfaces fe-2/0/10 unit 4 family inet address 4.4.4.2/24 
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user@PE4# set interfaces fe-2/0/10 unit 4 family mpls 
user@PE4# set interfaces loO unit 4 family inet address 100.40.40.40/32 


2. Enable RSVP, MPLS, and OSPF on the interfaces. 


[edit] 

user@P2# set protocols rsvp interface fe-2/0/10.2 

user@P2# set protocols rsvp interface fe-2/0/9.10 

user@P2# set protocols rsvp interface lo0.2 

user@P2# set protocols mpls interface fe-2/0/10.2 

user@P2# set protocols mpls interface fe-2/0/9.10 

user@P2# set protocols mpls interface lo0.2 

user@P2# set protocols ospf area 0.0.0.0 interface fe-2/0/10.2 
user@P2# set protocols ospf area 0.0.0.0 interface fe-2/0/9.10 
user@P2# set protocols ospf area 0.0.0.0 interface lo0.2 
user@PE2# set protocols rsvp interface fe-2/0/10.5 
user@PE2# set protocols rsvp interface lo0.5 

user@PE2# set protocols mpls interface fe-2/0/10.5 
user@PE2# set protocols mpls interface lo0.5 

user@PE2# set protocols ospf area 0.0.0.0 interface ge-2/0/3.0 
user@PE2# set protocols ospf area 0.0.0.0 interface fe-2/0/10.5 
user@PE2# set protocols ospf area 0.0.0.0 interface lo0.5 
user@P3# set protocols rsvp interface fe-2/0/10.6 

user@P3# set protocols rsvp interface fe-2/0/9.11 

user@P3# set protocols rsvp interface lo0.6 

user@P3# set protocols mpls interface fe-2/0/10.6 

user@P3# set protocols mpls interface fe-2/0/9.11 

user@P3# set protocols mpls interface lo0.6 

user@P3# set protocols ospf area 0.0.0.0 interface fe-2/0/10.6 
user@P3# set protocols ospf area 0.0.0.0 interface fe-2/0/9.11 
user@P3# set protocols ospf area 0.0.0.0 interface 100.6 
user@PE3# set protocols rsvp interface fe-2/0/10.7 
user@PE3# set protocols rsvp interface lo0.7 

user@PE3# set protocols mpls interface fe-2/0/10.7 
user@PE3# set protocols mpls interface lo0.7 

user@PE3# set protocols ospf area 0.0.0.0 interface ge-2/0/1.0 
user@PE3# set protocols ospf area 0.0.0.0 interface fe-2/0/10.7 
user@PE3# set protocols ospf area 0.0.0.0 interface lo0.7 
user@P4# set protocols rsvp interface fe-2/0/10.3 

user@P4# set protocols rsvp interface fe-2/0/9.12 

user@P4# set protocols rsvp interface lo0.3 

user@P4# set protocols mpls interface fe-2/0/10.3 

user@P4# set protocols mpls interface fe-2/0/9.12 
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user@P4# set protocols mpls interface lo0.3 

user@P4# set protocols ospf area 0.0.0.0 interface fe-2/0/10.3 
user@P4# set protocols ospf area 0.0.0.0 interface fe-2/0/9.12 
user@P4# set protocols ospf area 0.0.0.0 interface lo0.3 
user@PE4# set protocols rsvp interface fe-2/0/10.4 
user@PE4# set protocols rsvp interface lo0.4 

user@PE4# set protocols mpls interface fe-2/0/10.4 
user@PE4# set protocols mpls interface lo0.4 

user@PE4# set protocols ospf area 0.0.0.0 interface ge-2/0/0.0 
user@PE4# set protocols ospf area 0.0.0.0 interface fe-2/0/10.4 
user@PE4# set protocols ospf area 0.0.0.0 interface lo0.4 


3. Enable traffic engineering for OSPF. 


[edit] 

user@P2# set protocols ospf traffic-engineering 
user@P3# set protocols ospf traffic-engineering 
user@P4# set protocols ospf traffic-engineering 
user@PE2# set protocols ospf traffic-engineering 
user@PE3# set protocols ospf traffic-engineering 
user@PE4# set protocols ospf traffic-engineering 


This causes the shortest-path first (SPF) algorithm to take into account the LSPs configured under 
MPLS. 


4. Configure the router IDs. 


[edit] 

user@P2# set routing-options router-id 100.20.20.20 
user@P3# set routing-options router-id 100.60.60.60 
user@P4# set routing-options router-id 100.30.30.30 
user@PE2# set routing-options router-id 100.50.50.50 
user@PE3# set routing-options router-id 100.70.70.70 
user@PE4# set routing-options router-id 100.40.40.40 


5. If you are done configuring the devices, commit the configuration. 


[edit] 
user@host# commit 
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Results 

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
and show routing-options commands. If the output does not display the intended configuration, repeat 
the instructions in this example to correct the configuration. 


Device PE1 


user@PE1# show interfaces 
ge-2/0/2 { 
unit O { 
description R1-to-CE1; 
family inet { 
address 10.0.244.10/30; 


} 
fe-2/0/10 { 
unit 1 { 
description PE1-to-P2; 
family inet { 
address 2.2.2.1/24, 
} 


family mpls; 


} 
fe-2/0/9 { 
unit 8 { 
description PE1-to-P2; 
family inet { 
address 6.6.6.1/24; 
} 


family mpls; 


} 
fe-2/0/8 { 
unit 9 { 
description PE1-to-P3; 
family inet { 
address 3.3.3.1/24; 
} 


family mpls; 


} 
lo0 { 
unit 1 { 
family inet { 
address 100.10.10.10/32; 


user@PE1# show protocols 


rsvp { 


} 


interface fe-2/0/10.1; 
interface fe-2/0/9.8; 
interface fe-2/0/8.9; 
interface 100.1; 


mpls { 


} 


traffic-engineering bgp-igp; 

label-switched-path PE1-to-PE2 { 
to 100.50.50.50; 
link-protection; 
p2mp p2mp1; 

} 

label-switched-path PE1-to-PE3 { 
to 100.70.70.70; 
link-protection; 
p2mp p2mp1; 

} 

label-switched-path PE1-to-PE4 { 
to 100.40.40.40; 
link-protection; 
p2mp p2mp1; 

} 

interface fe-2/0/10.1; 

interface fe-2/0/9.8; 

interface fe-2/0/8.9; 

interface 100.1; 


ospf { 


traffic-engineering; 
area 0.0.0.0 { 
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interface ge-2/0/2.0; 
interface fe-2/0/10.1; 
interface fe-2/0/9.8; 
interface fe-2/0/8.9; 
interface 100.1; 


user@PE1# show routing-options 
static { 
route 5.5.5.0/24 { 
p2mp-lsp-next-hop p2mp1; 
} 
route 7.7.7.0/24 { 
p2mp-lsp-next-hop p2mp1; 
} 
route 4.4.4.0/24 { 
p2mp-lsp-next-hop p2mp1; 


} 
router-id 100.10.10.10; 


Device P2 


user@P2# show interfaces 
fe-2/0/10 { 
unit 2 { 
description P2-to-PE1; 
family inet { 
address 2.2.2.2/24. 
} 
family mpls; 
} 
fe-2/0/9 { 
unit 10 { 
description P2-to-PE2; 
family inet { 
address 5.5.5.1/24; 
} 


family mpls; 
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} 
lo0 { 
unit 2 { 
family inet { 
address 100.20.20.20/32; 


user@P2# show protocols 
rsvp { 
interface fe-2/0/10.2; 
interface fe-2/0/9.10; 
interface 100.2; 
} 
mpls { 
interface fe-2/0/10.2; 
interface fe-2/0/9.10; 
interface |o0.2; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface fe-2/0/10.2; 
interface fe-2/0/9.10; 
interface 100.2; 


user@P2# show routing-options 
router-id 100.20.20.20; 


Device P3 


user@P3# show interfaces 
fe-2/0/10 { 
unit 6 { 
description P3-to-PE1; 
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family inet { 
address 6.6.6.2/24; 
} 


family mpls; 


} 
fe-2/0/9 { 
unit 11 { 
description P3-to-PE3; 
family inet { 
address 7.7.7.1/24, 
} 


family mpls; 


} 
loO { 
unit 6 { 
family inet { 
address 100.60.60.60/32; 


user@P3# show protocols 
rsvp { 
interface fe-2/0/10.6; 
interface fe-2/0/9.11; 
interface 100.6; 
} 
mpls { 
interface fe-2/0/10.6; 
interface fe-2/0/9.11; 
interface 100.6; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface fe-2/0/10.6; 
interface fe-2/0/9.11; 
interface 100.6; 
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user@P2# show routing-options 
router-id 100.60.60.60; 


Device P4 


user@P4# show interfaces 
fe-2/0/10 { 
unit 3 { 
description P4-to-PE1; 
family inet { 
address 3.3.3.2/24; 
} 


family mpls; 


} 
fe-2/0/9 { 
unit 12 { 
description P4-to-PE4; 
family inet { 
address 4.4.4.1/24; 
} 


family mpls; 


} 
lo0 { 
unit 3 { 
family inet { 
address 100.30.30.30/32; 


user@P4# show protocols 
rsvp { 
interface fe-2/0/10.3; 
interface fe-2/0/9.12; 
interface 100.3; 
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mpls { 
interface fe-2/0/10.3; 
interface fe-2/0/9.12; 
interface 100.3; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface fe-2/0/10.3; 
interface fe-2/0/9.12; 
interface 100.3; 


user@P3# show routing-options 
router-id 100.30.30.30; 


Device PE2 


user@PE2# show interfaces 
ge-2/0/3 { 
unit O { 
description PE2-to-CE2; 
family inet { 
address 10.0.224.10/30; 


} 
fe-2/0/10 { 
unit 5 { 
description PE2-to-P2; 
family inet { 
address 5.5.5.2/24, 
} 


family mpls; 


} 
lo0 { 
unit 5 { 
family inet { 
address 100.50.50.50/32; 
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user@PE2# show protocols 
rsvp { 
interface fe-2/0/10.5; 
interface 100.5; 
} 
mpls { 
interface fe-2/0/10.5; 
interface 100.5; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-2/0/3.0; 
interface fe-2/0/10.5; 
interface 100.5; 


user@PE2# show routing-options 
router-id 100.50.50.50; 


Device PE3 


user@PE3# show interfaces 
ge-2/0/1 { 
unit O { 
description PE3-to-CE3; 
family inet { 
address 10.0.134.10/30; 


} 
fe-2/0/10 { 
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unit 7 { 
description PE3-to-P3; 
family inet { 
address 7.7.7.2/24, 
} 


family mpls; 


} 
lo0 { 
unit 7 { 
family inet { 
address 100.70.70.70/32; 


user@PE3# show protocols 
rsvp { 
interface fe-2/0/10.7; 
interface 100.7; 
} 
mpls { 
interface fe-2/0/10.7; 
interface 100.7; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-2/0/1.0; 
interface fe-2/0/10.7; 
interface 100.7; 


user@PE3# show routing-options 
router-id 100.70.70.70; 


Device PE4 
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user@PE4# show interfaces 
ge-2/0/0 { 
unit O { 
description PE4-to-CE4; 
family inet { 
address 10.0.104.9/30; 


} 
fe-2/0/10 { 
unit 4 { 
description PE4-to-P4; 
family inet { 
address 4.4.4.2/24, 
} 


family mpls; 


} 
lo0 { 
unit 4 { 
family inet { 
address 100.40.40.40/32; 


user@PE4# show protocols 
rsvp { 
interface fe-2/0/10.4; 
interface 100.4; 
} 
mpls { 
interface fe-2/0/10.4, 
interface 100.4; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-2/0/0.0; 
interface fe-2/0/10.4; 


interface 100.4; 


user@PE4# show routing-options 
router-id 100.40.40.40; 


Configuring Device CE1 


Step-by-Step Procedure 


To configure Device CE1: 


1. Configure an interface to Device PE1. 


[edit interfaces] 
user@CE1# set ge-1/3/2 unit 0 family inet address 10.0.244.9/30 
user@CE1# set ge-1/3/2 unit 0 description CE1-to-PE1 


2. Configure static routes from Device CE1 to the three other customer networks, with Device PE1 as 
the next hop. 


[edit routing-options] 

user@CE1# set static route 10.0.104.8/30 next-hop 10.0.244.10 
user@CE1# set static route 10.0.134.8/30 next-hop 10.0.244.10 
user@CE1# set static route 10.0.224.8/30 next-hop 10.0.244.10 


3. If you are done configuring the device, commit the configuration. 


[edit] 
user@CE1# commit 


Results 

From configuration mode, confirm your configuration by entering the show interfaces and show 
routing-options commands. If the output does not display the intended configuration, repeat the instructions 
in this example to correct the configuration. 


user@CE1# show interfaces 
ge-1/3/2 { 
unit O { 
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family inet { 
address 10.0.244.9/30; 
description CE1-to-PE1; 


user@CE1# show routing-options 

static { 
route 10.0.104.8/30 next-hop 10.0.244.10; 
route 10.0.134.8/30 next-hop 10.0.244.10; 
route 10.0.224.8/30 next-hop 10.0.244.10; 


Configuring Device CE2 


Step-by-Step Procedure 


To configure Device CE2: 
1. Configure an interface to Device PE2. 
[edit interfaces] 


user@CE2# set ge-1/3/3 unit O family inet address 10.0.224.9/30 
user@CE2# set ge-1/3/3 unit 0 description CE2-to-PE2 


2. Configure a static route from Device CE2 to CE1, with Device PE2 as the next hop. 


[edit routing-options] 
user@CE2# set static route 10.0.244.8/30 next-hop 10.0.224.10 


3. If you are done configuring the device, commit the configuration. 


[edit] 
user@CE2# commit 


Results 

From configuration mode, confirm your configuration by entering the show interfaces and show 
routing-options commands. If the output does not display the intended configuration, repeat the instructions 
in this example to correct the configuration. 
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user@CE2# show interfaces 
ge-1/3/3 { 
unit O { 
family inet { 
address 10.0.224.9/30; 
description CE2-to-PE2; 


user@CE2# show routing-options 
static { 
route 10.0.244.8/30 next-hop 10.0.224.10; 


Configuring Device CE3 


Step-by-Step Procedure 


To configure Device CE3: 
1. Configure an interface to Device PES. 
[edit interfaces] 


user@CE3# set ge-2/0/1 unit O family inet address 10.0.134.9/30 
user@CE3# set ge-2/0/1 unit 0 description CE3-to-PE3 


2. Configure a static route from Device CE3 to CE1, with Device PE3 as the next hop. 


[edit routing-options] 
user@CE3# set static route 10.0.244.8/30 next-hop 10.0.134.10 


3. If you are done configuring the device, commit the configuration. 


[edit] 
user@CE3# commit 


Results 

From configuration mode, confirm your configuration by entering the show interfaces and show 
routing-options commands. If the output does not display the intended configuration, repeat the instructions 
in this example to correct the configuration. 
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user@CE3# show interfaces 
ge-2/0/1 { 
unit O { 
family inet { 
address 10.0.134.9/30; 
description CE3-to-PE3; 


user@CE3# show routing-options 
static { 
route 10.0.244.8/30 next-hop 10.0.134.10; 


Configuring Device CE4 


Step-by-Step Procedure 
To configure Device CE4: 


1. Configure an interface to Device PE4. 
[edit interfaces] 


user@CE4# set ge-3/1/3 unit 0 family inet address 10.0.104.10/30 
user@CE4# set ge-3/1/3 unit 0 description CE4-to-PE4 


2. Configure a static route from Device CE4 to CE1, with Device PE4 as the next hop. 


[edit routing-options] 
user@CE4# set static route 10.0.244.8/30 next-hop 10.0.104.9 


3. If you are done configuring the device, commit the configuration. 


[edit] 
user@CE4# commit 


Results 

From configuration mode, confirm your configuration by entering the show interfaces and show 
routing-options commands. If the output does not display the intended configuration, repeat the instructions 
in this example to correct the configuration. 
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user@CE4# show interfaces 


ge-3/1/3 { 
unit O { 


family inet { 


address 10.0.104.10/30; 
description CE4-to-PE4; 


user@CE4# show routing-options 


static { 


route 10.0.244.8/30 next-hop 10.0.104.9; 


Verification 


IN THIS SECTION 


@ Verifying Connectivity | 684 


@ Verifying the State of the Point-to-Multipoint LSP | 685 


@ = Checking the Forwarding Table | 686 


Confirm that the configuration is working properly. 


Verifying Connectivity 


Purpose 


Make sure that the devices can ping each other. 


Action 


Run the ping command from CE1 to the interface on CE2 connecting to PE2. 


user@CE1> ping 10.0.224.9 





PING 10.0.224 
64 bytes from 
64 bytes from 
64 bytes from 


oo GIRO RORZaiAe, 


10-0, 424,98 
10 -0,.424,98 
10.0, 424.98 


9): 56 data bytes 
icmp_seq=0 tt1l=61 


time=1.387 ms 





icmp_seq=1 tt1l=61 


time=1.394 ms 





time=1.506 ms 





icmp_seq=2 tt1l=61 
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AG 

==> 10,0, 224.9 joing SieELSELeS -——— 

3 packets transmitted, 3 packets received, 0% packet loss 
round-trip min/avg/max/stddev = 1.387/1.429/1.506/0.055 ms 


Run the ping command from CE1 to the interface on CE3 connecting to PE3. 


user@CE1> ping 10.0.134.9 





PUNG VOR On SA oe (HOR OF le 4 oes aiGuidateay bytes 

64 bytes from 10.0.134.9: icmp_seq=0 ttl=61 time=1.068 ms 
64 bytes from 10.0.134.9: icmp_seq=1 ttl=61 time=1.062 ms 
64 bytes from 10.0.134.9: icmp_seq=2 tt1l=61 time=1.053 ms 
NG: 

=== 10,.0,134.9 ime Stacisties =——— 











3 packets transmitted, 3 packets received, 0% packet loss 
round-trip min/avg/max/stddev = 1.053/1.061/1.068/0.006 ms 


Run the ping command from CE1 to the interface on CE4 connecting to PE4. 





user@CE1> ping 10.0.104.10 


PING 10.0.104.10 (10.0.104.10): 56 data bytes 

64 bytes from 10.0.104.10: icmp_seq=0 ttl=61 time=1.079 ms 
64 bytes from 10.0.104.10: icmp_seq=1 ttl=61 time=1.048 ms 
64 bytes from 10.0.104.10: icmp_seq=2 tt1l=61 time=1.070 ms 
aG 

=== 10.0.104.10 ping Statistics =—=— 











3 packets transmitted, 3 packets received, 0% packet loss 
round-trip min/avg/max/stddev = 1.048/1.066/1.079/0.013 ms 


Verifying the State of the Point-to-Multipoint LSP 


Purpose 


Make sure that the ingress, transit, and egress LSRs are in the Up state. 
Action 


Run the show mpls Isp p2mp command on all of the LSRs. Only the ingress LSR is shown here. 





user@PE1> show mpls Isp p2mp 
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Ingress LSP: 1 sessions 


P2MP name: p2mpl, P2MP branch count: 3 


























To From Sess ie le ActivePath LSPname 
100.40.40.40 MOOR EO ROR MKO Up @ PE1-PE4 
MOOR MORO pw© LOO), 10 - 10. 1 Up OS PE1-PE3 
MOOR SOM oO Rea 0 100.5 10.10, 1 Up Ones PEI-PE2 
Total 3 displayed, Up 3, Down 0 





Checking the Forwarding Table 


Purpose 


Make sure that the routes are set up as expected by running the show route forwarding-table command. 
Only the routes to the remote customer networks are shown here. 


Action 





user@PE1> show route forwarding-table 


Routing table: default.inet 





INCSrNeL + 

Destination Type RtRef Next hop Type Index NhRef Netif 

uO PO Pen OACr/a50) user O So3o3,2 ucst 1006 6 fe-2/0/8.9 
10,0, 134,8/30 user 0 6.6.6.2 Bese IOLO 6 fe-2/0/9.8 
10.0224 8 / 30 user ) 2B oP oo UesiE LOS 6 ce—2/0/ 0). 1 


Configuring Primary and Branch LSPs for Point-to-Multipoint LSPs 


IN THIS SECTION 


@ = Configuring the Primary Point-to-Multipoint LSP | 687 
@ Configuring a Branch LSP for Point-to-Multipoint LSPs | 687 


A point-to-multipoint MPLS label-switched path (LSP) is an RSVP LSP with multiple destinations. By taking 
advantage of the MPLS packet replication capability of the network, point-to-multipoint LSPs avoid 
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unnecessary packet replication at the ingress router. For more information about point-to-multipoint LSPs, 
see “Point-to-Multipoint LSPs Overview” on page 657. 


To configure a point-to-multipoint LSP, you need to configure the primary LSP from the ingress router 
and the branch LSPs that carry traffic to the egress routers, as described in the following sections: 


Configuring the Primary Point-to-Multipoint LSP 


A point-to-multipoint LSP must have a configured primary point-to-multipoint LSP to carry traffic from 
the ingress router. The configuration of the primary point-to-multipoint LSP is similar to a signaled LSP. 
See “Configuring the Ingress Router for MPLS-Signaled LSPs” on page 487 for more information. In addition 
to the conventional LSP configuration, you need to specify a path name for the primary point-to-multipoint 
LSP by including the p2mp statement: 


p2mp p2mp-Isp-name; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


You can enable the optimization timer for point-to-multipoint LSPs. See “Optimizing Signaled LSPs” on 
page 511 for more information. 


Configuring a Branch LSP for Point-to-Multipoint LSPs 


IN THIS SECTION 


@ Configuring the Branch LSP as a Dynamic Path | 688 
@ Configuring the Branch LSP as a Static Path | 688 


The primary point-to-multipoint LSP sends traffic to two or more branch LSPs carrying traffic to each of 
the egress provider edge (PE) routers. In the configuration for each of these branch LSPs, the 
point-to-multipoint LSP path name you specify must be identical to the path name configured for the 
primary point-to-multipoint LSP. See “Configuring the Primary Point-to-Multipoint LSP” on page 687 for 
more information. 


To associate a branch LSP with the primary point-to-multipoint LSP, specify the point-to-multipoint LSP 
name by including the p2mp statement: 


p2mp p2mp-lsp-name; 
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You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


NOTE: Any change in any of the branch LSPs of a point-to-multipoint LSP, either due to a 
user action or an automatic adjustment made by the router, causes the primary and branch 
LSPs to be resignaled. The new point-to-multipoint LSP is signaled first before the old path is 
taken down. 


The following sections describe how you can configure the branch LSP as a dynamically signaled path 
using Constrained Shortest Path First (CSPF), as a static path, or as a combination of dynamic and static 
paths: 


Configuring the Branch LSP as a Dynamic Path 


By default, the branch LSP for a point-to-multipoint LSP is signaled dynamically using CSPF and requires 
no configuration. 


When a point-to-multipoint LSP is changed, either by the addition or deletion of new destinations or by 
the recalculation of the path to existing destinations, certain nodes in the tree might receive data from 
more than one incoming interface. This can happen under the following conditions: 


e Some of the branch LSPs to destinations are statically configured and might intersect with statically or 
dynamically calculated paths to other destinations. 


e When a dynamically calculated path for a branch LSP results in a change of incoming interface for one 
of the nodes in the network, the older path is not immediately torn down after the new one has been 
signaled. This ensures that any data in transit relying on the older path can reach its destination. However, 
network traffic can potentially use either path to reach the destination. 


e A faulty router at the ingress calculates the paths to two different branch destinations such that a 
different incoming interface is chosen for these branch LSPs on a router node common to these branch 
LSPs. 


Configuring the Branch LSP as a Static Path 


You can configure the branch LSP for a point-to-multipoint LSP as a static path. See “Configuring Static 
LSPs” on page 574 for more information. 


Configuring Inter-Domain Point-to-Multipoint LSPs 


An inter-domain P2MP LSP is a P2MP LSP that has one or more sub-LSPs (branches) that span multiple 
domains in a network. Examples of such domains include IGP areas and autonomous systems (ASs). A 
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sub-LSP of an inter-domain P2MP LSP may be intra-area, inter-area, or inter-AS, depending on the location 
of the egress node (leaf) with respect to the ingress node (source). 


On the ingress node, a name is assigned to the inter-domain P2MP LSP and shared by all constituent 
sub-LSPs. Each sub-LSP is configured separately, with its own egress node and optionally an explicit path. 
The location of the egress node of the sub-LSP with respect to the ingress node determines whether the 
sub-LSP is intra-area, inter-area, or inter-AS. 


Inter-domain P2MP LSPs can be used to transport traffic in the following applications in a multi-area or 
multi-AS network: 


e Layer 2 broadcast and multicast over MPLS 
e Layer 3 BGP/MPLS VPN 
e VPLS 


On each domain boundary node (ABR or ASBR) along the path of the P2MP LSP, the expand-loose-hop 
statement must be configured at the [edit protocols mpls] hierarchy level so that CSPF can extend a 
loose-hop ERO (usually the first entry of the ERO list carried by RSVP Path message) towards the egress 
node or the next domain boundary node. 


CSPF path computation for inter-domain P2MP LSPs: 


CSPF path computation is supported on each sub-LSP for inter-domain P2MP LSPs. A sub-LSP may be 
intra-area, inter-area, or inter-AS. CSPF treats an inter-area or inter-AS sub-LSP in the same manner as 
an inter-domain P2P LSP. 


On an ingress node or a domain boundary node (ABR or ASBR), CSPF can perform an Explicit Route 
Object (ERO) expansion per-RSVP query. The destination queried could be an egress node or a received 
loose-hop ERO. If the destination resides in a neighboring domain that the node is connected to, CSPF 
generates either a sequence of strict-hop EROs towards it or a sequence of strict-hop EROs towards 
another domain boundary node that can reach the destination. 


If RSVP fails to signal a path through a previously selected domain bounday node, RSVP attempts to 
signal a path through other available domain boundary nodes in a round-robin fashion. 


e When a sub-LSP is added or removed to or from an inter-domain P2MP LSP, causing its path (branch) 
to be merged or pruned with or from the current P2MP tree, the paths being taken by the other sub-LSPs 
should not be affected, helping to prevent traffic disruption on those sub-LSPs. 


Be aware of the following when deploying inter-domain P2MP LSPs in your network: 


e Periodic path re-optimization is supported for inter-domain P2MP LSPs on ingress nodes. It can be 
turned on for an inter-domain P2MP LSP by configuring the optimize-timer statement at the [edit 
protocols mpls label-switched-path Isp-name] hierarchy level with the same interval for every sub-LSP. 


e Only link protection bypass LSPs are supported for inter-domain P2MP LSPs. To enable it for an 
inter-domain P2MP LSP, link-protection must be configured for all sub-LSPs and on all of the RSVP 
interfaces that the P2MP LSP might travel through. 
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e Only OSPF areas are supported for inter-domain P2MP LSPs. IS-IS levels are not supported. 


Configuring Link Protection for Point-to-Multipoint LSPs 


Link protection helps to ensure that traffic going over a specific interface to a neighboring router can 
continue to reach this router if that interface fails. When link protection is configured for an interface and 
a point-to-multipoint LSP that traverses this interface, a bypass LSP is created that handles this traffic if 
the interface fails. The bypass LSP uses a different interface and path to reach the same destination. 


To extend link protection to all of the paths used by a point-to-multipoint LSP, link protection must be 
configured on each router that each branch LSP traverses. If you enable link protection on a 
point-to-multipoint LSP, you must enable link protection on all of the branch LSPs. 


The Internet draft draft-ietf-mpls-rsvp-te-p2mp-01.txt, Extensions to RSVP-TE for Point to Multipoint TE 
LSPs, describes link protection for point-to-multipoint LSPs. 


To enable link protection on point-to-multipoint LSPs, complete the following steps: 


1. Configure link protection on each branch LSP. To configure link protection, include the link-protection 
statement: 


link-protection; 


You can include this statement at the following hierarchy levels: 
e [edit protocols mpls label-switched-path branch-Isp-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path branch-Isp-name] 


2. Configure link protection for each RSVP interface on each router that the branch LSP traverses. For 
information about how to configure link protection on RSVP interfaces, see “Configuring Link Protection 
on Interfaces Used by LSPs” on page 377. 


For more information on how to configure link protection, see “Configuring Node Protection or Link 
Protection for LSPs” on page 385. 


Configuring Graceful Restart for Point-to-Multipoint LSPs 


You can configure graceful restart on point-to-multipoint LSPs. Graceful restart allows a router undergoing 
a restart to inform its adjacent neighbors of its condition. The restarting router requests a grace period 
from the neighbor or peer, which can then cooperate with the restarting router. The restarting router can 
still forward MPLS traffic during the restart period; convergence in the network is not disrupted. The 
restart is not apparent to the rest of the network, and the restarting router is not removed from the network 
topology. RSVP graceful restart can be enabled on both transit routers and ingress routers. 
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To enable graceful restart on a router handling point-to-multipoint LSP traffic, include the graceful-restart 
statement: 


graceful-restart; 


You can include this statement at the following hierarchy levels: 


e [edit routing-options] 
e [edit logical-systems logical-system-name routing-options] 


The graceful restart configuration for point-to-multipoint LSPs is identical to that of point-to-point LSPs. 
For more information on how to configure graceful restart, see “Configuring RSVP Graceful Restart” on 
page 822. 


Configuring a Multicast RPF Check Policy for Point-to-Multipoint LSPs 


You can control whether a reverse path forwarding (RPF) check is performed for a source and group entry 
before installing a route in the multicast forwarding cache. This makes it possible to use point-to-multipoint 
LSPs to distribute multicast traffic to PIM islands situated downstream from the egress routers of the 
point-to-multipoint LSPs. 


By configuring the rpf-check-policy statement, you can disable RPF checks for a source and group pair. 
You would typically configure this statement on the egress routers of a point-to-multipoint LSP, because 
the interface receiving the multicast traffic on a point-to-multipoint LSP egress router might not always 
be the RPF interface. 


You can also configure a routing policy to act upon a source and group pair. This policy behaves like an 
import policy, so if no policy term matches the input data, the default policy action is “acceptance.” An 
accept policy action enables RPF checks. A reject policy action (applied to all source and group pairs that 
are not accepted) disables RPF checks for the pair. 


To configure a multicast RPF check policy for a point-to-multipoint LSP, specify the RPF check policy using 
the rpf-check-policy statement: 


rpf-check-policy policy; 


You can include this statement at the following hierarchy levels: 
e [edit routing-options multicast] 
e [edit logical-systems logical-system-name routing-options multicast] 


You also must configure a policy for the multicast RPF check. You configure policies at the [edit 
policy-options] hierarchy level. For more information, see the Routing Policies, Firewall Filters, and Traffic 
Policers User Guide. 
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NOTE: When you configure the rpf-check-policy statement, the Junos OS cannot perform RPF 
checks on incoming traffic and therefore cannot detect traffic arriving on the wrong interface. 
This might cause routing loops to form. 


Example: Configuring Multicast RPF Check Policy for a Point-to-Multipoint LSP 


Configure a policy to ensure that an RPF check is not performed for sources with prefix 128.83/16 or 
longer that belong to groups having a prefix of 228/8 or longer: 


[edit] 
policy-options { 
policy-statement rpf-sg-policy { 
from { 
route-filter 228.0.0.0/8 orlonger; 
source-address-filter 128.83.0.0/16 orlonger; 


} 
then { 
reject; 


Configuring Ingress PE Router Redundancy for Point-to-Multipoint LSPs 


You can configure one or more PE routers as part of a backup PE router group to enable ingress PE router 
redundancy. You accomplish this by configuring the IP addresses of the backup PE routers (at least one 
backup PE router is required) and the local IP address used by the local PE router. 


You must also configure a full mesh of point-to-point LSPs between the primary and backup PE routers. 
You also need to configure BFD on these LSPs. See “Configuring BFD for RSVP-Signaled LSPs” on page 144 
and “Configuring BFD for LDP LSPs” on page 908 for more information. 


To configure ingress PE router redundancy for point-to-multipoint LSPs, include the backup-pe-group 
statement: 


backup-pe-group pe-group-name { 
backups [addresses]; 
local-address address; 


For alist of hierarchy levels at which you can include these statements, see the statement summary sections 
for these statements. 


After you configure the ingress PE router redundancy backup group, you must also apply the group to a 
static route on the PE router. This ensures that the static route is active (installed in the forwarding table) 
when the local PE router is the designated forwarder for the backup PE group. You can only associate a 
backup PE router group with a static route that also has the p2mp-lsp-next-hop statement configured. 
For more information, see “Configuring Static Unicast Routes for Point-to-Multipoint LSPs” on page 582. 


Enabling Point-to-Point LSPs to Monitor Egress PE Routers 


Configuring an LSP with the associate-backup-pe-groups statement enables it to monitor the status of 
the PE router to which it is configured. You can configure multiple backup PE router groups using the same 
router's address. A failure of this LSP indicates to all of the backup PE router groups that the destination 
PE router is down. The associate-backup-pe-groups statement is not tied to a specific backup PE router 
group. It applies to all groups that are interested in the status of the LSP to that address. 


To allow an LSP to monitor the status of the egress PE router, include the associate-backup-pe-groups 
statement: 


associate-backup-pe-groups; 


This statement can be configured at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 


If you configure the associate-backup-pe-groups statement, you must configure BFD for the point-to-point 
LSP. For information about how to configure BFD for an LSP, see “Configuring BFD for MPLS IPv4 LSPs” 
on page 143 and “Configuring BFD for LDP LSPs” on page 908. 


You also must configure a full mesh of point-to-point LSPs between the PE routers in the backup PE router 
group. A full mesh is required so that each PE router within the group can independently determine the 
status of the other PE routers, allowing each router to independently determine which PE router is currently 
the designated forwarder for the backup PE router group. 


If you configure multiple LSPs with the associate-backup-pe-groups statement to the same destination 
PE router, the first LSP configured is used to monitor the forwarding state to that PE router. If you configure 
multiple LSPs to the same destination, make sure to configure similar parameters for the LSPs. With this 
configuration scenario, a failure notification might be triggered even though the remote PE router is still 


up. 
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Preserving Point-to-Multipoint LSP Functioning with Different Junos OS Releases 


In Junos OS Release 9.1 and earlier, Resv messages that include the S2L_SUB_LSP object are rejected by 
default. In Junos OS Release 9.2 and later, such messages are accepted by default. To ensure proper 
functioning of point-to-multipoint LSPs in a network that includes both devices running Junos OS Release 9.1 
and earlier and devices running Junos 9.2 and later, you must include the no-p2mp-sublsp statement in 
the configuration of the devices running Junos 9.2 and later: 


no-p2mp-sublsp; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 


Re-merge Behavior on Point-to-Multipoint LSP Overview 


IN THIS SECTION 


@ Benefits of Controlling the P2MP LSP Re-merge | 694 
@ What is P2MP LSP Re-merge? | 694 
@ = Modify the Default P2MP LSP Re-merge Behavior | 696 


This section talks about the benefits and overview of controlling the re-merge behavior on RSVP 
Point-to-Multipoint (P2MP) LSPs. 


Benefits of Controlling the P2MP LSP Re-merge 


e Reduces the RSVP signalling load on the ingress (headend routers) by avoiding path computation of sub 
LSPs which creates a re-merge condition. 


e Saves the network bandwidth by rejecting the P2MP sub LSP re-merge at the transit node. 


What is P2MP LSP Re-merge? 


In a P2MP MPLS LSP network, the term re-merge refers to the case of an ingress (headend) or transit node 
(re-merge node) that creates a re-merge branch intersecting the P2MP LSP at another node down the 
tree. This may occur due to events such as an error in path calculation, an error in manual configuration, 
or network topology changes during the establishment of the P2MP LSP. 


RFC 4875 defines the following two approaches for handling the P2MP LSP re-merge: 
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e First, the node detecting the re-merge allows the re-merge case to persist, but data from all but one 
incoming interface is dropped at the re-merge node. This works by default without any configuration. 


e Second, the re-merge node initiates the pruning of the re-merge sub LSPs through signaling. 


On Juniper Networks MX Series routers, the first approach (as defined by RFC 4875) works by default. 
The second approach can be implemented by one of the following CLI configuration statements depending 
upon where the Juniper Networks MX Series routers are placed (ingress node or transit node) in the P2MP 
RSVP MPLS network: 


no-re-merge—This CLI configuration statement when enabled at the ingress (headend) router avoids 
the path computation of P2MP sub LSPs which creates a re-merge condition. When this CLI configuration 
statement is configured at the ingress, then configuring the no-p2mp-re-merge CLI configuration 


statement at the transit router is not required. 


no-p2mp-re-merge—This CLI configuration statement when enabled at the transit router changes the 
default behavior of allowing the P2MP sub LSP sessions re-merge to rejecting the re-merge. This CLI 


configuration statement is primarily required when the ingress (headend router) is not a Juniper Networks 
MX Series router. 


single-abr—This command when enabled reduces re-merge condition beyond the inter-area, or 
inter-domain, or inter-AS RSVP P2MP LSPs. 


The following topology explains the re-merge behavior in a P2MP LSP network: 


R1 R2 R3 










Multicast 
Receiver 


eer MX Series 


Multicast Multicast 
Receiver Receiver 


P2MP LSP 1: R1-R2-R3 
P2MP LSP 2: R1-R4-R2-R3-R5 


301072 


In this topology, R1 acts as an ingress (headend) router and R2 as the transit (re-merge node) router. There 
are two sub LSP sessions created in this network, LSP 1 and LSP 2. LSP 1 is a session established among 
R1, R2, and R3 devices. LSP 2 is a session established between R1, R4, R2, R3, and R5 devices. By default, 
the transit router allows the re-merge to happen from both the sub LSPs and drops one of the sub LSP 


branch traffic at the re-merge node. You can control this re-merge behavior by enabling the no-re-merge 
CLI configuration statement at the ingress router, or the no-p2mp-re-merge CLI configuration statement 
at the transit router. 


If you enable the no-re-merge CLI configuration statement at the ingress router (R1), only one of the two 
sub LSP sessions is established. For example, if LSP 1 (R1-R2-R3) session is established first, then the other 
sub LSP session (LSP 2) will not be established. 


If you enable the no-p2mp-re-merge CLI configuration statement at the transit router (R2), the transit 
router rejects the re-merge of one of the sub LSPs and sends a path error message to the ingress router 
(R1) preventing the ingress router from creating the second P2MP LSP re-merge branch. You can use the 
show rsvp statistics CLI command to view the path error message. 


Modify the Default P2MP LSP Re-merge Behavior 
You can modify the default re-merge behavior either at the ingress (headend) node, or at the transit node 


ina P2MP RSVP MPLS network. 


On the ingress (headend router), disable the default re-merge behavior so that the ingress router does not 
do the path computation of sub LSPs which creates the re-merge condition. The default behavior allows 
the path computation of sub LSPs. 


[edit protocols] 
user@host#set mpls p2mp-Isp no-re-merge 


On the transit router, disable the default re-merge behavior so that the transit router rejects the re-merge 
of sub LSPs. 


[edit protocols] 
user@host#set rsvp no-p2mp-re-merge 


For inter-area, or inter-domain, or inter-AS RSVP P2MP LSPs, use the single-abr CLI configuration statement 
at the ingress (headend router) so that all the P2MP sub LSPs prefer to select the same exit router (ABR 
or ASBR), thereby reducing the re-merge condition. 


[edit protocols] 
user@host#set mpls p2mp-lsp single-abr 
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| Pop-and-Forward LSP Configuration 
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Pop-and-forward LSPs introduces the notion of pre-installed per traffic engineering link pop labels that 
are shared by RSVP-TE LSPs that traverse these links and significantly reducing the required forwarding 
plane state . A transit label-switching router (LSR) allocates a unique pop label per traffic engineering link 
with a forwarding action to pop the label and forward the packet over that traffic engineering link should 
the label appear at the top of the packet. These pop labels are sent back in the RESV message of the LSP 
at each LSR and further recorded in the record route object (RRO). The label stack is constructed from the 
recorded labels in the RRO and pushed by the ingress label edge router (LER), as each transit hop performs 
a pop-and-forward action on its label. The pop-and-forward tunnels enhances the RSVP-TE control plane 
feature benefits with the simplicity of the shared MPLS forwarding plane. 


Benefits of RSVP-TE Pop-and-Forward LSP Tunnels 


e Scaling advantage of RSVP-TE—Any platform-specific label space limit on an LSR is prevented from 
being a constraint to the control plane scaling on that interface. 


Reduced forwarding plane state—The transit labels on a traffic engineering link are shared across RSVP-TE 
tunnels traversing the link, and are used independent of the ingress and egress devices of the LSPs, 


thereby significantly reducing the required forwarding plane state. 


Reduced transit data plane state—Because the pop labels are allocated per traffic engineering link and 
shared across LSPs, the total label state in the forwarding plane is reduced to a function of the number 
of RSVP neighbors on that interface. 


Faster LSP setup time—The forwarding plane state is not programmed during the LSP setup and teardown. 
As a result, the control plane need not wait sequentially at each hop for the forwarding plane to be 
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programmed prior to sending the label upstream in the RESV message, resulting in reduced LSP setup 
time. 


e Backward compatibility—This allows backward compatibility with transit LSRs that provide regular labels 
in RESV messages. Labels can be mixed across transit hops in a single MPLS RSVP-TE LSP. Certain LSRs 
can use traffic engineering link labels and others can use regular labels. The ingress can construct a label 
stack appropriately based on what type of label is recorded from every transit LSR. 


Pop-and-Forward LSP Tunnel Terminology 


The following terminology is used in the implementation of RSVP-TE pop-and-forward LSP tunnels: 


Pop label—An incoming label at an LSR that is popped and forwarded over a specific traffic-engineering 


link to a neighbor. 


Swap label—An incoming label at an LSR that is swapped to an outgoing label and forwarded over a 


specific downstream traffic engineering link. 


Delegation label—An incoming label at an LSR that is popped. A new set of labels is pushed before the 


packet is forwarded. 


Delegation hop— A transit hop that allocates a delegation label. 


e Application label depth (AppLD)—Maximum number of application or service labels (for example, VPN, 
LDP, or IPv6 explicit-null labels) that can be beneath the RSVP transport labels. It is configured ona 
per-node basis, and is equally applicable for all LSPs, and is neither signaled nor advertised. 


Outbound label depth (OutLD)—Maximum number of labels that can be pushed before a packet is 


forwarded. This is local to the node, and is neither signaled nor advertised. 


Additional transport label depth (AddTLD)—Maximum number of other transport labels that can be 
added (for example, bypass label). This is a per-LSP parameter that is neither signaled or advertised. The 
value is discerned by checking if the LSP has been signaled with link protection (AddTLD=1) or without 
link protection (AddTLD=0). 


Effective transport label depth (ETLD)— Number of transport labels that the LSP hop can potentially 


send to its downstream hop. This value is signaled per LSP in the hop attributes subobject. The hop 
attributes subobject is added to the record route object (RRO) in the path message. 


Pop-and-Forward LSP Tunnel Label and Signaling 


Every traffic engineering link is allocated a pop label that is installed in the mpls.O routing table with a 
forwarding action to pop the label and forward the packet over the traffic engineering link to the 
downstream neighbor of the RSVP-TE tunnel. 


For pop-and-forward LSP tunnels, the pop label for the traffic engineering link is allocated when the first 
RESV message for a pop-and-forward transit LSP arrives over that traffic engineering link. This is done to 
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avoid preallocating pop labels and installing them in networks where pop-and-forward LSPs are not 
configured. 


NOTE: For the pop-and-forward LSP tunnels to function effectively, we recommend that you 
configure the maximum-labels statement on all the interfaces in the RSVP-TE network. 


Figure 51 on page 699 displays pop labels at all interfaces for neighboring devices. 
Figure 51: Pop-and-Forward LSP Tunnel Labels 
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There are two pop-and-forward LSP tunnels—T1 and T2. Tunnel T1 is from Device A to Device E on path 
A-B-C-D-E. Tunnel T2 is from Device F to Device E on path F-B-C-D-E. Both the tunnels, T1 and T2, share 
the same traffic engineering links B-C, C-D, and D-E. 


As RSVP-TE signals the setup of the pop-and-forward tunnel T1, the LSR D receives the RESV message 
from the egress E. Device D checks the next-hop traffic engineering link (D-E) and provides the pop label 
(250) in the RESV message for the tunnel. The label is sent in the label object and is also recorded in the 
label subobject (with the pop label bit set) carried in the RRO. Similarly, Device C provides the pop label 
(200) for the next- hop traffic engineering link C-D and Device B provides the pop label (150) for the 
next-hop traffic engineering link B-C. For the tunnel T2, the transit LSRs provide the same pop labels as 
described for tunnel T1. 


Both the label edge routers (LERs), Device A and Device F, push the same stack of labels [150(top), 200, 
250] for tunnels T1 and T2, respectively. The recorded labels in the RRO are used by the ingress LER to 
construct a stack of labels. 


The pop-and-forward LSP tunnel labels are compatible with transit interfaces that use swap labels. Labels 
can be mixed across transit hops in a single MPLS RSVP-TE LSP, where certain LSRs can use pop labels 
and others can use swap labels. The ingress device constructs the appropriate label stack based on the 
label type recorded from every transit LSR. 
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Pop-and-Forward LSP Tunnel Label Stacking 


Construction of Label Stack at the Ingress 


The ingress LER checks the type of label received from each transit hop as recorded in the RRO in the 
RESV message and generates the appropriate label stack to use for the pop-and-forward tunnel. 


The following logic is used by the ingress LER while constructing the label stack: 


e Each RRO label subobject is processed starting with the label subobject from the first downstream hop. 


e Any label provided by the first downstream hop is always pushed on the label stack. If the label type is 
a pop label, then any label from the succeeding downstream hop is also pushed on the constructed label 
stack. 


e If the label type is a swap label, then any label from the succeeding downstream hop is not pushed on 
the constructed label stack. 


Auto-Delegation of Label Stack 


The ingress device runs the Constrained Shortest Path First (CSPF) to compute the path, and if the hop 
length is greater than the OutLD-AppLD-AddTLD, the ingress device cannot impose the entire label stack 
to reach the egress device. 


When requesting RSVP-TE to signal the path, the ingress device always requests autodelegation for the 
LSP, where one or more transit hops automatically select themselves as delegation hops to push the label 
stack to reach the next delegation hop. Junos OS uses an algorithm based on the received Effective 
Transport Label-Stack Depth (ETLD), that each transit executes to decide whether it should autoselect 
itself as a delegation hop. This algorithm is based on the section on ETLD in the Internet draft 
draft-ietf-mpls-rsvp-shared-labels-00.txt (expires September 11 2017), Signaling RSVP-TE Tunnels on a 
Shared MPLS Forwarding Plane. 


The label stack imposed by the ingress device delivers the packet up to the first delegation hop. Each 
delegation hop's label stack also includes the delegation label of the next delegation hop at the bottom of 
the stack. 


Figure 52 on page 701 displays labels at every device interface, where Device D and Device | are delegation 
hops, [Label] P is the pop label, and [Label] D is the delegation label. The RSVP-TE pop-and-forward LSP 
tunnel is A-B-C-D-E-F-G-H-I-J-K-L. Delegation label 1250 represents (300, 350, 400, 450, 1500); Delegation 
label 1500 represents (550, 600). 
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Figure 52: Pop-and-Forward LSP Tunnel Pop and Delegation Labels 
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In this approach, for the tunnel, the ingress LER Device A pushes (150, 200, 1250). At LSR Device D, the 
delegation label 1250 gets popped and labels 300, 350, 400, 450, and 1500 get pushed. At LSR Device I, 
the delegation label 1500 gets popped and the remaining set of labels (550, 600) get pushed. In Junos OS, 
the pop and push action occurs as a swap to the bottom label of the outgoing stack and push the remaining 
labels. 


A delegation label and the LSP segment that it covers can be shared by multiple pop-and-forward LSPs. 
A LSP delegation segment consist of an ordered set of hops (IP addresses and labels) as seen in the RESV 
RRO. The delegation label (and the segment that it covers) is not owned by a particular LSP, but can be 
shared. When all LSPs using a delegation label are deleted, the delegation label (and route) is deleted. 


Pop-and-Forward LSP Tunnel Link Protection 


To provide link protection at a point of local repair (PLR) with a pop-and-forward data plane, the LSR 
allocates a separate pop label for the traffic engineering link that is used for the RSVP-TE tunnels that 
request link protection from the ingress device. No signaling extensions are required to support link 
protection for the RSVP-TE tunnels over the pop-and-forward data plane. 


Figure 53 on page 702 displays pop labels at every device interface; labels marked with P are pop labels 
that offer link protection for the traffic-engineering link. 
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Figure 53: Pop-and Forward LSP Tunnel Link Protection 
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At each LSR, link-protected pop labels can be allocated for each traffic engineering link, and a link-protecting 
facility bypass LSP (which is not a pop-and-forward LSP, but rather a normal bypass LSP) can be created 
to protect the traffic engineering link. These labels can be sent in the RESV message by the LSR for LSPs 
requesting link protection over the specific traffic engineering link. Because the facility bypass terminates 
at the next hop (merge point), the incoming pop label on the packet at the PLR is what the merge point 
expects. 


For example, LSR Device B can install a facility bypass LSP for the link-protected pop label 151. When the 
traffic engineering link B-C is up, LSR Device B pops 151 and sends the packet to C. If the traffic engineering 
link B-C is down, the LSR can pop 151 and send the packet through the facility backup to Device C. 


RSVP-TE Pop-and-Forward LSP Tunnel Supported and Unsupported Features 


Junos OS supports the following features with RSVP-TE pop-and-forward LSP tunnels: 


e Pop labels per RSVP neighbor for unprotected LSP. 

e Pop labels per RSVP neighbor for LSPs requesting link protection using facility bypass 

e Autodelegation of LSP segment. 

e Mixed label mode, where certain transit LSRs do not support pop-and-forward LSP tunnels 
e LSP ping and traceroute 

e All existing CSPF constraint. 

e Load balancing of traffic between pop-and-forward LSPs and regular point-to-point RSVP-TE LSP. 
e Autobandwidth, LDP tunneling, and TE++ container LSP. 

e Aggregated Ethernet interface. 

e Virtual platforms support, such as Juniper Networks vMX Virtual Router. 

e 64-bit support 


e Logical systems 
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Junos OS does not support the following functionality for RSVP-TE pop-and-forward LSP tunnels: 


Node link protection 


Detour protection for MPLS fast reroute 


Point-to-multipoint LSPs. 


e Switch-away LSP. 


Generalized MPLS (GMPLS) LSPs (including bidirectional LSPs, associated LSPs, VLAN user-to-network 
interface [UNI] and so on) 


IP Flow Information Export (protocol) (IPFIX) inline flow sampling for MPLS template 


RFC 3813, Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base 
(MIB) 


IPv4 Explicit-null (Inserting label O at the bottom of the label stack is not supported. If there are service 
labels beneath the RSVP-TE pop-and-forward label stack, because the penultimate hop for the LSP 


copies the EXP value to the service label, this can allow continuity of class of service (CoS) across the 
MPLS forwarding plane). 


Ultimate-hop popping (UHP) 


Graceful Routing Engine switchover (GRES) 


Nonstop active routing (NSR) 
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Enabling Distributed CSPF for Segment Routing LSPs 
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Prior to Junos OS Release 19.2R1S1, for traffic engineering of segment routing paths, you could either 


explicitly configure static paths, or use computed paths from an external controller. With the distributed 


Constrained Shortest Path First (CSPF) for segment routing LSP feature, you can compute a segment 


routing LSP locally on the ingress device according to the constraints you have configured. With this 


feature, the LSPs are optimized based on the configured constraints and metric type (traffic-engineering 


or IGP). The LSPs are computed to utilize the available ECMP paths to the destination with segment routing 


label stack compression enabled or disabled. 


Distributed CSPF Computation Constraints 


Segment routing LSP paths are computed when all the configured constraints are met. 


The distributed CSPF computation feature supports the following subset of constraints specified in the 


Internet draft, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing Policy for Traffic Engineering: 


e Inclusion and exclusion of administrative groups. 


e Inclusion of loose or strict hop IP addresses. 


NOTE: You can specify only router IDs in the loose or strict hop constraints. Labels and other 
IP addresses cannot be specified as loose or strict hop constraints in Junos OS Release 
19.2R1-S1. 


e Maximum number of segment IDs (SIDs) in the segment list. 


e Maximum number of segment lists per candidate segment routing path. 
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The distributed CSPF computation feature for segment routing LSPs does not support the following types 
of constraints and deployment scenarios: 


e IPV6 addresses. 

e Inter domain segment routing traffic engineering (SRTE) LSPs. 

e Unnumbered interfaces. 

e Multiple protocols routing protocols such as, OSPF, ISIS, and BGP-LS, enabled at the same time. 
e Computation with prefixes or anycast addresses as destinations. 


e Including and excluding interface IP addresses as constraints. 


Distributed CSPF Computation Algorithm 
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The distributed CSPF computation feature for segment routing LSPs uses the label stack compression 
algorithm with CSPF. 


Label Stack Compression Enabled 


A compressed label stack represents a set of paths from a source to a destination. It generally consists of 
node SIDs and adjacency SIDs. When label stack compression is enabled, the result of the computation is 
a set of paths that maximize ECMP to the destination, with minimum number of SIDs in the stack, while 
conforming to constraints. 


Label Stack Compression Disabled 


The multipath CSPF computation with label stack compression disabled finds up to N segment lists to 
destination, where: 


e The cost of all segment lists is equal to and the same as the shortest traffic-engineering metric to reach 
the destination. 


e Each segment list is comprised of adjacency SIDs. 
e The value of N is the maximum number of segment lists allowed for the candidate path by configuration. 
e No two segment lists are identical. 


e Each segment list satisfies all the configured constraints. 


Distributed CSPF Computation Database 


The database used for SRTE computation has all links, nodes, prefixes and their characteristics irrespective 


of whether traffic-engineering is enabled in those advertising nodes. In other words, it is the union of the 
traffic-engineering database (TED) and the IGP link state database of all domains that the computing node 
has learnt from. 


Configuring Distributed CSPF Computation Constraints 


You can use a compute profile to logically group the computation constraints. These compute profiles are 
referenced by the segment routing paths for computing the primary and secondary segment routing LSPs. 


To configure a compute profile, include the compute-profile statement at the [edit protocols 


source-packet-routing] hierarchy level. 


The configuration for the supported computation constraints include: 


e Administrative groups 


You can configure admin-groups under the [edit protocols mpls] hierarchy level. Junos OS applies the 
administrative group configuration to the segment routing traffic-engineering (SRTE) interfaces. 


To configure the computation constraints you can specify three categories for a set of administrative 
groups. The computation constraint configuration can be common to all candidate segment routing 
paths, or it can be under individual candidate paths. 


e include-any—Specifies that any link with at least one of the configured administrative groups in the 
list is acceptable for the path to traverse. 


e include-all—Specifies that any link with all of the configured administrative groups in the list is 
acceptable for the path to traverse. 


e exclude—Specifies that any link which does not have any of the configured administrative groups in 
the list is acceptable for the path to traverse. 


Explicit path 


You can specify a series of router IDs in the compute profile as a constraint for computing the SRTE 
candidate paths. Each hop has to be an IPv4 address and can be of type strict or loose. If the type of a 
hop is not configured, strict is used. You must include the compute option under the segment-list 
statement when specifying the explicit path constraint. 


Maximum number of segment lists (ECMP paths) 


You can associate a candidate path with a number of dynamic segment-lists. The paths are ECMP paths, 
where each segment-list translates into a next hop gateway with active weight. These paths are a result 
of path computation with or without compression. 


You can configure this attribute using the maximum-computed-segment-lists 
maximum-computed-segment-lists option under the compute-profile configuration statement. This 
configuration determines the maximum number of such segment lists computed for a given primary and 
secondary LSP. 
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e Maximum segment list depth 


The maximum segment list depth computation parameter ensures that amongst the ECMP paths that 
satisfy all other constraints such as administrative group, only the paths that have segment lists less than 
or equal to the maximum segment list depth are used. When you configure this parameter as a constraint 
under the compute-profile, it overrides the maximum-segment-list-depth configuration under the [edit 
protocols source-packet-routing] hierarchy level, if present. 


You can configure this attribute using the maximum-segment-list-depth maximum-segment-list-depth 
option under the compute-profile configuration statement. 


Protected or unprotected adjacency SIDs 


You can configure protected or unprotected adjacency SID as a constraint under the compute-profile 
to avoid links with the specified SID type. 


Metric type 


You can specify the type of metric on the link to be used for computation. By default, SR-TE LSPs use 
traffic-engineering metrics of the links for computation. The traffic-engineering metric for links is 
advertised by traffic-engineering extensions of IGP protocols. However, you may also choose to use the 
IGP-metric for computation by using the metric-type configuration in the compute profile. 


You can configure this attribute using the metric-type (igp | te) option under the compute-profile 
configuration statement. 


Distributed CSPF Computation 


The SRTE candidate paths are computed locally such that they satisfy the configured constraints. When 
label stack compression is disabled, the multi-path CSPF computation result is a set of adjacency SID 
stacks. When label stack compression is enabled, the result is a set of compressed label stacks (composed 
of adjacent SIDs and node SIDs). 


When secondary paths are computed, the links, nodes and SRLGs taken by the primary paths are not 
avoided for computation. For more information on primary and secondary paths, see “Configuring Primary 
and Secondary LSPs” on page 570. 


For any LSPs with unsuccessful computation result, the computation is retried as traffic-engineering 
database (TED) changes. 


Interaction Between Distributed CSPF Computation and SRTE Features 
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Weights Associated With Paths of an SRTE Policy 


You can configure weights against computed and static SRTE paths, which contribute to the next hops of 
the route. However, a single path that has computation enabled can result in multiple segment lists. These 
computed segment lists are treated as ECMP amongst themselves. You can assign hierarchical ECMP 
weights to these segments, considering the weights assigned to each of the configured primaries. 


BFD Liveliness Detection 


You can configure BFD liveliness detection for the computed primary or secondary paths. Every computed 
primary or secondary path can result in multiple segment lists, as a result, the BFD parameters configured 
against the segment lists are applied to all the computed segment lists. If all the active primary paths go 
down, the pre-programmed secondary path (if provided) becomes active. 


inherit-label-nexthops 


You are not required to explicitly enable the inherit-label-nexthops configuration under the [edit protocols 
source-packet-routing segment-list segment-list-name] hierarchy for the computed primary or secondary 
paths, as it is a default behavior. 


Auto-Translate Feature 


You can configure the auto-translate feature on the segment lists, and the primary or secondary paths 
with the auto-translate feature reference these segment lists. On the other hand, the primary or secondary 
on which compute feature is enabled cannot reference any segment list. As a result, you cannot enable 
both the compute feature and the auto-translate feature for a given primary or secondary path. However, 
you could have an LSP configured with a primary path with compute type and another with auto-translate 


type. 


Distributed CSPF Computation Sample Configurations 
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Example 1 
In Example 1, 
e The non-computed primary path references a configured segment-list. In this example, the configured 


segment list static_sl1 is referenced, and it also serves as the name for this primary path. 


e Acomputed primary should have a name configured, and this name should not reference any configured 
segment list. In this example, compute_segment1 is not a configured segment list. 
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e The compute_profile_red compute-profile is applied to the primary path with the name compute_segment1. 


e The compute_profile_red compute-profile includes a segment list of type compute, which is used to 
specify the explicit path constraint for the computation. 


[edit protocols source-packet-routing] 
segment-list static_sI1{ 
hop1 label 80000 
} 
segment-list exp_path1 { 
hop1 ip-address 10.1.1.1 loose 
hop2 ip-address 2.2.2.2 
compute 
} 
compute-profile compute_profile_red { 
include-any red 
segment-list exp_path1 
maximum-segment-list-depth 5 


The weights for computed path next-hops and static next-hops are 2 and 3, respectively. Assuming the 
next-hops for computed paths are comp_nh1, comp_nh2, and comp_nh3, and the next-hop for static path 
is static_nh, the weights are applied as follows: 


Next-Hop Weight 

comp_nh1 2 

comp_nh2 2 

comp_nh3 2 

static_nh 9 
Example 2 


In Example 2, both the primary and secondary paths can be of compute type and can have their own 
compute-profiles. 


[edit protocols source-packet-routing] 

compute-profile compute_profile_green{ 
include-any green 
maximum-segment-list-depth 5 
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compute-profile compute_profile_redf 
include-any red 
maximum-segment-list-depth 8 


Example 3 


In Example 3, when compute is mentioned under a primary or secondary path, it results in local computation 
of a path to the destination without any constraints or other parameters for the computation. 


[edit protocols source-packet-routing] 
source-routing-path srte_colored_policy1 { 

to 5.5.5.5 

color 5 

binding-sid 10001 

primary { 

compute_segment1 { 
compute 
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The segment routing architecture enables the ingress devices in a core network to steer traffic through 
explicit paths. You can configure these paths using segment lists to define the paths that the incoming 
traffic should take. The incoming traffic may be labeled or IP traffic, causing the forwarding operation at 
the ingress device to be either a label swap, or a destination-based lookup. 


Understanding Static Segment Routing LSP in MPLS Networks 
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Source packet routing or segment routing is a control-plane architecture that enables an ingress router to 
steer a packet through a specific set of nodes and links in the network without relying on the intermediate 
nodes in the network to determine the actual path it should take. 


Introduction to Segment Routing LSPs 


Segment routing leverages the source routing paradigm. A device steers a packet through an ordered list 
of instructions, called segments. A segment can represent any instruction, topological or service-based. A 
segment can have a local semantic to a segment routing node or to a global node within a segment routing 
domain. Segment routing enforces a flow through any topological path and service chain while maintaining 
per-flow state only at the ingress device to the segment routing domain. Segment routing can be directly 
applied to the MPLS architecture with no change on the forwarding plane. A segment is encoded as an 
MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the 
top of the stack. Upon completion of a segment, the related label is popped from the stack. 


Segment routing LSPs can either be dynamic or static in nature. 


Dynamic segment routing LSPs—When a segment routing LSP is created either by an external controller and downloaded 
to an ingress device through Path Computation Element Protocol (PCEP) extensions, or from a BGP segment routing 
policy through BGP segment routing extensions, the LSP is dynamically provisioned. The segment list of the dynamic 
segment routing LSP is contained in the PCEP Explicit Route Object (ERO), or the BGP segment routing policy of the 
LSP. 
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Static segment routing LSPs—When a segment routing LSP is created on the ingress device through local configuration, 
the LSP is statically provisioned. 


A static segment routing LSP can further be classified as colored and non-colored LSPs based on the configuration of 
the color statement at the [edit protocols source-packet-routing source-routing-path Isp-name] hierarchy level. 


For example: 


[edit protocols] 
source-packet-routing { 
source-routing-path Isp_name { 
to destination_address; 
color color_value; 
binding-sid binding-label; 
primary segment_list_1_name weight weight; 


primary segment_list_n_name weight weight; 
secondary segment_list_n_name; 
sr-preference sr_preference_value; 


} 


Here, each primary and secondary statement refers to a segment list. 


[edit protocols] 
source-packet-routing { 
segment-list segment_list_name { 
hop_1_name label sid_label; 


hop_n_name label sid_label; 


Benefits of using Segment Routing LSPs 


e Static segment routing does not rely on per LSP forwarding state on transit routers. Hence, removing 
the need of provisioning and maintaining per LSP forwarding state in the core. 


e Provide higher scalability to MPLS networks. 


Colored Static Segment Routing LSP 
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A static segment routing LSP configured with the color statement is called a colored LSP. 


Understanding Colored Static Segment Routing LSPs 


Similar to a BGP segment routing policy, the ingress route of the colored LSP is installed in the inetcolor.O 
or inet6color.0 routing tables, with destincation-ip-address, color as key for mapping IP traffic. 


A static colored segment routing LSP may have a binding SID, for which a route is installed in the mpls.O 
routing table. This binding SID label is used to map labeled traffic to the segment routing LSP. The gateways 
of the route are derived from the segment list configurations under the primary and secondary paths. 


Segment List of Colored Segment Routing LSPs 


The colored static segment routing LSPs already provde support for first hop label mode of resolving an 
LSP. However, first hop IP mode is not supported for colored segment routing LSPs. Starting in Junos OS 
Release 19.1R1, a commit check feature is introduced to ensure that all the segment lists contributing to 
the colored routes have the minimum label present for all hops. If this requirement is not met, the commit 
is blocked. 


Non-Colored Static Segment Routing LSP 
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A static segment routing LSP that is configured without the color statement is a non-colored LSP. Similar 
to PCEP segment routing tunnels, the ingress route is installed in the inet.3 or inet6.3 routing tables. 


Junos OS supports non-colored static segment routing LSPs on ingress routers. You can provision 
non-colored static segment routing LSP by configuring one source routed path and one or more segment 
lists. These segment lists can be used by multiple non-colored segment routing LSPs. 


Understanding Non-Colored Segment Routing LSPs 


The non-colored segment routing LSP has a unique name and a destination IP address. An ingress route 
to the destination is installed in the inet.3 routing table with a default preference of 8 and a metric of 1. 
This route allows non-colored services to be mapped to the segment routing LSP pertaining to the 
destination. In case the non-colored segment routing LSP does not require an ingress route then the ingress 
route can be disabled. A non-colored segment routing LSP uses binding SID label to achieve segment 
routing LSP stitching. This label that can be used to model the segment routing LSP as a segment that may 
be further used to construct other segment routing LSPs in a hierarchical manner. The transit of the binding 
SID label, by default, has a preference of 8 and a metric of 1. 


Starting in Junos OS Release 18.2R1, statically configured non-colored segment routing LSPs on the ingress 
device are reported to the Path Computation Element (PCE) through a Path Computation Element Protocol 
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(PCEP) session. These non-colored segment routing LSPs may have binding service identifier (SID) labels 
associated with them. With this feature, the PCE can use this binding SID label in the label stack to provision 
PCE-initiated segment routing LSP paths. 


Anon-colored segment routing LSP can have a maximum of 8 primary paths. If there are multiple operational 
primary paths then the packet forwarding engine (PFE) distributes traffic over the paths based on the load 
balancing factors like the weight configured on the path. This is equal cost multi path (ECMP) if none of 
the paths have a weight configured on them or weighted ECMP if at least one of the paths has a non-zero 
weight configured on the paths. In both the cases, when one or some of the paths fail, the PFE rebalances 
the traffic over the remaining paths that automatically leads to achieving path protection. A non-colored 
segment routing LSP can have a secondary path for dedicated path protection. Upon failure of a primary 
path, the PFE rebalances the traffic to the remaining functional primary paths. Otherwise, the PFE switches 
the traffic to the backup path, hence achieving path protection. A non-colored segment routing LSP may 
specify a metric at [edit protocols source-packet-routing source-routing-path Isp-name] for its ingress 
and binding-SID routes. Multiple non-colored segment routing LSPs have the same destination address 
that contribute to the next hop of the ingress route. 


Multiple non-colored segment routing LSPs have the same destination address that contribute to the next 
hop of the ingress route. Each path ,either primary or secondary, of each segment routing LSP is considered 
as a gateway candidate, if the path is functional and the segment routing LSP has the best preference of 
all these segment routing LSPs. However, the maximum number of gateways that the next-hop can hold 
cannot exceed the RPD multi-path limit, which is 128 by default. Extra paths are pruned, firstly secondary 
paths and then primary paths. A given segment list may be referred multiple times as primary or secondary 
paths by these segment routing LSPs. In this case, there are multiple gateways, each having a unique 
segment routing LSP tunnel ID. These gateways are distinct, although they have identical outgoing label 
stack and interface. A non-colored segment routing LSP and a colored segment routing LSP may also have 
the same destination address. However, they correspond to different destination addresses for ingress 
routes, as the colored segment routing LSP’s destination address is constructed with both its destination 
address and color. 


NOTE: Inthe case where a static non-colored segment routing LSP and a PCEP-created segment 
routing LSP co-exist and have the same to address that contributes to the same ingress route, 
if they also have the same preference. Otherwise, the segment routing LSP with the best 
preference is installed for the route. 


Segment List of Non-Colored Segment Routing LSPs 


Asegment list consists of a list of hops. These hops are based on the SID label or an IP address. The number 
of SID labels in the segment list should not exceed the maximum segment list limit. You can configure the 
maximum segment list limit at the [edit protocols source-packet-routing] hierarchy level. 


Prior to Junos OS Release 19.1R1, for a non-colored static segment routing LSP to be usable, the first hop 
of the segment list had to be an IP address of an outgoing interface and the second to nth hops could be 
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SID labels. Starting in Junos OS Release 19.1R1, this requirement does not apply, as the first hop of the 
non-colored static LSPs now provides support for SID labels, in addition to IP addresses. With the first 
hop label support, MPLS fast reroute (FRR) and weighted equal-cost multipath is enabled for resolving the 
static non-colored segment routing LSPs, similar to colored static LSPs. 


For the first-hop label mode to take effect, you must include the inherit-label-nexthops statement globally 
or individually for a segment list, and the first hop of the segment list must include both IP address and 
label. If the first hop includes only IP address, the inherit-label-nexthops statement does not have any 
effect. 


You can configure inherit-label-nexthops at any one of the following hierarchies. The inherit-label-nexthops 
statement takes effect only if the segment list first hop includes both IP address and label. 


e Segment list level—At the [edit protocols source-packet-routing segment-list segment-list-name] hierarchy 
level. 


e Globally—At the [edit protocols source-packet-routing] hierarchy level. 


When the inherit-label-nexthops statement is configured globally, it takes precedence over the segment-list 
level configuration, and the inherit-label-nexthops configuration is applied to all the segment lists. When 
the inherit-label-nexthops statement is not configured globally, only segment lists with both labels and IP 
address present in the first hop, and configured with inherit-label-nexthops statement are resolved using 
SID labels. 


For dynamic non-colored static LSPs, that is the PCEP-driven segment routing LSPs, the 
inherit-label-nexthops statement must be enabled globally, as the segment-level configuration is not 
applied. 


Table 22 on page 715 describes the mode of segment routing LSP resolution based on the first hop 
specification. 


Table 22: Non-Colored Static LSP Resolution Based on First Hop Specification 


First Hop Specification Mode of LSP Resolution 

IP address only The segment list is resolved using the IP 
address. 

For example: 


segment-list path-1 { 
hop-1 ip-address 172.0.12.2; 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 
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Table 22: Non-Colored Static LSP Resolution Based on First Hop Specification (continued) 


First Hop Specification 


SID only 
For example: 


segment-list path-2 { 
hop-1 label 1000011; 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 


IP address and SID (without the inherit-label-nexthops configuration) 


For example: 


segment-list path-3 { 
hop1 { 
label 801006; 
ip-address 172.24.1.2; 
} 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 


IP address and SID (with the inherit-label-nexthops configuration) 


For example: 


segment-list path-3 { 
inherit-label-nexthops; 
hop1 { 
label 801006; 
ip-address 172.24.1.2; 
} 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 


Mode of LSP Resolution 


The segment list is resolved using SID 
labels. 


By default, the segment list is resolved 
using IP address. 


The segment list is resolved using SID 
labels. 


You can use the show route ip-address protocol spring-te active-path table inet.3 command to view the 
non-colored segment routing traffic-engineered LSPs having multiple segment lists installed in the inet.3 


routing table. 
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For example: 


user@host> show route 7.7.7.7 protocol spring-te active-path table inet.3 


inet.3: 42 destinations, 59 routes (41 active, 0 holddown, 1 hidden) 


( 
+ = Active Route, Last Active, * = Both 











Tota Ve Vs B2 *[SPRING-TE/8] 00:01:25, metric 1, metric? 0 
S tO lil ,l.1.2 wila St-0/0/0.1, Pusin SOL007 
EtG 251,12 waa St-0/O/2.1, Pusin SOLOOT 
Com li hO2Z hla avtaret 0/0/02, bush mc O00 mrss OLOOZK Cee p 


EO© 21,202 ,1.28 via st-0/0/2.2, Pusin SOL007, Pusin SOLOS (cop 


tO Li, 1OS.1.2 wie st-O/0/0.,3, Pusin BOLOO7, Pusin SOLOOS (eco 





EO® Zi 20S 1.2 wie st-O/0/2,3, Pusin SOLOOT, Pusin SOLOW (eco 


to 11.104.1.2 via et-0/0/0.4, Push 801007, Push 801003, Push 


801002 (top) 
to 21.204.1.2 via et-0/0/2.4, Push 801007, Push 801006, Push 


801005 (top) 
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NOTE: 


The first hop type of segment lists of a static segment routing LSP can cause a commit to fail, if: 


e Different segment lists of a tunnel have different first hop resolution types. This is applicable 
to both colored and non-colored static segment routing LSPs. However, this does not apply 
for PCEP-driven LSPs; a system log message is generated for the mismatch in the first hop 
resolution type at the time of computing the path. 


For example: 


segment-list path-1 { 


} 


hop-1 ip-address 172.0.12.2; 


hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 


segment-list path-2 { 


} 


hop-1 label 1000011; 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 


source-routing-path Isp1 { 


The commit of tunnel Isp1 fails, as path-1 is of IP addressmode and path-2 is of label mode. 


e The binding SID is enabled for the static non-colored LSP whose segment list type is SID label. 


to 172.10.10.1; 

primary { 
path-1; 
path-2; 


For example: 


segment-list path-3 { 


} 


hop-1 label 1000011; 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 


source-routing-path Isp1 { 
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to 172.10.10.1; 

binding-sid 333; 

primary { 
path-3; 


Configuring binding SID over label segment list is supported only for colored static LSPs and 
not for no-colored static LSPs. 


Static Segment Routing LSP Provisioning 


Segment provisioning is performed on per-router basis. For a given segment on a router, a unique service 
identifier (SID) label is allocated from a desired label pool which may be from the dynamic label pool for 
an adjacency SID label or from the segment routing global block (SRGB) for a prefix SID or node SID. The 
adjacency SID label can be dynamically allocated, which is the default behavior, or be allocated from a 
local static label pool (SRLB). A route for the SID label is then installed in the mpls.0O table. 


Junos OS allows static segment routing LSPs by configuring the segment statement at the [edit protocols 
mpls static-label-switched-path static-label-switched-path] hierarchy level. A static segment LSP is identified 
by a unique SID label that falls under Junos OS static label pool. You can configure the Junos OS static 
label pool by configuring the static-label-range static-label-range statement at the [edit protocols mpls 
label-range] hierarchy level. 


Static Segment Routing LSP Limitations 


e Junos OS currently has a limitation that the next hop cannot be built to push more than the maximum 
segment list depth labels. So, a segment list with more than the maximum SID labels (excluding the SID 
label of the first hop which is used to resolve forwarding next-hop) is not usable for colored or non-colored 
segment routing LSPs. Also, the actual number allowed for a given segment routing LSP may be even 
lower than the maximum limit, if an MPLS service is on the segment routing LSP or the segment routing 
LSP is ona link or a node protection path. In all cases, the total number of service labels, SID labels, and 
link or node protection labels must not exceed the maximum segment list depth. You can configure the 
maximum segment list limit at [edit protocols source-packet-routing] hierarchy level. Multiple non-colored 
segment routing LSPs with less than or equal to the maximum SID labels can be stitched together to 
construct a longer segment routing LSP. This is called segment routing LSP stitching. It can be achieved 
using binding-SID label. 


e The segment routing LSP stitching is actually performed at path level. If a non-colored segment routing 
LSP has multiple paths that is multiple segment lists, each path can be independently stitched to another 
non-colored segment routing LSP at a stitching point. A non-colored segment routing LSP which is 
dedicated to stitching may disable ingress route installation by configuring no-ingress statement at [edit 
protocols source-packet-routing source-routing-path Isp-name] hierarchy level. 
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e A maximum of 8 primary paths and 1 secondary path are supported per non-colored static segment 
routing LSP. If there is a violation in configuration, commit check fails with an error. 


e If any segment-list is configured with more labels than the maximum segment list depth, the configuration 
commit check fails with an error. 


Dynamic Creation of Segment Routing LSPs 
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In segment routing networks that have each provider edge (PE) device connected to every other PE device, 
a large amount of configuration is required for setting up the segment routing label-switched paths (LSPs), 
although only a few segment routing traffic-engineered (SR-TE) paths may be used. You can enable 

BGP-trigerred dynamic creation of these LSPs to reduce the amount of configuration in such deployments. 


Configuring Dynamic Segment Routing LSP Template 


To configure the template for enabling dynamic creation of segment routing LSPs, you must include the 
spring-te statement at the [edit routing-options dynamic-tunnels] hierarchy. 


e The following is a sample configuration for color dynamic segment routing LSP template: 


[edit routing-options] 
dynamic-tunnels { 
<dynamic-tunnel-name> { 
spring-te { 
source-routing-path-template { 
<template-name1> color [c1 c2]; 
<template-name2> color [c3]; 
<template-name3> color-any; 
} 
destination-networks { 
<dest1>; 
<dest2>; 


e The following is a sample configuration for non-color dynamic segment routing LSP template: 


dynamic-tunnels { 
<dynamic-tunnel-name> { 
spring-te { 
source-routing-path-template { 
<template-name1>; 


} 


destination-networks { 
<dest1>; 
<dest2>; 


Resolving Dynamic Segment Routing LSPs 
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Resolving Colored Dynamic Segment Routing LSP 


When the BGP prefixes are assigned with color community, they initially get resolved over the 
catch-all-route-for-that-particular-color policy, and in turn, the SR-TE template on which the BGP prefix 
should be resolved onto is identified. The destinations SID is then derived from the BGP payload prefix 
next-hop attribute. For example, if the next hop of the BGP payload prefix is an IP address that belongs 
to Device A, then the node-SID of Device A is taken and a corresponding label is prepared and pushed to 
the bottom of the stack. The BGP payload prefix is resolved in a color-only mode, where the node-SID of 
Device A is at the bottom of the final label stack, and the SR-TE path labels are on top. 


The final LSP template name is a combination of prefix, color, and tunnel name; for example, 
<prefix>:<color>:dt-srte-<tunnel-name>. The color in the LSP name is displayed in hexadecimal format, 
and the format of the tunnel name is similar to that o RSVP-triggered tunnel LSP names. 
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To successfully resolve a colored destination network, the color should have a valid template mapping, 
either to a specific color, or through the color-any template. Without a valid mapping, the tunnel is not 
created and the BGP route requesting for resolution remains unresolved. 


Resolving Uncolored Dynamic Segment Routing LSPs 


The catch-all routes for non-colored LSPs are added to the inet.3 routing table. The non-colored tunnel 

destination must be configured in a different spring-te configuration with only one template name in the 
mapping list. This template name is used for all the tunnel routes matching any of the destination networks 
configured under the same spring-te configuration. These tunnels are similar to RSVP tunnels in functionality. 


The final LSP template name is a combination of prefix and tunnel name; for example, 
<prefix>:dt-srte-<tunnel-name>. 


Dynamic Segment Routing LSP Sample Configuration 
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The dynamic segment routing LSP template always carries a partial path. The last hop node SID is derived 
automatically at the tunnel creation time depending on the protocol next-hop address (PNH) node SID. 
The same template can be used by multiple tunnels to different destinations. In such cases, the partial 
path remains the same, and only the last hop changes depending on the PNH. Dynamic segment routing 
LSP templates are not common to a single tunnel, as a result a full path cannot be carried on it. You can 
use a segment list if a full path is to be used. 


Colored Dynamic Segment Routing LSPs 


Sample configuration for colored dynamic segment routing LSPs: 


protocols source-packet-routing { 
source-routing-path-template sr_Isp11 { 
primary sr_sl1 
primary sr_sl2 weight 2 
sr-preference 180; 


} 
dynamic-tunnels tunnel1 { 
spring-te { 
source-routing-path-template { 
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sr_Isp1 color [123 124 125 ]; 
sr_lsp2 color-any 

} 

destination-networks { 
22.33.44.0/24; 


For the above-mentioned sample configuration, the route entries are as follows: 


inetcolor.O tunnel route: 22.33.44.0-0/24 --> RT_.NH_TUNNEL 

inetcolor6.0 tunnel route: ffff::22.33.44.0-0/120 --> RT_NH_TUNNEL 

BGP prefix to tunnel mapping: 

R1 (prefix) -> 22.33.44.55-101(PNH) LSP tunnel name = 22.33.44.55:65:dt-srte-tunnel1 

R1 (prefix) -> ffff::22.33.44.55-101(PNH) LSP tunnel name = 22.33.44.55:65:dt-srte-tunnel1 
R1 (prefix) -> ffff::22.33.44.55-124(PNH) LSP tunnel name = 22.33.44.55:7c:dt-srte-tunnel1 
inetcolor.0 tunnel route: 

22.33.44.55-101/64 --> <next-hop> 

22.33.44.55-124/64 --> <next-hop> 

inetcolor6.0 tunnel route: 

ffff::22.33.44.55-101/160 --> <next-hop> 

ffff::22.33.44.55-124/160 --> <next-hop> 


Non-Colored Dynamic Segment Routing LSPs 


Sample configuration for non-colored dynamic segment routing LSPs: 


protocols source-packet-routing { 
source-routing-path-template sr_Isp1 { 
primary sr_sl1 
primary sr_sl2 weight 2 
sr-preference 180; 


} 
dynamic-tunnels { 
tunnel1 { 
spring-te { 
source-routing-path-template { 


sr_Isp1 color [ 101 ]; 
} 
destination-networks { 
22.33.44.0/24; 


} 
tunnel2 { 
spring-te { 
source-routing-path-template { 
sr_Isp1; 
} 
destination-networks { 
22.33.44.0/24; 


For the above-mentioned sample configuration, the route entries are as follows: 


inet.3 tunnel route: 22.33.44.0/24 --> RT_NH_TUNNEL 
inet6.3 tunnel route: ffff::22.33.44.0/120 --> RT_NH_TUNNEL 


BGP prefix to tunnel mapping: 


R1 (prefix) -> 22.33.44.55(PNH) LSP template name = LSP1 --- 22.33.44.55:dt-srte-tunnel2 
R1 (prefix) -> ffff::22.33.44.55(PNH) LSP template name = LSP1 --- 22.33.44.55:dt-srte-tunnel2 
inet.3 tunnel route: 22.33.44.55/32 --> <next-hop> 


inet6.3 tunnel route: ffff::22.33.44.55/128 --> <next-hop> 


Unresolved Dynamic Segment Routing LSP 


Sample configuration for unresolved dynamic segment routing LSPs: 


protocols source-packet-routing { 


source-routing-path-template sr_Isp1 { 


primary sr_sl1 
primary sr_sl2 weight 2 
sr-preference 180; 
} 
} 
dynamic-tunnels tunne!1 { 
spring-te { 
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source-routing-path-template { 
sr_Isp1 color [120 121 122 123]; 
} 


destination-networks { 
22.33.44.0/24; 
1.1.1.0/24, 


For the above-mentioned sample configuration, the route entries are as follows: 


inetcolor.O tunnel route: 22.33.44.0 - 0/24 --> RT_.NH_TUNNEL 1.1.1.0 - 0 /24 --> RT_NH_TUNNEL 


inetcolor6.0 tunnel route: ffff::22.33.44.0 - 0/120 --> RT_.NH_TUNNEL ffff::1.1.1.0 - 0 /24 --> 
RT_NH_TUNNEL 


BGP prefix to tunnel mapping: R1 (prefix) -> 22.33.44.55-124(PNH) Tunnel will not be created. (Template 
not found for the color). 


Considerations for Configuring Dynamic Creation of Segment Routing LSPs 
When configuring the dynamic creation of segment routing LSPs, take the following into consideration: 
e Atemplate can be assigned with a color object. When the dynamic tunnel spring-te configuration includes 


a template with a color object, you must configure all other templates with color objects as well. All 
destinations are assumed to be colored within that configuration. 


e Atemplate can have a list of colors defined on it, or can be configured with the color-any option. Both 
these options can coexist in the same spring-te configuration. In such cases, templates assigned with 
specific colors have a higher preference. 


Ina spring-te configuration, only one template can be defined with the color-any option. 


The color-to-template mapping is done on a one-to-one basis. One color cannot map to multiple templates. 


The template name should be configured in the spring-te statement under the [edit protocols] hierarchy, 


and should have the primary option enabled. 
e Colored and non-colored destinations cannot co-exist in the same spring-te configuration. 


e You cannot configure same destination networks, with or without color, under different spring-te 
configuration statements. 


e Innon-colored spring-te configuration, only one template can be configured without color object. 


Services Supported over Dynamic Segment Routing LSPs 


The following services are supported over colored dynamic segment routing LSPs: 


e Layer 3 VPN 
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e BGP EVPN 
e Export policy services 
The following services are supported over non-colored dynamic segment routing LSPs: 


e Layer 3 VPN 
e Layer 2 VPN 


e Multipath configurations 


Behavior With Multiple Tunnel Sources in Segment Routing 


When two sources download routes to the same destination from segment routing (for example static and 
dynamic sourced tunnels), then the segment routing preference is used for choosing the active route entry. 
A higher value has greater preference. In case the preference remains the same, then the tunnel source is 
used to determine the route entry. 


Dynamic Segment Routing LSPs Limitations 

The dynamic SR-TE LSPs do not support the following features and functionalities: 

e IPvé segment routing tunnels. 

e Static tunnels. 

e 6PE is not supported. 

e Distributed CSPF. 

e sBFD and LDP tunnelling is not supported for dynamic SR-TE LSPs and in a template. 


e Install and B-SID routes in a template. 


Color-Based Mapping of VPN Services 
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You can specify color as a protocol next hop constraint (in addition to the IPv4 or IPv6 address) for resolving 
transport tunnels over static colored and BGP segment routing traffic-engineered (SRTE) LSPs. This is 
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called the color-IP protocol next hop resolution, where you are required to configure a resolution-map 
and apply to the VPN services. With this feature, you can enable color-based traffic steering of Layer 2 
and Layer 3 VPN services. 


Junos OS supports colored SRTE LSPs associated with a single color. The color-based mapping of VPN 
services feature is supported on static colored LSPs and BGP SRTE LSPs. 


VPN Service Coloring 
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In general, a VPN service may be assigned a color on the egress router where the VPN NLRI is advertised, 
or on an ingress router where the VPN NLRI is received and processed. 


You can assign a color to the VPN services at different levels: 


e Per routing instance. 
e Per BGP group. 
e Per BGP neighbor. 


e Per prefix. 


Once you assign a color, the color is attached to a VPN service in the form of BGP color extended 
community. 


You can assign multiple colors to a VPN service, referred to as multi-color VPN services. In such cases, 
the last color attached is considered as the color of the VPN service, and all other colors are ignored. 


Multiple colors are assigned by egress and/or ingress devices through multiple policies in the following 
order: 


e BGP export policy on the egress device. 
e BGP import policy on the ingress device. 
e VRF import policy on the ingress device. 
The two modes of VPN service coloring are: 


Egress Color Assignment 


In this mode, the egress device (that is, the advertiser of the VPN NLRI) is responsible for coloring the VPN 
service. To enable this mode, you can define a routing policy, and apply it in the VPN service’s 
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routing-instance vrf-export, group export, or group neighbor export at the [edit protocols bgp] hierarchy 
level. The VPN NLRI is advertised by BGP with the specified color extended community. 


For example: 


[edit routing-options] 
community red-comm { 
members color:0:50; 


[edit policy-options] 
policy-statement pol-color { 
term t1 { 
from { 
[any match conditions]; 


} 

then { 
community add red-comm; 
accept; 


[edit routing-instances] 
vpn-X { 


vrf-export pol-color ...; 


NOTE: When you apply the routing policy as an export policy of a BGP group or BGP neighbor, 
you must include the vpn-apply-export statement at the BGP, BGP group, or BGP neighbor level 
in order for the policy to take an effect on the VPN NLRI. 


[edit protocols bgp] 
group PEs { 


neighbor PE-A { 
export pol-color ...; 
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vpn-apply-export; 


The routing policies are applied to Layer 3 VPN prefix NLRIs, Layer 2 VPN NRLIs, and EVPN NLRIs. The 
color extended community is inherited by all the VPN routes, imported, and installed in the target VRFs 
on one or multiple ingress devices. 


Ingress Color Assignment 


In this mode, the ingress device (that is, the receiver of the VPN NLRI) is responsible for coloring the VPN 
service. To enable this mode, you can define a routing policy, and apply it to the VPN service’s 
routing-instance vrf-import, group import, or group neighbor import at the [edit protocols bgp] hierarchy 
level. All the VPN routes matching the routing policy is attached with the specified color extended 
community. 


For example: 


[edit routing-options] 
community red-comm { 
members color:0:50; 


[edit policy-options] 
policy-statement pol-color { 
term t1 { 
from { 
[any match conditions]; 
} 
then { 
community add red-comm; 
accept; 


[edit routing-instances] 
vpn-Y { 


vrf-import pol-color ...; 


Or 
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[edit protocols bgp] 
group PEs { 


neighbor PE-B { 
import pol-color ...; 


Specifying VPN Service Mapping Mode 


To specify flexible VPN service mapping modes, you must define a policy using the resolution-map 
statement, and refer the policy in a VPN service's routing-instance vrf-import, group import, or group 


neighbor import at the [edit protocols bgp] hierarchy level. All the VPN routes matching the routing policy 
are attached with the specified resolution-map. 


For example: 


[edit policy-options] 

resolution-map map-A { 
<mode-1>; 
<mode-2>; 


} 
policy-statement pol-resolution { 
term t1 { 
from { 


[any match conditions]; 


} 

then { 
resolution-map map-A; 
accept; 


You can apply import policy to the VPN service’s routing-instance. 


[edit routing-instances] 
vpn-Y { 


vrf-import pol-resolution ...; 


You can also apply the import policy to a BGP group or BGP neighbor. 
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[edit protocols bgp] 
group PEs { 


neighbor PE-B { 
import pol-resolution ...; 


NOTE: Each VPN service mapping mode should have a unique name defined in the 
resolution-map. Only a single entry of IP-color is supported in the resolution-map, where the 
VPN route(s) are resolved using a colored-IP protocol next hop in the form of ip-address:color. 


Color-IP Protocol Next Hop Resolution 


The protocol next hop resolution process is enhanced to support colored-IP protocol next hop resolution. 
For a colored VPN service, the protocol next hop resolution process takes a color and a resolution-map, 
builds a colored-IP protocol next hop in the form of IP-address:color, and resolves the protocol next hop 
in the inet6color.0 routing table. 


You must configure a policy to support multipath resolution of colored Layer 2 VPN, Layer 3 VPN, or EVPN 
services over colored LSPs. The policy must then be applied with the relevant RIB table as the resolver 
import policy. 


For example: 


[edit policy-options] 
policy-statement mpath { 
then multipath-resolve; 


[edit routing-options] 
resolution { 
rib bgp.I3vpn.0 { 
inetcolor-import mpath; 


} 


resolution { 
rib bgp.I3vpn-inet6.0 { 
inet6color-import mpath; 


resolution { 
rib bgp.I2vpn.0 { 
inetcolor-import mpath; 


} 
resolution { 
rib mpls.0 { 
inetcolor-import mpath; 


} 
resolution { 
rib bgp.evpn.0O { 
inetcolor-import mpath; 


Fallback to IP Protocol Next Hop Resolution 


If a colored VPN service does not have a resolution-map applied to it, the VPN service ignores its color 
and falls back to the IP protocol next hop resolution. Conversely, if a non-colored VPN service has a 
resolution-map applied to it, the resolution-map is ignored, and the VPN service uses the IP protocol next 
hop resolution. 


The fallback is a simple process from colored SRTE LSPs to LDP LSPs, by using a RIB group for LDP to 
install routes in inet{6}color.O routing tables. A longest prefix match for a colored-IP protocol next hop 
ensures that if a colored SRTE LSP route does not exist, an LDP route with a matching IP address should 
be returned. 


BGP Labeled Unicast Color-based Mapping over SR-TE Tunnels 


Starting in Junos OS Release 20.2R1, BGP Labeled Unicast (BGP-LU) can resolve IPv4 and IPv6 routes 
over IPv4 and IPvé segment routing-traffic engineering (SR-TE) tunnels. . You can configure a resolution 
map policy for BGP-LU to construct colored protocol next hops by combining BGP next hop and BGP 
extended color community. The colored protocol next hops are then resolved on colored SR-TE tunnels 
in the inetcolor.0O or inet6color.0 table. If a resolution map policy is not configured, BGP-LU continues to 
use inet.3 and inet6.3 tables for non-color based mapping. The BGP-LU IPvé6 feature supports IPv6-only 
networks where routers do not have any IPv4 addresses configured. Currently we support BGP IPvé LU 
over IPv6 SR-TE with IS-IS underlay. 


In Figure 54 on page 734, the controller configures 4 colored SR-TE tunnels from Router A to Router D in 
an IPv6 core network. Each colored tunnel takes a different path to the destination, abcd::3701:2d05. On 
Router A, BGP imports policies to assign an extended color community and resolution map of IP-Color to 
the received BGP-LU prefix abcd::3700:6/128. Based on the resolution map and the color, BGP-LU resolves 
the colored protocol next hop on one of the colored SR-TE tunnels. 
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Figure 54: BGP IPv6 LU over colored IPv6 SR-TE Tunnels 


[.tt~‘SsSCsS BGP IPv6 LU es | 


Tunnelto A B Cc D 


aded::3701:2d05 adcd::3701:2d05 


===p adcd::3700:6/128 





g301111 


BGP-LU supports the following scenarios: 


e BGP IPv4 LU over colored BGP IPv4 SR-TE, with ISIS/OSPF IPv4 SR extensions. 
e BGP IPv4 LU over static colored and non-colored IPv4 SR-TE, with ISIS/OSPF IPv4 SR extensions. 
e BGP IPv6é LU over colored BGP IPv6 SR-TE, with ISIS IPv6 SR extensions. 


e BGP IPvé6 LU over static colored and non-colored IPv6 SR-TE, with ISIS IPv6 SR extensions. 


Supported and Unsupported Features for Color-Based Mapping of VPN Services 

The following features and functionality are supported with color-based mapping of VPN services: 
e BGP Layer 3 VPN 

e BGP Layer 2 VPN (Kompella Layer 2 VPN) 

e BGP EVPN 


Resolution-map with a single IP-color option. 


Colored IPv4 and IPv6 protocol next hop resolution. 


Routing information base (also known as routing table) group based fallback to LDP LSP in inetcolor.O 
routing table. 


Colored SRTE LSP. 


e Virtual platforms. 


e 64-bit Junos OS. 


Logical systems. 


BGP labeled unicast. 
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The following features and functionality are not supported with color-based mapping of VPN services: 


e Colored MPLS LSPs, such as RSVP, LDP, BGP-LU, static. 

e Layer 2 circuit 

e FEC-129 BGP auto-discovered and LDP-signaled Layer 2 VPN. 
e VPLS 

e MVPN 


e IPv4 and IPvé6 using resolution-map. 


Tunnel Templates for PCE-Initiated Segment Routing LSPs 


You can configure a tunnel template for PCE-initiated segment routing LSPs to pass down two additional 
parameters for these LSPs - Bidirectional forwarding detection (BFD) and LDP tunneling. 


When a PCE-Initiated segment routing LSP is being created, the LSP is checked against policy statements 
(if any) and if there is a match, the policy applies the configured template for that LSP. The template 
configuration is inherited only if it is not provided by the LSP source (PCEP); for example, metric. 


To configure a template: 


1. Include the source-routing-path-template statement at the [edit protocols source-packet-routing] 
hierarchy level. You can configure the additional BFD and LDP tunneling parameters here. 


2. Include the source-routing-path-template-map statement at the [edit protocols source-packet-routing] 
hierarchy level to list the policy statements against which the PCE-initiated LSP should be checked. 


3. Define a policy to list the LSPs on which the template should be applied. 


The from statement can include either the LSP name or LSP regular expression using the Isp and 
Isp-regex match conditions. These options are mutually exclusive, so you can specify only one option 
at a given point in time. 


The then statement must include the sr-te-template option with an accept action. This applies the 
template to the PCE-initiated LSP. 


Take the following into consideration when configuring a template for PCE-initiated LSPs: 


e Template configuration is not applicable to staticalyy configured segment routing LSPs, or any other 
client's segment routing LSP. 


e PCEP-provided configuration has precedence over template configuration. 


e PCEP LSP does not inherit template segment-list configuration. 


Example: Configuring Static Segment Routing Label Switched Path 
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This example shows how to configure static segment routing label switched paths (LSPs) in MPLS networks. 
This configuration helps to bring higher scalability to MPLS networks. 


Requirements 


This example uses the following hardware and software components: 


e Seven MX Series 5G Universal Routing Platforms 


e Junos OS Release 18.1 or later running on all the routers 
Before you begin, be sure you configure the device interfaces. 


Overview 


Junos OS a set of explicit segment routing paths are configured on the ingress router of a non-colored 
static segment routing tunnel by configuring the segment-list statement at the [edit protocols 
source-packet-routing] hierarchy level. You can configure segment routing tunnel by configuring the 
source-routing-path statement at [edit protocols source-packet-routing] hierarchy level. The segment 
routing tunnel has a destination address and one or more primary paths and optionally secondary paths 
that refer to the segment list. Each segment list consists of a sequence of hops. For non-colored static 
segment routing tunnel, the first hop of the segment list specifies an immediate next hop IP address and 
the second to Nth hop specifies the segment identifies (SID) labels corresponding to the link or node which 
the path traverses. The route to the destination of the segment routing tunnel is installed in inet.3 table. 


Topology 


In this example, configure layer 3 VPN on the provider edge routers PE1 and PES. Configure the MPLS 
protocol on all the routers. The segment routing tunnel is configured from router PE1 to router PE5 with 
a primary path configured on router PE1 and router PE5 . Router PE1 is also configured with secondary 
path for path protection. The transit routers PE2 to PE4 are configured with adjacency SID labels with 
label pop and an outgoing interface. 
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Figure 55: Static Segment Routing Label Switched Path 
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CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


PE1 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.1/24 
set interfaces ge-0/0/0 unit 0 family mpls maximum-labels 5 

set interfaces ge-0/0/1 unit 0 family inet address 10.10.13.1/24 
set interfaces ge-0/0/1 unit 0 family mpls maximum-labels 5 

set interfaces ge-0/0/5 unit 0 family inet address 10.10.17.1/24 
set routing-options autonomous-system 65000 

set routing-options forwarding-table export load-balance-policy 
set routing-options forwarding-table chained-composite-next-hop ingress I3vpn 
set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls label-range static-label-range 1000000 1000999 
set protocols bgp group pe type internal 

set protocols bgp group pe local-address 192.168.147.211 

set protocols bgp group pe family inet-vpn unicast 

set protocols bgp group pe neighbor 192.168.146.181 


PE2 
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set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols source-packet-routing segment-list sl-15-primary hop-1 ip-address 10.10.13.3 
set protocols source-packet-routing segment-list sl-15-primary hop-2 label 1000134 
set protocols source-packet-routing segment-list sl-15-primary hop-3 label 1000145 
set protocols source-packet-routing segment-list sl-15-backup hop-1 ip-address 10.10.12.2 
set protocols source-packet-routing segment-list sl-15-backup hop-2 label 1000123 

set protocols source-packet-routing segment-list sl-15-backup hop-3 label 1000134 
set protocols source-packet-routing segment-list sl-15-backup hop-4 label 1000145 

set protocols source-packet-routing source-routing-path Isp-15 to 192.168.146.181 

set protocols source-packet-routing source-routing-path Isp-15 binding-sid 1000999 
set protocols source-packet-routing source-routing-path Isp-15 primary sl-15-primary 
set protocols source-packet-routing source-routing-path Isp-15 secondary sl-15-backup 
set policy-options policy-statement VPN-A-export term a from protocol ospf 

set policy-options policy-statement VPN-A-export term a from protocol direct 

set policy-options policy-statement VPN-A-export term a then community add VPN-A 
set policy-options policy-statement VPN-A-export term a then accept 

set policy-options policy-statement VPN-A-export term b then reject 

set policy-options policy-statement VPN-A-import term a from protocol bgp 

set policy-options policy-statement VPN-A-import term a from community VPN-A 

set policy-options policy-statement VPN-A-import term a then accept 

set policy-options policy-statement VPN-A-import term b then reject 

set policy-options policy-statement bgp-to-ospf from protocol bgp 

set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger 
set policy-options policy-statement bgp-to-ospf then accept 

set policy-options policy-statement load-balance-policy then load-balance per-packet 
set policy-options community VPN-A members target:65000:1 

set routing-instances VRF1 instance-type vrf 

set routing-instances VRF1 interface ge-0/0/5.0 

set routing-instances VRF1 route-distinguisher 192.168.147.211:1 

set routing-instances VRF1 vrf-import VPN-A-import 

set routing-instances VRF1 vrf-export VPN-A-export 

set routing-instances VRF1 vrf-table-label 

set routing-instances VRF1 protocols ospf export bgp-to-ospf 

set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/5.0 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.2/24 


PE3 


PE4 
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set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.2/24 

set interfaces ge-0/0/1 unit 0 family mpls 

set protocols mpls static-label-switched-path adj-23 segment 1000123 

set protocols mpls static-label-switched-path adj-23 segment next-hop 10.10.23.3 
set protocols mpls static-label-switched-path adj-23 segment pop 

set protocols mpls static-label-switched-path adj-21 segment 1000221 

set protocols mpls static-label-switched-path adj-21 segment next-hop 10.10.12.1 
set protocols mpls static-label-switched-path adj-21 segment pop 

set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls label-range static-label-range 1000000 1000999 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.13.3/24 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.3/24 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.3/24 

set interfaces ge-0/0/2 unit 0 family mpls 

set protocols mpls static-label-switched-path adj-34 segment 1000134 

set protocols mpls static-label-switched-path adj-34 segment next-hop 10.10.34.4 
set protocols mpls static-label-switched-path adj-34 segment pop 

set protocols mpls static-label-switched-path adj-32 segment 1000232 

set protocols mpls static-label-switched-path adj-32 segment next-hop 10.10.23.2 
set protocols mpls static-label-switched-path adj-32 segment pop 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls label-range static-label-range 1000000 1000999 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 
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set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.4/24 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.4/24 

set interfaces ge-0/0/3 unit 0 family mpls 

set protocols mpls static-label-switched-path adj-45 segment 1000145 

set protocols mpls static-label-switched-path adj-45 segment next-hop 10.10.45.5 
set protocols mpls static-label-switched-path adj-45 segment pop 

set protocols mpls static-label-switched-path adj-43 segment 1000243 

set protocols mpls static-label-switched-path adj-43 segment next-hop 10.10.34.3 
set protocols mpls static-label-switched-path adj-43 segment pop 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/3.0 

set protocols mpls label-range static-label-range 1000000 1000999 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 


set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.5/24 

set interfaces ge-0/0/3 unit 0 family mpls maximum-labels 5 

set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.5/24 

set routing-options autonomous-system 65000 

set protocols mpls interface ge-0/0/3.0 

set protocols mpls label-range static-label-range 1000000 1000999 

set protocols bgp group pe type internal 

set protocols bgp group pe local-address 192.168.146.181 

set protocols bgp group pe family inet-vpn unicast 

set protocols bgp group pe neighbor 192.168.147.211 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols bfd sbfd local-discriminator 0.0.0.32 minimum-receive-interval 1000 
set protocols source-packet-routing segment-list sl-51 hop-1 ip-address 10.10.45.4 
set protocols source-packet-routing segment-list sl-51 hop-2 label 1000243 

set protocols source-packet-routing segment-list sl-51 hop-3 label 1000232 

set protocols source-packet-routing segment-list sl-51 hop-4 label 1000221 

set protocols source-packet-routing source-routing-path Isp-51 to 192.168.147.211 
set protocols source-packet-routing source-routing-path Isp-51 primary sl-51 

set policy-options policy-statement VPN-A-export term a from protocol ospf 

set policy-options policy-statement VPN-A-export term a from protocol direct 

set policy-options policy-statement VPN-A-export term a then community add VPN-A 


set policy-options policy-statement VPN-A-export term a then accept 

set policy-options policy-statement VPN-A-export term b then reject 

set policy-options policy-statement VPN-A-import term a from protocol bgp 

set policy-options policy-statement VPN-A-import term a from community VPN-A 
set policy-options policy-statement VPN-A-import term a then accept 

set policy-options policy-statement VPN-A-import term b then reject 

set policy-options policy-statement bgp-to-ospf from protocol bgp 

set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger 
set policy-options policy-statement bgp-to-ospf then accept 

set policy-options community VPN-A members target:65000:1 

set routing-instances VRF1 instance-type vrf 

set routing-instances VRF1 interface ge-0/0/4.0 

set routing-instances VRF1 route-distinguisher 192.168.146.181:1 

set routing-instances VRF1 vrf-import VPN-A-import 

set routing-instances VRF1 vrf-export VPN-A-export 

set routing-instances VRF1 vrf-table-label 

set routing-instances VRF1 protocols ospf export bgp-to-ospf 

set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/4.0 


CE1 
set interfaces ge-0/0/0 unit 0 family inet address 10.10.17.7/24 
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 
CE2 
set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.6/24 
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 
Configuring Device PE1 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 


information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device PE1: 


1. Configure the interfaces. 
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[edit interfaces] 
set ge-0/0/0 unit O family inet address 10.10.12.1/24 
set ge-0/0/0 unit 0 family mpls maximum-labels 5 


set ge-0/0/1 unit 0 family inet address 10.10.13.1/24 
set ge-0/0/1 unit O family mpls maximum-labels 5 


set ge-0/0/5 unit O family inet address 10.10.17.1/24 


2. Configure autonomous system number and options to control packet forwarding routing options. 


[edit routing-options] 

set autonomous-system 65000 

set forwarding-table export load-balance-policy 

set forwarding-table chained-composite-next-hop ingress I3vpn 


3. Configure the interfaces with the MPLS protocol and configure the MPLS label range. 


[edit protocols mpls] 

set interface ge-0/0/0.0 

set interface ge-0/0/1.0 

set label-range static-label-range 1000000 1000999 


4. Configure the type of peer group, local address, protocol family for NLRIs in updates, and IP address 
of a neighbor for the peer group. 


[edit protocols bgp] 

set group pe type internal 

set group pe local-address 192.168.147.211 
set group pe family inet-vpn unicast 

set group pe neighbor 192.168.146.181 


5. Configure the protocol area interfaces. 


[edit protocols ospf] 

set area 0.0.0.0 interface ge-0/0/0.0 
set area 0.0.0.0 interface lo0.0 

set area 0.0.0.0 interface ge-0/0/1.0 


743 


6. Configure the IPv4 address and labels of primary and secondary paths for source routing-traffic 
engineering (TE) policies of protocol source packet routing (SPRING). 


[edit protocols source-packet-routing segment-list] 
set sl-15-primary hop-1 ip-address 10.10.13.3 

set sl-15-primary hop-2 label 1000134 

set sl-15-primary hop-3 label 1000145 

set sl-15-backup hop-1 ip-address 10.10.12.2 

set sl-15-backup hop-2 label 1000123 

set sl-15-backup hop-3 label 1000134 

set sl-15-backup hop-4 label 1000145 


7. Configure destination IPv4 address, binding SID label, primary, and secondary source routing path for 
protocol SPRING. 


[edit protocols source-packet-routing source-routing-path] 
set Isp-15 to 192.168.146.181 

set Isp-15 binding-sid 1000999 

set Isp-15 primary sl-15-primary 

set Isp-15 secondary sl-15-backup 


8. Configure policy options. 


[edit policy-options policy-statement] 

set VPN-A-export term a from protocol ospf 

set VPN-A-export term a from protocol direct 

set VPN-A-export term a then community add VPN-A 
set VPN-A-export term a then accept 

set VPN-A-export term b then reject 

set VPN-A-import term a from protocol bgp 

set VPN-A-import term a from community VPN-A 

set VPN-A-import term a then accept 

set VPN-A-import term b then reject 

set bgp-to-ospf from protocol bgp 

set bgp-to-ospf from route-filter 10.10.0.0/16 orlonger 
set bgp-to-ospf then accept 

set load-balance-policy then load-balance per-packet 


9. Configure BGP community information. 


[edit policy-options] 
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set community VPN-A members target:65000:1 


10. Configure routing instance VRF1 with instance type, interface, router distinguisher, VRF import, export 
and table label. Configure export policy and interface of area for protocol OSPF. 


[edit routing-instances VRF1] 

set instance-type vrf 

set interface ge-0/0/5.0 

set route-distinguisher 192.168.147.211:1 

set vrf-import VPN-A-import 

set vrf-export VPN-A-export 

set vrf-table-label 

set protocols ospf export bgp-to-ospf 

set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, 
show protocols, show routing-options, and show routing-instances commands. If the output does not 
display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@PE1# show interfaces 
ge-0/0/0 { 
unit O { 

family inet { 
address 55.1.12.1/24; 

} 

family mpls { 
maximum-labels 5; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 55.1.13.1/24; 
} 
family mpls { 
maximum-labels 5; 


ge-0/0/5 { 
unit O { 
family inet { 
address 55.1.17.1/24; 


user@PE1# show routing-options 


autonomous-system 65000; 
forwarding-table { 
export load-balance-policy; 
chained-composite-next-hop { 
ingress { 
I3vpn; 


user@PE1# show protocols 
mpls { 
interface ge-0/0/0.0; 
interface ge-0/0/1.0; 
label-range { 
static-label-range 1000000 1000999; 


} 
bgp { 
group pe { 
type internal; 
local-address 128.9.147.211; 
family inet-vpn { 
unicast; 

} 
neighbor 128.9.146.181; 


} 
ospf { 
area 0.0.0.0 { 
interface ge-0/0/0.0; 
interface 100.0; 
interface ge-0/0/1.0; 
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} 
bfd { 
} 
source-packet-routing { 
segment-list sl-15-primary { 
hop-1 ip-address 55.1.13.3; 
hop-2 label 1000134; 
hop-3 label 1000145; 
} 
segment-list sl-15-backup { 
hop-1 ip-address 55.1.12.2; 
hop-2 label 1000123; 
hop-3 label 1000134; 
hop-4 label 1000145; 
} 
source-routing-path Isp-15 { 
to 128.9.146.181; 
binding-sid 1000999; 
primary { 
sl-15-primary; 
} 
secondary { 
sl-15-backup; 


user@PE1# show policy-options 
policy-statement VPN-A-export { 
terma { 
from protocol [ ospf direct ]; 
then { 
community add VPN-A; 
accept; 


} 
term b { 
then reject; 


} 
policy-statement VPN-A-import { 
terma { 
from { 
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protocol bgp; 
community VPN-A; 
} 
then accept; 
} 
term b { 
then reject; 


} 
policy-statement bgp-to-ospf { 
from { 
protocol bgp; 
route-filter 55.1.0.0/16 orlonger; 
} 
then accept; 
} 
policy-statement load-balance-policy { 
then { 
load-balance per-packet; 


} 
community VPN-A members target:65000:1; 


user@PE1# show routing-instances 
VRF1 { 
instance-type vrf; 
interface ge-0/0/5.0; 
route-distinguisher 128.9.147.211:1; 
vrf-import VPN-A-import; 
vrf-export VPN-A-export; 
vrf-table-label; 
protocols { 
ospf { 
export bgp-to-ospf; 
area 0.0.0.0 { 
interface ge-0/0/5.0; 


Configuring Device PE2 


Step-by-Step Procedure 
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The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


1. Configure the interfaces. 


[edit interfaces] 
set ge-0/0/0 unit O family inet address 10.10.12.2/24 
set ge-0/0/0 unit O family mpls 


set ge-0/0/1 unit O family inet address 10.10.23.2/24 
set ge-0/0/1 unit O family mpls 


2. Configure the static LSP for protocol MPLS. 


3. Configure interfaces and static label range for protocol MPLS. 


[edit protocols mpls static-label-switched-path] 
set adj-23 segment 1000123 

set adj-23 segment next-hop 10.10.23.3 

set adj-23 segment pop 

set adj-21 segment 1000221 

set adj-21 segment next-hop 10.10.12.1 

set adj-21 segment pop 


[edit protocols mpls] 

set interface ge-0/0/0.0 

set interface ge-0/0/1.0 

set label-range static-label-range 1000000 1000999 


4. Configure interfaces for protocol OSPF. 


Results 


From configuration mode on router PE2, confirm your configuration by entering the show interfaces and 
show protocols commands. If the output does not display the intended configuration, repeat the instructions 


[edit protocols ospf area 0.0.0.0] 
set interface ge-0/0/0.0 
set interface ge-0/0/1.0 


in this example to correct the configuration. 
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user@PE2# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 55.1.12.2/24; 
} 


family mpls; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 55.1.23.2/24, 
} 


family mpls; 


user@PE2# show protocols 
mpls { 
static-label-switched-path adj-23 { 
segment { 
1000123; 
next-hop 55.1.23.3; 


pop; 


} 
static-label-switched-path adj-21 { 
segment { 
1000221; 
next-hop 55.1.12.1; 
pop; 


} 
interface ge-0/0/0.0; 
interface ge-0/0/1.0; 
label-range { 
static-label-range 1000000 1000999; 


} 
ospf { 
area 0.0.0.0 { 
interface ge-0/0/0.0; 
interface ge-0/0/1.0; 


749 


750 


Verification 


IN THIS SECTION 


Verifying Route Entry of Routing Table inet.3 of Router PE1 | 750 

Verifying Route Table Entries of Routing Table mpls.0 of Router PE1 | 751 

Verifying SPRING Traffic Engineered LSP of Router PE1 | 751 

Verifying SPRING Traffic Engineered LSPs on the Ingress Router of Router PE1 | 752 


9 
@ 
9 
®@ 
@ Verifying the Routing Table Entries of Routing Table mpls.0 of Router PE2 | 753 
© 


Verifying the Status of Static MPLS LSP Segments of Router PE2 | 754 


Confirm that the configuration is working properly. 
Verifying Route Entry of Routing Table inet.3 of Router PE1 


Purpose 


Verify the route entry of routing table inet.3 of router PE1. 
Action 


From operational mode, enter the show route table inet.3 command. 





user@PE1> show route table inet.3 


inet.3: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 


192.168.146.181/32 PSE REGEN Gb .OslO SiO) AG) mmc ieeresieomelt 
ScomlOr ORG resm vet cg —0y/.0)/sle0 mets nelAO\O ONE Sy am etiam OO OeSAN tao) 





to 10.10.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, 
Push 1000123 (top) 


Meaning 


The output displays the ingress routes of segment routing tunnels. 


Verifying Route Table Entries of Routing Table mpls.0 of Router PE1 


Purpose 


Verify the route entries of routing table mpls.O 
Action 


From operational mode, enter the show route table mpls.0 command. 


user@PE1> show route table mpls.0 





mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, O hidden) 
































+ = Active Route, Last Active, * = Both 

0 “(MES / Ol] OSeL25852, imsiereale: i 
Receive 

il IMPS Ol Ossi2 S12) emeie atom 
Receive 

2) IMPS) Oll0 S32 51> 2) aemeteraatcml 
Receive 

3} =(MPLS/O]) OFe25s52, wrercieale il 
Receive 

16 Avie Ny AON OS eae) 

> wala iei.0 (WRF), LoS 
1000999 * [SPRING-TE/8] 03:04:03, metric 1 
> to 10.10.13.3 via ge-0/0/1.0, Swap 1000145, Push 1000134 (top) 


to 10.10.12.2 via ge-0/0/0.0, Swap 1000145, Push 1000134, 
Push 1000123 (top) 


Meaning 


The output displays the SID labels of segment routing tunnels. 


Verifying SPRING Traffic Engineered LSP of Router PE1 


Purpose 


Verify SPRING traffic engineered LSPs on the ingress routers. 
Action 


From operational mode, enter the show spring-traffic-engineering overview command. 





user@PE1> show spring-traffic-engineering overview 


751 


Overview of SPRING-TE: 





el 


Route preference: 8 


Number of LSPs: 1 (Up: 1, Down: 0) 





External controllers: 


< Not configured > 


Meaning 


The output displays the overview of SPRING traffic engineered LSPs on the ingress router. 


Verifying SPRING Traffic Engineered LSPs on the Ingress Router of Router PE1 


Purpose 


Verify SPRING traffic engineered LSPs on the ingress router. 
Action 


From operational mode, enter the show spring-traffic-engineering Isp detail command. 





user@PE1# show spring-traffic-engineering Isp detail 


Name: lsp-15 

HOS W268. VAS, We 

State: Up 
Petting Sill S—jeseimescy 
Outgoing interface: ge-0/0/1.0 
BFD status: N/A (Up: 0, Down: 0) 





SR-ERO) hop) count: 3 
Bee I (Sieraeie)) < 
NAS Iw Aclieeemey 1D, O.0.0.0 —> 10.10,15.3 
SID type: None 
neo 2 (SiteiCie)) s 
NAT: None 
SID type: 20-bit label, Value: 1000134 
EUG OMS Man (ionlenraele oles) ies 
NAI: None 
SID type: 20-bit label, Value: 1000145 
Path ssi > backup 
Outgoing interface: ge-0/0/0.0 
BFD status: N/A (Up: 0, Down: 0) 
SR-ERO hop count: 4 





Inky I (Siewaleie)) = 
NAS Iw Mchaccsiney ID, O.0.0,0 —> 10.10.12 ,2 
SID type: None 
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Ineo 2 ((SiEwaLSHE)) = 
NAI: None 


SID type: 


NAI: None 


SID type: 


NAI: None 
SID type: 


Total displayed LSPs: 


Meaning 


20-bit label, Value: 
ne 3 (SireiLeis) s 


20-bit label, Value: 
Bey 4 (Sieraeie)) < 


20-bit label, Value: 


I (Ujeg 1, Dew 


Nn: 


0) 


1000123 


1000134 


1000145 


The output displays details of SPRING traffic engineered LSPs on the ingress router 


Verifying the Routing Table Entries of Routing Table mpls.0 of Router PE2 


Purpose 


Verify the routing table entries of routing table mpls.O of router PE2. 


Action 


From operational mode, enter the show route table mpls.0 command. 





user@PE2> show route table mpls.0 


mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, O hidden) 








+ = Active Rout 
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1000221 (S=0) *([MPLS/6] 03:22:29, metric 1 
acon Opel Opreermnvaitcmcic— 010/10 Ome Op 


Verifying the Status of Static MPLS LSP Segments of Router PE2 


Purpose 
Verify the status of MPLS LSP segments of router PE2. 


Action 


From operational mode, enter the show mpls static-Isp command. 





user@PE2> show mpls static-Isp 


LIMGIASSS ILVSIENS)s 
Total 0, displayed 0, Up 0, Down 0 


Transit LSPs: 





Total 0, displayed 0, Up 0, Down 0 


Bypass lskst 
Total 0, displayed 0, Up 0, Down 0 


Segment LSPs: 


LSPname SID-label State 
alcla=2as OCO2Z 2s Up 
adeia2s 1000123 Up 


Total 2, displayed 2, Up 2, Down 0 


Meaning 


The output displays the status of static MPLS LSP segments of router PE2. 
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Release History Table 


Release Description 


20.2R1 Starting in Junos OS Release 20.2R1, BGP Labeled Unicast (BGP-LU) can resolve IPv4 and IPvé 
routes over IPv4 and IPv6é segment routing-traffic engineering (SR-TE) tunnels. 


19.4R1 You can configure a tunnel template for PCE-initiated segment routing LSPs to pass down two 
additional parameters for these LSPs - Bidirectional forwarding detection (BFD) and LDP tunneling. 


19.1R1 Starting in Junos OS Release 19.1R1, a commit check feature is introduced to ensure that all the 
segment lists contributing to the colored routes have the minimum label present for all hops. 


19.1R1 Starting in Junos OS Release 19.1R1, this requirement does not apply, as the first hop of the 
non-colored static LSPs now provides support for SID labels, in addition to IP addresses. With the 
first hop label support, MPLS fast reroute (FRR) and weighted equal-cost multipath is enabled for 
resolving the static non-colored segment routing LSPs, similar to colored static LSPs. 


18.2R1 Starting in Junos OS Release 18.2R1, statically configured non-colored segment routing LSPs on 
the ingress device are reported to the Path Computation Element (PCE) through a Path Computation 
Element Protocol (PCEP) session. 


Routing Engine-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label 
Resolution 


IN THIS SECTION 


@ Understanding RE-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label 
Resolution | 756 


Configuring RE-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution | 757 
Example | 760 


Verify That LSPs Are Configured for Static Segment-Routing Tunnels and That S-BFD Session Status Is 
Visible | 761 


Verify the Segment-Routing Tunnel Route with a Primary Next Hop and a Secondary Next Hop | 763 
@ ~~ Verify the S-BFD Session of the Primary Path | 763 


You can run seamless Bidirectional Forwarding Detection (S-BFD) over non-colored and colored 
label-switched paths (LSPs) with first-hop label resolution, using S-BFD as a fast mechanism to detect path 
failures. 


Understanding RE-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution 


IN THIS SECTION 


@ _S-BFD Static Segment-Routing Tunnels for First-Hop Labels | 756 
@ Limitations | 757 


S-BFD Static Segment-Routing Tunnels for First-Hop Labels 


IN THIS SECTION 


@ = _LSP-level S-BFD | 757 
@  S-BFD Parameters | 757 


Segment-routing architecture enables ingress nodes in a core network to steer traffic through explicit 
paths through the network. The segment-routing traffic engineering (TE) next hop is a list or lists of segment 
identifiers (SIDs). These segment lists represent paths in the network that you want incoming traffic to 
take. The incoming traffic may be labeled or IP traffic and the forwarding operation at the ingress node 
may be a label swap or a destination-based lookup to steer the traffic onto these segment-routing TE paths 
in the forwarding path. 


You can run seamless BFD (S-BFD) over non-colored and colored static segment-routing LSPs with first-hop 
label resolution and use S-BFD as a fast mechanism to detect path failures and to trigger global convergence. 
S-BFD requires fewer state changes than BFD requires, thus speeding up the reporting of path failures. 


Given a segment-routing tunnel with one or multiple primary LSPs and optionally a secondary LSP, you 
can enable S-BFD on any of those LSPs. If an S-BFD session goes down, the software updates the 
segment-routing tunnel’s route by deleting the next hops of the failed LSPs. If the first-hop label of the 
LSP points to more than one immediate next hop, the kernel continues to send S-BFD packets if at least 
one next hop is available (underlying next-hop reachability failure detection must be faster than the duration 
of the S-BFD detection timer). 


NOTE: This model is supported for auto-translate-derived LSPs. 
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LSP-level S-BFD 


An S-BFD session is created for each unique label-stackt+address-family combination. You can configure 
identical segment lists and enable S-BFD for all of them. The segment lists that have identical 
label-stack+address-family combinations share the same S-BFD session. The source address for the S-BFD 
session is set to the least configured loopback address (except the special addresses) under the main 
instance. 


NOTE: Ensure that the chosen source address is routable. 


The address family of an LSP is derived based on the address family of the “to” address in the 
segment-routing TE tunnel. The state of the LSP with S-BFD configured also depends on whether BFD is 
up—if S-BFD is configured for an LSP, the LSP route isn’t calculated until S-BFD reports the path is alive. 


S-BFD Parameters 


The following S-BFD parameters are supported for segment-routing TE paths: 


e Remote discriminator 
e Minimum interval 

e Multiplier 

e No router alert option 


In S-BFD, each responder may have multiple discriminators. The discriminators may be advertised by IGP 
to other routers, or they may be statically configured on these routers. On an initiator, a particular 
discriminator is chosen as the remote discriminator for an S-BFD session by static configuration, based on 
the decision or resolution made by you or by a central controller. When multiple LSPs are created with 
the same key label stack and S-BFD is enabled on each of them with different parameters, the aggressive 
value of each parameter is used in the shared S-BFD session. For the discriminator parameter, the lowest 
value is considered as most aggressive. Similarly for the router alert option, if one of the configurations 
no router alert is configured, the derived S-BFD parameter will have no router alert option. 


Limitations 


e Only global repair is supported. 


e Even though S-BFD detects failures depending on the configured timer values, convergence time depends 
on the global repair time (seconds). 


Configuring RE-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution 


To enable LSP-level S-BFD for a segment list, you configure the bfd-liveness-detection configuration 
statement at the [edit protocols source-packet-routing source-routing-path Isp-path-name primary 
segment-list-name] hierarchy and the [edit protocols source-packet-routing source-routing-path 
Isp-path-name secondary segment-list-name] hierarchy. 
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The following steps give the basic configuration and then operation of S-BFD with first-hop label resolution: 


e The steps immediately below describe the outlines of the basic configuration: 


1. 


On an ingress router, you configure one or more segment lists with first-hop labels for a static 
segment-routing tunnel to use as primary and secondary paths. 


. On the ingress router, you configure the static segment-routing tunnel, with either multiple primary 


paths (for load balancing), or one primary path and one secondary path (for path protection). Each 
primary or secondary path (LSP) refers to one of the segment lists you configured already, creating 
routes using the next hops derived from the first-hop labels from contributing LSPs. 


. On the ingress router, you enable per-packet load-balancing so that routes resolving over ingress 


routes and the binding-SID route (which all have first-hop labels) install all active paths in the Packet 
Forwarding Engine. An S-BFD session under an LSP protects all routes that use that LSP. 


On the egress router of the segment-routing tunnel, you configure S-BFD responder mode with a 
local discriminator D, creating a distributed S-BFD listener session for D on each FPC. 


On the ingress router, you configure S-BFD for any LSP for which you want to see path-failure 
detection. You specify a remote-discriminator D to match the local S-BFD discriminator of the egress 
router. An S-BFD initiator session is created with the LSP label-stackt+address-family combination 
as the key, if an initiator session doesn’t already exist for the current LSP key. The S-BFD parameters 
in the case of a matching BFD session are reevaluated with the new shared LSPs taken into 
consideration. When the S-BFD parameters are derived, the aggressive value of each parameter is 
chosen. 


The steps immediately below describe basic operation : 


1. 


The S-BFD initiator session runs in a centralized mode on the Routing Engine. The software tracks 
S-BFD session up and down states. 


. When the S-BFD state moves to UP, the LSP is considered for the relevant routes. 


. On the ingress router, if the software detects an S-BFD session DOWN, a session-down notification 


is sent to the routing daemon (RPD), and RPD deletes the next hop of the failed LSPs from the 
segment-routing tunnel’s route. 


The total traffic loss in the procedure is bound to the S-BFD failure detection time and the global 
repair time. The S-BFD failure detection time is determined by the S-BFD minimum-interval and 
multiplier parameters. The global repair time depends on the segment-routing TE process time and 
the redownload of the routes to forwarding. 


LSP label stacks are changed as follows: 


1. 


The particular LSP is detached from the existing S-BFD session. If the existing S-BFD session has at 
least one LSP referring to it, the old BFD session is preserved, but the S-BFD parameters are 
re-evaluated so that the aggressive parameter values among the existing LSP sessions is chosen. 
Also, the name of the S-BFD session is updated to the least one if there is a change. If the old S-BFD 
session has no more LSPs attached to it, that S-BFD session is removed. 
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2. The software attempts to find an existing BFD session that matches the 
new-label-stackt+address-family combination value; if such a match exists, the LSP refers to that 
existing S-BFD session. The S-BFD session is re-evaluated for any change in parameters or session 
name similarly to the re-evaluations in step 1. 


3. If there is no matching BFD session in the system, a new BFD session is created, and the S-BFD 
parameters are derived from this LSP. 


NOTE: An S-BFD session’s minimum interval and multiplier determine the failure detection 
time for the session. The repair time additionally depends on the global repair time. 


The following output shows configuration statements you would use for a colored LSP with primary LSPs: 


[edit protocols] 
source-packet-routing { 
source-routing-path Isp_name { 
to destination_address; 
color color_value; 
binding-sid binding-label, 
primary segment_list_1_name weight weight; 
Sat 
bfd-liveness-detection { 
sbfd { 
remote-discriminator value; 


At the responder side, you must configure the correct discriminator: 


[edit protocols bfd] 
sbfd { 
local-discriminator value; 


By default, router alerts are configured for S-BFD packets. When the MPLS header is removed at the 
responder end, the packet is sent to the host for processing without a destination address lookup for the 
packet. If you enable the no-router-alert option on the ingress router, the router-alert option is removed 
from the IP options and hence from the egress side. You must configure the destination address explicitly 
in loO; otherwise the packet is discarded, and S-BFD remains down. 


[edit interfaces loO unit O family inet] 


address 127.0.0.1/32; 


You can use a new trace flag, bfd, to trace BFD activities: 


user@host# set protocols source-packet-routing traceoptions flag bfd 


Example 


The following configuration is an example of a non-colored static segment-routing tunnel with LSP 


protection. 


protocols { 
source-packet-routing { 


source-routing-path ncsrisp5 { 


to 10.10.10.10; 
primary { 


ncsrpath12 { 
weight 1; 
bfd-liveness-detection { 
sbfd { 
remote-discriminator 100; 
} 


minimum-interval 100; 


} 
ncsrpath13 { 
weight 2; 
bfd-liveness-detection { 
sbfd { 
remote-discriminator 100; 
} 


minimum-interval 100; 


} 
ncsrpath14 { 
weight 3; 
bfd-liveness-detection { 
sbfd { 
remote-discriminator 100; 
} 


minimum-interval 100; 
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Verify That LSPs Are Configured for Static Segment-Routing Tunnels and That S-BFD Session Status Is Visible 


Purpose 


Use the show spring-traffic-engineering Isp detail command to show LSPs for static segment-routing 


ncsrpath15 { 
weight 4; 
bfd-liveness-detection { 
sbfd { 
remote-discriminator 100; 
} 


minimum-interval 100; 


} 

segment-list ncsrpath12 { 
hop1 label 50191; 
hop2 label 801000; 

} 

segment-list ncsrpath13 { 
hop1 label 50191; 
hop2 label 801001; 
hop3 label 801000; 

} 

segment-list ncsrpath14 { 
hop1 label 801000; 

} 

segment-list ncsrpath15 { 
hop1 label 801002; 
hop2 label 801000; 


tunnels, with S-BFD session status. 


Action 


user@host> show spring-traffic-engineering lsp detail 


Name: abc 


Los Wi. 
State: 
Path: 


Plo VV VY 
Up 
Salle 
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Outgoing interface: NA 


Per “status: 


SREEROMMOpmCc oun: 





Hop 1 


NAIL: 


SLD 
Hop 2 


NAIL: 


Sey 
HOpas 


NAIL: 


SID 


(SirieaLeic}) e 


None 


type: 20-bit label, 


(Siesta) ee 


None 


type: 20-bit label, 


(Sic eaLeic}) 8 


None 


type: 20-bit label, 


Praia iy cele, 


Ups BEDenamer 


$s 


Outgoing interface: NA 


PEE Suatuc: 


SR-ERO hop count: 





Hop 1 


NAIL: 


SLD 
Hop 2 


NAIL: 


SID 


((Sitesrssinoiten) Ie 


None 


type: 20-bit label, 


(SieieaLeic}) 8 


None 


type: 20-bit label, 


Praia ly emsee) 


Up BFD name: 


2 


Outgoing interface: NA 


BED ‘Stans: 


SR-ERO hop count: 





Hop 1 


NAIL: 


SLD 
Hop 2 


NAIL: 


SID 


(Sic eaLeic}) 8 


None 


type: 20-bit label, 


((Sitesreeiteiten) ee 


None 


type: 20-bit label, 


Up BFD name: 


2 


v4-sll 


Value: 801007 


Value: 22222 


Value: 3333 


V4-sl2 


Value: 801006 


Wallies 121212 


V4-sl12 


Value: 801006 


Walwes 1.21212 


roca, Chisjolenysc! uSese a (vss 1, wrens @)) 


Because many LSPs can share the same BFD session, when the first LSP with a unique 
label-stackt+address-family combination comes up, the name of the S-BFD session uses 
address-family+lsp-name. If more LSPs later share the same session, the name of the session can change 
to address-family+least-Isp-name, without affecting the state of the S-BFD session. The name of the S-BFD 
session appears in output from the show bfd session extensive command as well. Output for each LSP 
shows the S-BFD status as well as the S-BFD name it is referring to as shown in the preceding example 
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as BFD status: Up BFD name: V4-sl2. Because there might not be one S-BFD session per LSP, the LSP-level 
S-BFD counters are not displayed. 


Verify the Segment-Routing Tunnel Route with a Primary Next Hop and a Secondary Next Hop 


Purpose 
On the Routing Engine of the ingress router, verify the segment-routing tunnel route with a primary next 
hop and a secondary next hop. 


Action 


user@host> show route table inet.3 


inet.3: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 





128), 9,146, 157/32 *[SPRING-TE/8] 00:43:16, metric 1 

> to 55.1.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, 
Push 1000123 (top) 

to 55.1.12.2 via ge-0/0/1.0, Push 1000934, Push 1000923 (top) 


Verify the S-BFD Session of the Primary Path 


Purpose 


On the Routing Engine of the ingress router, verify the S-BFD session of the primary path. 


Action 


user@host> show bfd session extensiv 





Detect Transmit 
Address State Interface Time Interval Multiplier 
127 0.051 Up 4.000 1.000 4 


Client SPRING-TE, TX interval 1.000, RX interval 1.000 





Session up time 00:40:53, previous down time 00:02:08 


Local diagnostic None, remote diagnostic None 





Remote state Up, version 1 

Session type: Multi hop BFD (Seamless) 

Min async interval 1.000, min slow interval 1.000 

Adaptive async TX interval 1.000, RX interval 1.000 

Local min TX interval 1.000, minimum RX interval 1.000, multiplier 4 
Remote min TX interval 1.000, min RX interval 0.001, multiplier 4 


Local discriminator 28, remote discriminator 32 





Echo mode disabled/inactive 





Remote is control-plane independent 
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Path-Name V4-s1-1 


1 sessions, 1 clients 


Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 pps 





NOTE: On the Routing Engine of the ingress router, verify the S-BFD session of the secondary 
path also similarly. 


Configuring Static Adjacency Segment Identifier for Aggregate Ethernet Member Links Using 
Single-Hop Static LSP 


In anetwork where aggregate Ethernet (AE) bundles are in use, an aggregate link could be bundle of any 
number of physical links. The traffic sent over these AE bundle interfaces are forwarded on any of the 
member links of an AE interface. The traffic can take any physical link based on the hash defined for 
load-balancing the traffic, which makes it difficult to isolate which links have gone bad or are dropping the 
traffic. One way to test the forwarding path available in the network is to add a single-hop static label 
switched path (LSP) with the next hop pointing to a specific member link of the AE interface. 


The default label operation for the static LSPs must be pop and forward. When a packet hits these labeled 
routes, the packet is forwarded on to a specific member link. A unique label is used to identify the member 
link. These labels are referred to as adjacency segment identifiers (SID) and are statically provisioned. 


You can control the flow of the packets in the network by constructing a label stack in controller, which 
includes the labels allocated by all transit static LSP. Operation, Administration, and Maintenance (OAM) 
packets are crafted and injected into the network with entire label-stack. 


When a packet hits this label route the label is popped and traffic is forwarded on the member link specified 
in the configuration. A destination MAC is chosen while forwarding the packet, the destination Mac is the 
aggregate interface MAC address (selected based on nexthop address configured). 


When the member link goes down and aggregate interface is up, then the route corresponding to that 
member link is deleted. When an aggregate interface goes down, then all the routes corresponding to 
member links of the aggregate interface are deleted. When the child physical interface is LACP detached 
but the child physical interface is up, the labeled route for the child link is deleted. In the case of LACP 
detach, if the member link is up and invalid forwarding state, then the OAM packets is dropped in the PFE 
when the child physical interface is detached. 


Use the following example to configure single-hop static LSP for an AE member link. 


1. Define a static label range. 


user@host# set protocols mpls label-range static-label-range 1000000 1048575; 


NOTE: We recommend configuring the default static label range of 1OOO000-1048575 for 
the static LSP. If you wish to configure a label range other than the default static label range, 
configure multiple ranges. 


2. Create a static LSP for the AE member link from the segment routing local block (SRLB) pool of the 
static label range. 


user@host# set protocols mpls static-label-switched-path statc-Isp transit 100001 pop next-hop 
10.1.1.1 member-interface ge-0/0/0 


In this configuration, a transit labelled router is installed in mpls.O, pops the label, and forwards the packet 
down the next hop. The next hop address is mandatory for broadcast interfaces (such as ge-, xe-, ae-) and 
the if-name is used for P2P interfaces (such as so-). The address is required for broadcast interfaces because 
the next hop IP address is used to pick the destination MAC address. The source MAC address for the 
packet is the AE’s MAC address. 


The sample outputs display the member link name in the next hop output: 


show mpls static-Isp extensive 


user@host> show mpls static-lsp extensive 


INC iSSSis} ISIE Ss 
Total 0, displayed 0, Up 0, Down 0 





Transit LSPs: 


LSPname: static-lspl, Incoming-label: 1000001 





Description: verify-static-lsp-—behavior 

State: Up, Sub State: Traffic via primary but unprotected 
Nexthop: 10.2.1.1 Via ae0.0 -> ge-0/0/0 

LabelOperation: Pop 

Created) Thum May2 5) 5s Ss s2'6 2107, 

Bandwidth: 0 bps 

Statistics: Packets 0, Bytes 0 


show route label label-name extensive 


user@host> show route label 1000001 extensive 
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mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) 
1000001 (1 entry, 1 announced) 
WSI8 
KRT in-kernel 1000001/52 -> {Pop } 
SIMIE LYS) Preference: 6 
Next hop type: Router, Next hop index: 611 
Address: Qxb7al17b0 
Next-hop reference count: 2 
Next hop: 10.2.1.1 via ae0.0 -> ge-0/0/0 weight 0x1, selected 
Label operation: Pop 
Load balance label: None; 
Label element ptr: 0xb7al1800 


Label parent element ptr: 0x0 





Label element references: 1 


Label element child references: 0 











Label element lsp id: 0 
Session Id: 0x15d 

State: <Active Int> 

Agere loans Metric: 1 
Validation State: unverified 
Task: MPLS 

Announcement bits (1): 1-KRT 
NMS jOsnclag I 

Label 188765184 


Release History Table 


Release 


20.2R1 


19.4R1 


T9-7R1 


TO. URL 


18.2R1 


Description 


Starting in Junos OS Release 20.2R1, BGP Labeled Unicast (BGP-LU) can resolve IPv4 and IPvé 
routes over IPv4 and IPv6é segment routing-traffic engineering (SR-TE) tunnels. 


You can configure a tunnel template for PCE-initiated segment routing LSPs to pass down two 
additional parameters for these LSPs - Bidirectional forwarding detection (BFD) and LDP tunneling. 


Starting in Junos OS Release 19.1R1, a commit check feature is introduced to ensure that all the 
segment lists contributing to the colored routes have the minimum label present for all hops. 


Starting in Junos OS Release 19.1R1, this requirement does not apply, as the first hop of the 
non-colored static LSPs now provides support for SID labels, in addition to IP addresses. With the 
first hop label support, MPLS fast reroute (FRR) and weighted equal-cost multipath is enabled for 
resolving the static non-colored segment routing LSPs, similar to colored static LSPs. 


Starting in Junos OS Release 18.2R1, statically configured non-colored segment routing LSPs on 
the ingress device are reported to the Path Computation Element (PCE) through a Path Computation 
Element Protocol (PCEP) session. 
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RSVP Overview 


The RSVP protocol is used by routers to deliver quality-of-service (QoS) requests to all nodes along data 
flow path(s) and to establish and maintain state for the requested service. RSVP requests generally result 
in resource reservations in each node along the data path. RSVP has the following attributes: 


e Makes resource reservations for unidirectional data flows. 


e Allows the receiver of a data flow to initiate and maintain the resource reservation used for that flow, 
as shown in Figure 56 on page 770. 


e Maintains a soft state in routers and hosts, providing graceful support for dynamic membership changes 
and automatic adaptation to routing changes. 


e Depends upon present and future routing protocols, but is not a routing protocol itself. 
e Provides several reservation models or styles to fit a variety of applications. 


e Supports both IPv4 and IPv6 packets that can be sent over RSVP-signaled LSPs. 


Figure 56: RSVP Reservation Request and Data Flow 
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RSVP Operation Overview 


RSVP creates independent sessions to handle each data flow. A session is identified by a combination of 
the destination address, an optional destination port, and a protocol. Within a session, there can be one 
or more senders. Each sender is identified by a combination of its source address and source port. An 
out-of-band mechanism, such as a session announcement protocol or human communication, is used to 
communicate the session identifier to all senders and receivers. 


A typical RSVP session involves the following sequence of events: 


1. A potential sender starts sending RSVP path messages to the session address. 


2. Areceiver, wanting to join the session, registers itself if necessary. For example, a receiver in a multicast 
application would register itself with IGMP. 


3. The receiver receives the path messages. 
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4. The receiver sends appropriate Resv messages toward the sender. These messages carry a flow 
descriptor, which is used by routers along the path to make reservations in their link-layer media. 


5. The sender receives the Resv message and then starts sending application data. 


This sequence of events is not necessarily strictly synchronized. For example, receivers can register 
themselves before receiving path messages from the sender, and application data can flow before the 
sender receives Resv messages. Application data that is delivered before the actual reservation contained 
in the Resv message typically is treated as best-effort, non-real-time traffic with no CoS guarantee. 


Understanding the RSVP Signaling Protocol 


IN THIS SECTION 


RSVP Fundamentals | 771 
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RSVP is asignaling protocol that handles bandwidth allocation and true traffic engineering across an MPLS 
network. Like LDP, RSVP uses discovery messages and advertisements to exchange LSP path information 
between all hosts. However, RSVP also includes a set of features that control the flow of traffic through 
an MPLS network. Whereas LDP is restricted to using the configured IGP's shortest path as the transit 
path through the network, RSVP uses a combination of the Constrained Shortest Path First (CSPF) algorithm 
and Explicit Route Objects (EROs) to determine how traffic is routed through the network. 


Basic RSVP sessions are established in exactly the same way that LDP sessions are established. By 
configuring both MPLS and RSVP on the appropriate transit interfaces, you enable the exchange of RSVP 
packets and the establishment of LSPs. However, RSVP also lets you configure link authentication, explicit 
LSP paths, and link coloring. 


This topic contains the following sections: 


RSVP Fundamentals 


RSVP uses unidirectional and simplex flows through the network to perform its function. The inbound 
router initiates an RSVP path message and sends it downstream to the outbound router. The path message 
contains information about the resources needed for the connection. Each router along the path begins 
to maintain information about a reservation. 


When the path message reaches the outbound router, resource reservation begins. The outbound router 
sends a reservation message upstream to the inbound router. Each router along the path receives the 
reservation message and sends it upstream, following the path of the original path message. When the 
inbound router receives the reservation message, the unidirectional network path is established. 


The established path remains open as long as the RSVP session is active. The session is maintained by the 
transmission of additional path and reservation messages that report the session state every 30 seconds. 
If a router does not receive the maintenance messages for 3 minutes, it terminates the RSVP session and 
reroutes the LSP through another active router. 


Bandwidth Reservation Requirement 


When a bandwidth reservation is configured, reservation messages propagate the bandwidth value 
throughout the LSP. Routers must reserve the bandwidth specified across the link for the particular LSP. 
If the total bandwidth reservation exceeds the available bandwidth for a particular LSP segment, the LSP 
is rerouted through another LSR. If no segments can support the bandwidth reservation, LSP setup fails 
and the RSVP session is not established. 


Explicit Route Objects 


Explicit Route Objects (EROs) limit LSP routing to a specified list of LSRs. By default, RSVP messages follow 
a path that is determined by the network IGP's shortest path. However, in the presence of a configured 
ERO, the RSVP messages follow the path specified. 


EROs consist of two types of instructions: loose hops and strict hops. When a loose hop is configured, it 
identifies one or more transit LSRs through which the LSP must be routed. The network IGP determines 
the exact route from the inbound router to the first loose hop, or from one loose hop to the next. The 
loose hop specifies only that a particular LSR be included in the LSP. 


When astrict hop is configured, it identifies an exact path through which the LSP must be routed. Strict-hop 
EROs specify the exact order of the routers through which the RSVP messages are sent. 


You can configure loose-hop and strict-hop EROs simultaneously. In this case, the IGP determines the 
route between loose hops, and the strict-hop configuration specifies the exact path for particular LSP path 
segments. 


Figure 57 on page 773 shows a typical RSVP-signaled LSP that uses EROs. 
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Figure 57: Typical RSVP-Signaled LSP with EROs 
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In the topology shown in Figure 57 on page 773, traffic is routed from Host C1 to Host C2. The LSP can 
pass through Routers R4 or Router R7. To force the LSP to use R4, you can set up either a loose-hop or 
strict-hop ERO that specifies R4 as a hop in the LSP. To force a specific path through Router R4, R3, and 
R6, configure a strict-hop ERO through the three LSRs. 

Constrained Shortest Path First 


Whereas IGPs use the Shortest Path First (SPF) algorithm to determine how traffic is routed within a 
network, RSVP uses the Constrained Shortest Path First (CSPF) algorithm to calculate traffic paths that 
are subject to the following constraints: 


e LSP attributes—Administrative groups such as link coloring, bandwidth requirements, and EROs 


e Link attributes—Colors on a particular link and available bandwidth 


These constraints are maintained in the traffic engineering database (TED). The database provides CSPF 
with up-to-date topology information, the current reservable bandwidth of links, and the link colors. 


In determining which path to select, CSPF follows these rules: 


Computes LSPs one at a time, beginning with the highest priority LSP—the one with the lowest setup 
priority value. Among LSPs of equal priority, CSPF starts with those that have the highest bandwidth 
requirement. 


Prunes the traffic engineering database of links that are not full duplex and do not have sufficient 


reservable bandwidth. 


If the LSP configuration includes the include statement, prunes all links that do not share any included 


colors. 


If the LSP configuration includes the exclude statement, prunes all links that contain excluded colors. If 


a link does not have a color, it is accepted. 
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e Finds the shortest path toward the LSP's outbound router, taking into account any EROs. For example, 
if the path must pass through Router A, two separate SPF algorithms are computed: one from the inbound 
router to Router A and one from Router A to the outbound router. 


e If several paths have equal cost, chooses the one with a last-hop address the same as the LSP's destination. 
e If several equal-cost paths remain, selects the path with the least number of hops. 


e If several equal-cost paths remain, applies CSPF load-balancing rules configured on the LSP. 


Link Coloring 


RSVP allows you to configure administrative groups for CSPF path selection. An administrative group is 
typically named with a color, assigned a numeric value, and applied to the RSVP interface for the appropriate 
link. Lower numbers indicate higher priority. 


After configuring the administrative group, you can either exclude, include, or ignore links of that color in 
the TED: 


e If you exclude a particular color, all segments with an administrative group of that color are excluded 
from CSPF path selection. 


e If you include a particular color, only those segments with the appropriate color are selected. 


e If you neither exclude nor include the color, the metrics associated with the administrative groups and 
applied on the particular segments determine the path cost for that segment. 


The LSP with the lowest total path cost is selected into the TED. 


RSVP-TE protocol extensions for FRR 


Starting with Junos OS Release 16.1, RSVP Traffic Engineering (TE) protocol extensions to support 
Refresh-interval Independent RSVP (RI-RSVP) defined RFC 8370 for fast reroute (FRR) facility protection 
were introduced to allow greater scalability of label-switched paths (LSPs) faster convergence times and 
decrease RSVP signaling message overhead from periodic refreshes. Junos RSVP-TE runs in enhanced 
FRR aka RI-RSVP mode by default that includes protocol extensions to support RI-RSVP for FRR facility 
bypass originally specified in RFC 4090. 


The RI-RSVP protocol extensions implemented in Junos are fully backward compatible. In mixed 
environments, where a subset of LSPs traverse nodes that do not include this feature, Junos RSVP-TE 
running in enhanced FRR mode will automatically turn off the new protocol extensions in its signaling 
exchanges with nodes that do not support the new extensions. 


As part of enhanced FRR profile, a number of changes were made and new defaults adopted. These are 
listed here. 
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RSVP-TE runs “enhanced” FRR, or RI-RSVP mode, by default, which includes enhancements to facilitate 
scaled up scenarios. These new protocol extensions can be disabled on a router with the 
no-enhanced-frr-bypass command. 


RSVP refresh reduction extensions defined in RFC 2961 are enabled by default. The user can disable 
them with the no-reliable command (see below). 


NOTE: Node-id based Hellos are enabled by default as enhanced FRR or RI-RSVP extensions 
require the exchange of Node-id based Hello messages. Node-id based Hellos can be disabled 
with node-hello command. As refresh-reduction extensions and node-id based Hello messages 
are essential for enhanced FRR or RI-RSVP extensions, disabling either of them will automatically 
turn off enhanced FRR extensions on the node. 


The default refresh time for RSVP messages has increased from 30 seconds to 20 minutes. 
The default value for keep-multiplier, which is 3, is applied to the new default refresh time. 


Local reversion is disabled by default. The existing CLI configuration for node Hellos, [edit protocols 
rsvp node-hello], is still available but the action is redundant. If enabled, a message is displayed to indicate 
that the configuration is not necessary in conjunction with enhanced FRR. 


The existing commands to disable message reliability are now used to disable RSVP refresh reduction. 
To revert back to the previous default enabling refresh reduction, use the delete version of the following 


commands: 


e Set no-reliable on a given interface to disable FRR scalability enhancements automatically for all LSPs 
traversing the interface. Likewise, to run RSVP-TE without FRR facility protection enhancements, and 
without refresh-reduction, disable refresh reduction on each interface. Use one of the commands 


shown here: 
e [edit protocols rsvp interface name no-reliable] 
e [edit logical-systems name protocols rsvp interface name no-reliable] 
Graceful restart and nonstop active routing (NSR) are not supported while the LSP undergoes local repair 


or while the LSP is refreshed during backup LSP signaling. This limitation exists already in the 
implementation because GR or NSR switchover during FRR local-repair makes for multiple failure scenario. 


The following operational commands have been updated to include new information about the new 
procedures introduced for the RSVP TE protocol extensions for FRR facility protection. 


e show rsvp version displays whether enhanced FRR procedures are enabled. 
e show rsvp neighbor detail displays whether enhanced FRR procedures are enabled on the neighbor. 


e show rsvp interface detail displays conditional PathTear statistics. 
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e show rsvp statistics displays sent and received statistics for conditional PathTear, along with other 
statistics. 


e show rsvp session extensive displays whether the node is a merge point, and if it is, shows the Point 
of Local Repair (PLR) address. 


e The previous CLI configuration options for enabling or disabling message bundling have been deprecated 
(the existing configurations are accepted, but a warning is displayed in the show configuration output). 
These commands are the following: 


e [edit protocols rsvp interface name aggregate] 
e [edit logical-systems name protocols rsvp interface name aggregate] 
e [edit protocols rsvp interface name no-aggregate] 


e [edit logical-systems name protocols rsvp interface name no-aggregate] 


The following CLI configuration options have been made redundant by the current changes (the existing 
configurations are accepted, but a warning is displayed in the show configuration output): 


e [edit protocols rsvp interface name reliable] 


e [edit logical-systems name protocols rsvp interface name reliable] 


Junos OS RSVP Protocol Implementation 


The Junos implementation of RSVP supports RSVP version 1. The software includes support for all 
mandatory objects and RSVP message types, and supports message integrity and node authentications 
through the Integrity object. 


The primary purpose of the Junos RSVP software is to support dynamic signaling within MPLS label-switched 
paths (LSPs). Supporting resource reservations over the Internet is only a secondary purpose of the Junos 
OS implementation. Since supporting resource reservations is secondary, the Junos RSVP software does 
not support the following features: 


e IP multicasting sessions. 
e Traffic control. The software cannot make resource reservations for real-time video or audio sessions. 


With regard to the protocol mechanism, packet processing, and RSVP objects supported, the Junos OS 
implementation of the software is interoperable with other RSVP implementations. 


RSVP Authentication 


The Junos OS supports both the RSVP authentication style described in RFC 2747 (allowing for multivendor 
compatibility) and the RSVP authentication style described in Internet draft draft-ietf-rsvp-md5-03.txt. 

The Junos OS uses the authentication style described in Internet draft draft-ietf-rsvp-md5-08.txt by default. 
If the router receives an RFC 2747-style RSVP authentication from a neighbor, it switches to this style of 


authentication for that neighbor. The RSVP authentication style for each neighboring router is determined 
separately. 


RSVP and IGP Hello Packets and Timers 


RSVP monitors the status of the interior gateway protocol (IGP) (IS-IS or OSPF) neighbors and relies on 
the IGP protocols to detect when a node fails. If an IGP protocol declares a neighbor down (because hello 
packets are no longer being received), RSVP also brings down that neighbor. However, the IGP protocols 
and RSVP still act independently when bringing a neighbor up. 


In the Junos OS, RSVP typically relies on IGP hello packet detection to check for node failures. Configuring 
a short time for the IS-IS or OSPF hello timers allows these protocols to detect node failures quickly. When 
the node fails or a node failure is detected, a path error message is generated, and although the RSVP 
session goes down, the IGP neighbors remain up. 


RSVP hellos can be relied on when the IGP does not recognize a particular neighbor (for example, if IGP 
is not enabled on the interface) or if the IGP is RIP (not IS-IS or OSPF). Also, the equipment of other vendors 
might be configured to monitor RSVP sessions based on RSVP hello packets. This equipment might also 
take an RSVP session down due to a loss of RSVP hello packets. 


We do not recommend configuring a short RSVP hello timer. If quick discovery of a failed neighbor is 
needed, configure short IGP (OSPF or IS-IS) hello timers. 


OSPF and IS-IS have infrastructure to manage rapid hello message sending and receiving reliably, even if 
the routing protocols or some other process are straining the processing capability of the router. Under 
the same circumstances, RSVP hellos might time out prematurely even though the neighbor is functioning 
normally. 


RSVP Message Types 
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RSVP uses the following types of messages to establish and remove paths for data flows, establish and 
remove reservation information, confirm the establishment of reservations, and report errors: 


Path Messages 


Each sender host transmits path messages downstream along the routes provided by the unicast and 
multicast routing protocols. Path messages follow the exact paths of application data, creating path states 
in the routers along the way, thus enabling routers to learn the previous-hop and next-hop node for the 
session. Path messages are sent periodically to refresh path states. 


The refresh interval is controlled by a variable called the refresh-time, which is the periodical refresh timer 
expressed in seconds. A path state times out if a router does not receive a specified number of consecutive 
path messages. This number is specified by a variable called keep-multiplier. Path states are kept for 

( (keep-multiplier + 0.5) x 1.5 x refresh-time ) seconds. 


Resv Messages 


Each receiver host sends reservation request (Resv) messages upstream toward senders and sender 
applications. Resv messages must follow exactly the reverse path of path messages. Resv messages create 
and maintain a reservation state in each router along the way. 


Resv messages are sent periodically to refresh reservation states. The refresh interval is controlled by the 
same refresh time variable, and reservation states are kept for ( (keep-multiplier + 0.5) x 1.5 x 
refresh-time ) seconds. 


PathTear Messages 


PathTear messages remove (tear down) path states as well as dependent reservation states in any routers 
along a path. PathTear messages follow the same path as path messages. A PathTear typically is initiated 
by a sender application or by a router when its path state times out. 


PathTear messages are not required, but they enhance network performance because they release network 
resources quickly. If PathTear messages are lost or not generated, path states eventually time out when 
they are not refreshed, and the resources associated with the path are released. 


ResvTear Messages 


ResvTear messages remove reservation states along a path. These messages travel upstream toward 
senders of the session. In asense, ResvTear messages are the reverse of Resv messages. ResvTear messages 
typically are initiated by a receiver application or by a router when its reservation state times out. 


ResvTear messages are not required, but they enhance network performance because they release network 
resources quickly. If ResvTear messages are lost or not generated, reservation states eventually time out 
when they are not refreshed, and the resources associated with the reservation are released. 


PathErr Messages 


When path errors occur (usually because of parameter problems in a path message), the router sends a 
unicast PathErr message to the sender that issued the path message. PathErr messages are advisory; these 
messages do not alter any path state along the way. 
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ResvErr Messages 


When a reservation request fails, a ResvErr error message is delivered to all the receivers involved. ResvErr 
messages are advisory; these messages do not alter any reservation state along the way. 


ResvConfirm Messages 


Receivers can request confirmation of a reservation request, and this confirmation is sent with a ResvConfirm 
message. Because of the complex RSVP flow-merging rules, a confirmation message does not necessarily 
provide end-to-end confirmation of the entire path. Therefore, ResvConfirm messages are an indication, 
not a guarantee, of potential success. 


Juniper Networks routers never request confirmation using the ResvConfirm message; however, a Juniper 
Networks router can send a ResvConfirm message if it receives a request from another vendor's equipment. 


Understanding RSVP Automatic Mesh 


When adding sites to BGP and MPLS VPNs that use RSVP signaling, more configuration is needed to add 
provider edge (PE) routers than is needed to add customer edge (CE) devices. RSVP automatic mesh helps 
to reduce this configuration burden. 


Service providers often use BGP and MPLS VPNs to efficiently scale the network while delivering 
revenue-generating services. In these environments, BGP is used to distribute the VPN routing information 
across the service provider's network, while MPLS is used to forward that VPN traffic from one VPN site 
to another. BGP and MPLS VPNs are based on a peer model. To add a new CE device (site) to an existing 
VPN, you need to configure the CE router at the new site and the PE router connected to the CE router. 
You do not have to modify the configuration of all of the other PE routers participating in the VPN. The 
other PE routers automatically learn about the routes associated with the new site, a process called 
automatic discovery (AD). 


The requirements are a bit different if you need to add a new PE router to the network. A BGP and MPLS 
VPN requires that the BGP session be fully meshed and that there also be a full mesh of PE router-to-PE 
router MPLS label-switched paths (LSPs) between all of the PE routers in the network. When you add a 
new PE router to the network, all of the existing PE routers must be reconfigured to peer with the new 
PE router. Much of the configuration effort can be reduced if you configure BGP route reflectors (mitigating 
the full mesh requirement for BGP) and if you configure (LDP) as the signaling protocol for MPLS. 


However, if you need to add a new PE router to a network configured with a full mesh of RSVP-signaled 
LSPs, you must reconfigure each of the PE routers to have a peer relationship with the new PE router. 
You can configure RSVP automatic mesh to address this particular operational scenario. When you enable 
RSVP automatic mesh, RSVP LSPs are dynamically created between a new PE router and the existing PE 
routers, eliminating the need to reconfigure all of the PE routers manually. For dynamic LSP creation to 
function properly, BGP must be configured to exchange routes between all of the participating PE routers. 
If two BGP peers do not exchange routes, it is not possible to configure a dynamic LSP between them. 
The local router’s inet.0 routing table must include a labeled route to each potential IBGP next-hop (future 
potential PE routers or LSP destinations). 
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RSVP includes numerous capabilities that are not available in LDP, including fast reroute, end-point control, 
and link management. RSVP automatic mesh helps to reduce the operation and maintenance requirements 
for RSVP, making it possible to deploy RSVP in larger and more complicated networks. 


Every PE router can reach every other PE router in the network because this information is distributed by 
the IGP. A PE router can set up a point-to-point RSVP LSP to any other PE router in the network as long 
as it knows that such an LSP is required. To build a full mesh of LSPs between the PE routers requires that 
each PE router know which of the other PE routers make up the full mesh. 


NOTE: In Junos OS, RSVP automatic mesh is configured using the rsvp-te configuration statement 
at the [edit routing-options dynamic-tunnels dynamic-tunnel-name] hierarchy level. The rsvp-te 
configuration statement is also available for use in routing instances as a provider-tunnel option. 
When implemented as a provider-tunnel option, rsvp-te is used to configure the RSVP 
point-to-multipoint LSPs for multiprotocol BGP multicast VPNs, not to configure RSVP automatic 
mesh. 


RSVP Reservation Styles 


A reservation request includes options for specifying the reservation style. The reservation styles define 
how reservations for different senders within the same session are treated and how senders are selected. 


Two options specify how reservations for different senders within the same session are treated: 


e Distinct reservation—Each receiver establishes its own reservation with each upstream sender. 


e Shared reservation—All receivers make a single reservation that is shared among many senders. 
Two options specify how senders are selected: 


e Explicit sender—List all selected senders. 


e Wildcard sender—Select all senders, which then participate in the session. 
The following reservation styles, formed by a combination of these four options, currently are defined: 


e Fixed filter (FF)—This reservation style consists of distinct reservations among explicit senders. Examples 
of applications that use fixed-filter-style reservations are video applications and unicast applications, 
which both require flows that have a separate reservation for each sender. The fixed filter reservation 
style is enabled on RSVP LSPs by default. 


e Wildcard filter (WF)—This reservation style consists of shared reservations among wildcard senders. 
This type of reservation reserves bandwidth for any and all senders, and propagates upstream toward 
all senders, automatically extending to new senders as they appear. A sample application for wildcard 
filter reservations is an audio application in which each sender transmits a distinct data stream. Typically, 
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only a few senders are transmitting at any one time. Such a flow does not require a separate reservation 
for each sender; a single reservation is sufficient. 


e Shared explicit (SE)—This reservation style consists of shared reservations among explicit senders. This 
type of reservation reserves bandwidth for a limited group of senders. A sample application is an audio 
application similar to that described for wildcard filter reservations. 


RSVP Refresh Reduction 


RSVP relies on soft-state to maintain the path and reservation states on each router. If the corresponding 
refresh messages are not sent periodically, the states eventually time out and reservations are deleted. 
RSVP also sends its control messages as IP datagrams with no reliability guarantee. It relies on periodic 
refresh messages to handle the occasional loss of Path or Resv messages. 


The RSVP refresh reduction extensions, based on RFC 2961, addresses the following problems that result 
from relying on periodic refresh messages to handle message loss: 


e Scalability—The scaling problem arises from the periodic transmission and processing overhead of refresh 
messages, which increases as the number of RSVP sessions increases. 


e Reliability and latency—The reliability and latency problem stems from the loss of nonrefresh RSVP 
messages or one-time RSVP messages such as PathTear or PathErr. The time to recover from sucha 
loss is usually tied to refresh interval and the keepalive timer. 


The RSVP refresh reduction capability is advertised by enabling the refresh reduction (RR) capable bit in 
the RSVP common header. This bit is only significant between RSVP neighbors. 


RSVP refresh reduction includes the following features: 


e RSVP message bundling using the bundle message 
e RSVP Message ID to reduce message processing overhead 
e Reliable delivery of RSVP messages using Message ID, Message Ack, and Message Nack 


e Summary refresh to reduce the amount of information transmitted every refresh interval 


The RSVP refresh reduction specification (RFC 2961) allows you to enable some or all of the above 
capabilities on a router. It also describes various procedures that a router can use to detect the refresh 
reduction capabilities of its neighbor. 


The Junos OS supports all of the refresh reduction extensions, some of which can be selectively enabled 
or disabled. The Junos OS supports Message ID and therefore can perform reliable message delivery only 
for Path and Resv messages. 


For information about how to configure RSVP refresh reduction, see “Configuring RSVP Refresh Reduction” 
on page 788. 
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MTU Signaling in RSVP 


The maximum transmission unit (MTU) is the largest size packet or frame, in bytes, that can be sent in a 
network. An MTU that is too large might cause retransmissions. Too small an MTU might cause the router 
to send and handle relatively more header overhead and acknowledgments. There are default values for 
MTUs associated with various protocols. You can also explicitly configure an MTU on an interface. 


When an LSP is created across a set of links with different MTU sizes, the ingress router does not know 
what the smallest MTU is on the LSP path. By default, the MTU for an LSP is 1,500 bytes. 


If this MTU is larger than the MTU of one of the intermediate links, traffic might be dropped, because 
MPLS packets cannot be fragmented. Also, the ingress router is not aware of this type of traffic loss, 
because the control plane for the LSP would still function normally. 


To prevent this type of packet loss in MPLS LSPs, you can configure MTU signaling in RSVP. This feature 
is described in RFC 3209. Juniper Networks supports the Integrated Services object for MTU signaling in 
RSVP. The Integrated Services object is described in RFCs 2210 and 2215. MTU signaling in RSVP is 
disabled by default. 


To avoid packet loss due to MTU mismatches, the ingress router needs to do the following: 


e Signal the MTU on the RSVP LSP—To prevent packet loss from an MTU mismatch, the ingress router 
needs to know what the smallest MTU value is along the path taken by the LSP. Once this MTU value 
is obtained, the ingress router can assign it to the LSP. 


e Fragment packets—Using the assigned MTU value, packets that exceed the size of the MTU can be 
fragmented into smaller packets on the ingress router before they are encapsulated in MPLS and sent 
over the RSVP-signaled LSP. 


Once both MTU signaling and packet fragmentation have been enabled on an ingress router, any route 
resolving to an RSVP LSP on this router uses the signaled MTU value. For information about how to 
configure this feature, see “Configuring MTU Signaling in RSVP” on page 809. 


The following sections describe how MTU signaling in RSVP works: 


e How the Correct MTU Is Signaled in RSVP on page 782 
e Determining an Outgoing MTU Value on page 783 
e MTU Signaling in RSVP Limitations on page 783 


How the Correct MTU Is Signaled in RSVP 


How the correct MTU is signaled in RSVP varies depending on whether the network devices (for example, 
routers) explicitly support MTU signaling in RSVP or not. 


If the network devices support MTU signaling in RSVP, the following occur when you enable MTU signaling: 


e The MTU is signaled from the ingress router to the egress router by means of the Adspec object. Before 
forwarding this object, the ingress router enters the MTU value associated with the interface over which 
the path message is sent. At each hop in the path, the MTU value in the Adspec object is updated to the 
minimum of the received value and the value of the outgoing interface. 


e The ingress router uses the traffic specification (Tspec) object to specify the parameters for the traffic 
it is going to send. The MTU value signaled for the Tspec object at the ingress router is the maximum 
MTU value (9192 bytes for M Series and T Series routers, 9500 bytes for PTX Series Packet Transport 
Routers). This value does not change en route to the egress router. 


When the Adspec object arrives at the egress router, the MTU value is correct for the path (meaning it 
is the smallest MTU value discovered). The egress router compares the MTU value in the Adspec object 
to the MTU value in the Tspec object. It signals the smaller MTU using the Flowspec object in the Resv 
message. 


e When the Resv object arrives at the ingress router, the MTU value in this object is used as the MTU for 
the next hops that use the LSP. 


In a network where there are devices that do not support MTU signaling in RSVP, you might have the 
following behaviors: 


e If the egress router does not support MTU signaling in RSVP, the MTU is set to 1,500 bytes by default. 


e A Juniper Networks transit router that does not support MTU signaling in RSVP sets an MTU value of 
1,500 bytes in the Adspec object by default. 


Determining an Outgoing MTU Value 


The outgoing MTU value is the smaller of the values received in the Adspec object compared to the MTU 
value of the outgoing interface. The MTU value of the outgoing interface is determined as follows: 


e If you configure an MTU value under the [family mpls] hierarchy level, this value is signaled. 


e If you do not configure an MTU, the inet MTU is signaled. 


MTU Signaling in RSVP Limitations 


The following are limitations to MTU signaling in RSVP: 
e Changes in the MTU value might cause a temporary loss of traffic in the following situations: 


e For link protection and node protection, the MTU of the bypass is only signaled at the time the bypass 
becomes active. During the time it takes for the new path MTU to be propagated, packet loss might 
occur because of an MTU mismatch. 
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e For fast reroute, the MTU of the path is updated only after the detour becomes active, causing a delay 
in an update to the MTU at the ingress router. Until the MTU is updated, packet loss might occur if 
there is an MTU mismatch. 


In both cases, only packets that are larger than the detour or bypass MTU are lost. 
e When an MTU is updated, it triggers a change in the next hop. Any change in the next hop causes the 
route statistics to be lost. 


e The minimum MTU supported for MTU signaling in RSVP is 1,488 bytes. This value prevents a false or 
incorrectly configured value from being used. 


e For single-hop LSPs, the MTU value displayed by the show commands is the RSVP-signaled value. 
However, this MPLS value is ignored and the correct IP value is used. 


Release History Table 


Release Description 


16.4 Starting with Junos OS Release 16.1, RSVP Traffic Engineering (TE) protocol extensions to support 
Refresh-interval Independent RSVP (RI-RSVP) defined RFC 8370 for fast reroute (FRR) facility 
protection were introduced to allow greater scalability of label-switched paths (LSPs) faster 
convergence times and decrease RSVP signaling message overhead from periodic refreshes. 
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Minimum RSVP Configuration 
To enable RSVP on a single interface, include the rsvp statement and specify the interface using the 


interface statement. This is the minimum RSVP configuration. All other RSVP configuration statements 
are optional. 


rsvp { 
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interface interface-name; 


You can include these statements at the following hierarchy levels: 


e [edit protocols] 


e [edit logical-systems logical-system-name protocols] 
To enable RSVP on all interfaces, substitute all for the interface-name variable. 


If you have configured interface properties on a group of interfaces and want to disable RSVP on one of 
the interfaces, include the disable statement: 


interface interface-name { 
disable; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp interface interface-name | 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name | 


Configuring RSVP and MPLS 


The primary purpose of the Junos RSVP software is to support dynamic signaling within label-switched 
paths (LSPs). When you enable both MPLS and RSVP on a router, MPLS becomes a client of RSVP. No 
additional configuration is required to bind MPLS and RSVP. 


You can configure MPLS to set up signaled paths by using the label-switched-path statement at the [edit 
protocols mpls] hierarchy level. Each LSP translates into a request for RSVP to initiate an RSVP session. 
This request is passed through the internal interface between label switching and RSVP. After examining 
the request information, checking RSVP states, and checking the local routing tables, RSVP initiates one 
session for each LSP. The session is sourced from the local router and is destined for the target of the LSP. 


When an RSVP session is successfully created, the LSP is set up along the paths created by the RSVP 
session. If the RSVP session is unsuccessful, RSVP notifies MPLS of its status. It is up to MPLS to initiate 
backup paths or continue retrying the initial path. 


To pass label-switching signaling information, RSVP supports four additional objects: Label Request object, 
Label object, Explicit Route object, and Record Route object. For an LSP to be set up successfully, all routers 
along the path must support MPLS, RSVP, and the four objects. Of the four objects, the Record Route 
object is not mandatory. 
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To configure MPLS and make it a client of RSVP, do the following: 


e Enable MPLS on all routers that will participate in the label switching (this is, on all routers that might 
be part of a label-switching path). 


e Enable RSVP on all routers and on all router interfaces that form the LSP. 


e Configure the routers at the beginning of the LSP. 


Example: Configuring RSVP and MPLS 


The following shows a sample configuration for a router at the beginning of an LSP: 


[edit] 
protocols { 
mpls { 
label-switched-path sf-to-london { 
to 192.168.1.4; 


} 


rsvp { 
interface so-0/0/0; 


The following shows a sample configuration for all the other routers that form the LSP: 


[edit] 
protocols { 
mpls { 
interface so-0/0/0; 
} 


rsvp { 
interface so-0/0/0; 


Configuring RSVP Interfaces 


IN THIS SECTION 


@ = Configuring RSVP Refresh Reduction | 788 
® = Configuring the RSVP Hello Interval | 790 
® = Configuring RSVP Authentication | 791 
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@® Configuring the Bandwidth Subscription for Class Types | 791 
@ Configuring the RSVP Update Threshold on an Interface | 791 
@® Configuring RSVP for Unnumbered Interfaces | 793 


The following sections describe how to configure RSVP interfaces: 


Configuring RSVP Refresh Reduction 


You can configure RSVP refresh reduction on each interface by including the following statements in the 
interface configuration: 


aggregate and reliable—Enable all RSVP refresh reduction features: RSVP message bundling, RSVP 
message ID, reliable message delivery, and summary refresh. 


In order to have refresh reduction and reliable delivery, you must include the aggregate and reliable 
statements. 


e no-aggregate—Disable RSVP message bundling and summary refresh. 
e no-reliable—Disable RSVP message ID, reliable message delivery, and summary refresh. 


For more information on RSVP refresh reduction, see “RSVP Refresh Reduction” on page 781. 


If the no-reliable statement is configured on the router (reliable message delivery is disabled), the router 
accepts RSVP messages that include the Message ID object but ignores the Message ID object and continues 
performing standard message processing. No error is generated in this case, and RSVP operates normally. 


However, not all combinations between two neighbors with different refresh reduction capabilities function 
correctly. For example, a router is configured with either the aggregate statement and no-reliable statement 
or with the reliable and no-aggregate statements. If an RSVP neighbor sends a Summary Refresh object 
to this router, no error is generated, but the Summary Refresh object cannot be processed. Consequently, 
RSVP states can time out on this router if the neighbor is relying only on Summary Refresh to refresh those 
RSVP states. 


We recommend, unless there are specific requirements, that you configure RSVP refresh reduction in a 
similar manner on each RSVP neighbor. 


To enable all RSVP refresh reduction features on an interface, include the aggregate statement: 


aggregate; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp interface interface-name] 
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e [edit logical-systems logical-system-name protocols rsvp interface interface-name] 


To disable RSVP message bundling and summary refresh, include the no-aggregate statement: 


no-aggregate; 


You can include this statement at the following hierarchy levels: 
e [edit protocols rsvp interface interface-name] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name] 


To enable RSVP message ID and reliable message delivery on an interface, include the reliable statement: 


reliable; 


You can include this statement at the following hierarchy levels: 
e [edit protocols rsvp interface interface-name] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name] 


To disable RSVP message ID, reliable message delivery, and summary refresh, include the no-reliable 
statement: 


no-reliable; 


You can include this statement at the following hierarchy levels: 
e [edit protocols rsvp interface interface-name] 
e [edit logical-systems logical-system-name protocols rsvp interface interface-name] 


Determining the Refresh Reduction Capability of RSVP Neighbors 


To determine the RSVP refresh reduction capability of an RSVP neighbor, you need the following 
information: 


e The RR bit advertised by the neighbor 
e The local configuration of RSVP refresh reduction 


e The actual RSVP messages received from the neighbor 


To obtain this information, you can issue a show rsvp neighbor detail command. Sample output follows: 


user@host> show rsvp neighbor detail 


RSVP neighbor: 6 learned 
Melcheases, IZ. Gi) 224), 17s wales ixqol © Siracrwes Wo 
Inisic, Gligingacl itameas LOs0G, welles 5 see, Wo cies 1, Wemwnm cmes 
Message received: 36 





Hello: sent 69, received: 69, interval: 9 sec 
Remote instance: O0x60b8feba, Local instance: 0x74bc7a8d 


Refresh reduction: not operational 


Address: 192.168.224.186 via: fxp2.0 status: Down 
Last changed time: 10:17, Idle: 40 sec, Up cnt: 0, Down cnt: 0 





Message received: 6 

Hello: sent 20, received: 0, interval: 9 sec 
Remote instance: 0x0, Local instance: 0x2ae1b339 
Refresh reduction: incomplete 


Remote end: disabled, Ack-extension: enabled 


Address: 192.168.224.188 via: fxp2.0 status: Up 
lnaisic Claaimeecl itamas “@eils, wellas © see, Ws ents 1, Demin emies 0 
Message received: 55 





Hello: sent 47, received: 31, interval: 9 sec 
Remote instance: 0x6436a35b, Local instance: 0x663849£f0 


Refresh reduction: operational 





Remot nd: enabled, Ack-extension: enabled 


For more information on the show rsvp neighbor detail command. 


Configuring the RSVP Hello Interval 


RSVP monitors the status of the interior gateway protocol (IGP) (IS-IS or OSPF) neighbors and relies on 
the IGP protocols to detect when a node fails. If an IGP protocol declares a neighbor down (because hello 
packets are no longer being received), RSVP also brings down that neighbor. However, the IGP protocols 
and RSVP still act independently when bringing a neighbor up. 


For Juniper Networks routers, configuring a shorter or longer RSVP hello interval has no impact on whether 
or not an RSVP session is brought down. RSVP sessions are kept up even if RSVP hello packets are no 
longer being received. RSVP sessions are maintained until either the router stops receiving IGP hello 
packets or the RSVP Path and Resv messages time out. However, starting from Junos OS Release 16.1, 
when RSVP hello messages time-out, the RSVP sessions are brought down. 


The RSVP hello interval might also be impacted when another vendor's equipment brings down an RSVP 
session. For example, a neighboring non-Juniper Networks router might be configured to monitor RSVP 
hello packets. 


790 


791 


To modify how often RSVP sends hello packets, include the hello-interval statement: 


hello-interval seconds; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section. 


Configuring RSVP Authentication 


All RSVP protocol exchanges can be authenticated to guarantee that only trusted neighbors participate 
in setting up reservations. By default, RSVP authentication is disabled. 


RSVP authentication uses a Hashed Message Authentication Code (HMAC)-MD5 message-based digest. 
This scheme produces a message digest based on a secret authentication key and the message contents. 
(The message contents also include a sequence number.) The computed digest is transmitted with RSVP 
messages. Once you have configured authentication, all received and transmitted RSVP messages with all 
neighbors are authenticated on this interface. 


MD5 authentication provides protection against forgery and message modification. It also can prevent 
replay attacks. However, it does not provide confidentiality, because all messages are sent in clear text. 


By default, authentication is disabled. To enable authentication, configure a key on each interface by 
including the authentication-key statement: 


authentication-key key; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp interface interface-name] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name] 


Configuring the Bandwidth Subscription for Class Types 


By default, RSVP allows 100 percent of the bandwidth for a class type to be used for RSVP reservations. 
When you oversubscribe a class type for a multiclass LSP, the aggregate demand of all RSVP sessions is 
allowed to exceed the actual capacity of the class type. 


For detailed instructions on how to configure the bandwidth subscription for class types, see “Configuring 
the Bandwidth Subscription Percentage for LSPs” on page 568. 


Configuring the RSVP Update Threshold on an Interface 


The interior gateway protocols (IGPs) maintain the traffic engineering database, but the current available 
bandwidth on the traffic engineering database links originates from RSVP. When a link’s bandwidth changes, 
RSVP informs the IGPs, which can then update the traffic engineering database and forward the new 
bandwidth information to all network nodes. The network nodes then know how much bandwidth is 
available on the traffic engineering database link (local or remote), and CSPF can correctly compute the 
paths. 


However, IGP updates can consume excessive system resources. Depending on the number of nodes in 
a network, it might not be desirable to perform an IGP update for small changes in bandwidth. By configuring 
the update-threshold statement at the [edit protocols rsvp] hierarchy level, you can adjust the threshold 
at which a change in the reserved bandwidth triggers an IGP update. 


You can configure a value of from 0.001 percent through 20 percent (the default is 10 percent) for when 
to trigger an IGP update. If the change in the reserved bandwidth is greater than or equal to the configured 
threshold percentage of the static bandwidth on that interface, then an IGP update occurs. For example, 
if you have configured the update-threshold statement to be 15 percent and the router discovers that 
the reserved bandwidth ona link has changed by 10 percent of the link bandwidth, RSVP does not trigger 
an IGP update. However, if the reserved bandwidth on a link changes by 20 percent of the link bandwidth, 
RSVP triggers an IGP update. 


You can also configure the threshold as an absolute value using the threshold-value option under the 
update-threshold statement. 


If the threshold-value is configured to greater than 20% of bandwidth on that link, the threshold-value is 
capped at 20% of bandwidth. 


For instance, if bandwidth on an interface is 1Gbps, and the threshold-value is configured greater than 
200Mbps, the threshold-value is capped at 200Mbps. The threshold-percent is displayed as 20.000% and 
the threshold-value as 200Mbps. 


NOTE: The two options, threshold-percent and threshold-value, are mutually exclusive. You can 
configure only one option at a given point in time to generate an IGP update for lower bandwidth 
reservations. As a result, when one option is configured, the other option is calculated and 
displayed on the CLI. 


For instance, on a link of 1Gbps, if the threshold-percent is configured to 5%, the threshold-value 
is calculated and displayed as 50Mbps. Similarly, if the threshold-value is configured to 50m, 
then the threshold-percent is calculated and displayed as 5%. 


To adjust the threshold at which a change in the reserved bandwidth triggers an IGP update, include the 
update-threshold statement. Because of the update threshold, it is possible for Constrained Shortest Path 
First (CSPF) to compute a path using outdated traffic engineering database bandwidth information on a 
link. If RSVP attempts to establish an LSP over that path, it might find that there is insufficient bandwidth 
on that link. When this happens, RSVP triggers an IGP traffic engineering database update, flooding the 
updated bandwidth information on the network. CSPF can then recompute the path by using the updated 
bandwidth information, and attempt to find a different path, avoiding the congested link. Note that this 
functionality is the default and does not need any additional configuration. 


You can configure the rsvp-error-hold-time statement at the [edit protocols mpls] hierarchy level or the 
[edit logical-systems logical-system-name protocols mpls] hierarchy level to improve the accuracy of the 
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traffic engineering database (including the accuracy of bandwidth estimates for LSPs) using information 
provided by PathErr messages. See “Improving Traffic Engineering Database Accuracy with RSVP PathErr 
Messages” on page 1115. 


Configuring RSVP for Unnumbered Interfaces 


The Junos OS supports RSVP traffic engineering over unnumbered interfaces. Traffic engineering information 
about unnumbered links is carried in the IGP traffic engineering extensions for OSPF and IS-IS as described 
in RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS), and RFC 4205, 
Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label 
Switching (GMPLS). Unnumbered links can also be specified in the MPLS traffic engineering signaling as 
described in RFC 3477, Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering 
(RSVP-TE). This feature allows you avoid having to configure IP addresses for each interface participating 
in the RSVP-signaled network. 


To configure RSVP for unnumbered interfaces, you must configure the router with a router ID using the 
router-id statement specified at the [edit routing-options] hierarchy level. The router ID must be available 
for routing (you can typically use the loopback address). The RSVP control messages for the unnumbered 
links are sent using the router ID address (rather than a randomly selected address). 


To configure link protection and fast reroute on a router with unnumbered interfaces enabled, you must 
configure at least two addresses. We recommend that you configure a secondary interface on the loopback 
in addition to configuring the router ID. 


Configuring RSVP Node-ID Hellos 


You can configure node-ID based RSVP hellos to ensure that Juniper Networks routers can interoperate 
with the equipment of other vendors. By default, Junos OS uses interface-based RSVP hellos. Node-ID 
based RSVP hellos are specified in RFC 4558, Node-ID Based Resource Reservation Protocol (RSVP) Hello: A 
Clarification Statement. RSVP node-ID hellos are useful if you have configured BFD to detect problems 
over RSVP interfaces, allowing you to disable interface hellos for these interfaces. You can also use node-ID 
hellos for graceful restart procedures. 


Node-ID hellos can be enabled globally for all RSVP neighbors. By default, node-ID hello support is disabled. 
If you have not enabled RSVP node IDs on the router, the Junos OS does not accept any node-ID hello 
packets. 


To enable RSVP node-ID hellos globally on the router, include the node-hello statement at the following 
hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-systems-name protocols rsvp] 
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You can also explicitly disable RSVP interface hellos globally. This type of configuration might be necessary 
in networks where the Juniper Networks router has numerous RSVP connections with equipment from 
other vendors. However, if you disable RSVP interface hellos globally, you can also configure a hello interval 
onan RSVP interface using the hello-interval statement. This configuration disables RSVP interface hellos 
globally, but enables RSVP interface hellos on the specified interface (the RSVP interface you configure 
the hello-interval statement on). This configuration might be necessary in a heterogeneous network in 
which some devices support RSVP node-ID hellos and other devices support RSVP interface hellos. 


To disable RSVP interface hellos globally on the router, include the no-interface-hello statement at the 
following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-systems-name protocols rsvp] 


Example: Configuring RSVP-Signaled LSPs 


IN THIS SECTION 


Requirements | 794 
Overview and Topology | 794 
Configuration | 795 


Verification | 797 


This example shows how to create an LSP between routers in an IP network using RSVP as the signaling 
protocol. 
Requirements 


Before you begin, delete security services from the device. See Example: Deleting Security Services. 


Overview and Topology 


Using RSVP as a signaling protocol, you can create LSPs between routers in an IP network. In this example, 
you configure a sample network as shown in Figure 58 on page 795. 


Figure 58: Typical RSVP-Signaled LSP 
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To establish an LSP between routers, you must individually enable the MPLS family and configure RSVP 
on each of the transit interfaces in the MPLS network. This example shows how to enable MPLS and 
configure RSVP on the ge-0/0/0 transit interface. Additionally, you must enable the MPLS process on all 


of the MPLS interfaces in the network. 


This example shows how to define an LSP from R11 to R7 on the ingress router (R1) using R7’s loopback 
address (10.0.9.7). The configuration reserves 10 Mbps of bandwidth. Additionally, the configuration 
disables the CSPF algorithm, ensuring that Hosts C1 and C2 use the RSVP-signaled LSP that correspond 


to the network IGP's shortest path. 
Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 


the commands into the CLI at the [edit] hierarchy level. 


set interfaces ge-0/0/0 unit O family mpls 

set protocols rsvp interface ge-0/0/0.0 

set protocols mpls label-switched-path r1-r7 to 10.0.9.7 

set protocols mpls label-switched-path r1-r7 bandwidth 10m 
set protocols mpls interface all 


Step-by-Step Procedure 
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The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure RSVP: 


1. Enable the MPLS family on all transit interfaces in the MPLS network. 


[edit] 
user@host# set interfaces ge-0/0/0 unit O family mpls 


2. Enable RSVP on each transit interface in the MPLS network. 


[edit] 
user @host# set protocols rsvp interface ge-0/0/0 


3. Enable the MPLS process on the transit interface in the MPLS network. 


[edit] 
user@host# set protocols mpls interface ge-0/0/0 


4. Define the LSP on the ingress router. 


[edit protocols mpls] 
user@host# set label-switched-path r1-r7 to 10.0.9.7 


5. Reserve 10 Mbps of bandwidth on the LSP. 


[edit protocols mpls] 
user @host# set label-switched-path r1-r7 bandwidth 10m 


Results 


Confirm your configuration by entering the show command from configuration mode. If the output does 
not display the intended configuration, repeat the configuration instructions in this example to correct it. 


For brevity, this show command output includes only the configuration that is relevant to this example. 
Any other configuration on the system has been replaced with ellipses (...). 


user@host# show 
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interfaces { 

ge-0/0/0 { 
family mpls; 
} 

} 

} 


protocols { 
rsvp { 
interface ge-0/0/0.0; 
} 
mpls { 
label-switched-path r1-r7 { 
to 10.0.9.7; 
bandwidth 10m; 


} 


interface all; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


@ Verifying RSVP Neighbors | 797 
@ Verifying RSVP Sessions | 798 
@ Verifying the Presence of RSVP-Signaled LSPs | 799 


To confirm that the configuration is working properly, perform these tasks: 


Verifying RSVP Neighbors 


Purpose 
Verify that each device shows the appropriate RSVP neighbors—for example, that Router R1 in 
Figure 58 on page 795 lists both Router R3 and Router R2 as RSVP neighbors. 


Action 
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From the CLI, enter the show rsvp neighbor command. 


user@r1> show rsvp neighbor 


RSVP neighbor: 2 learned 


Address Idle Up/Dn LastChange HelloInt HelloTx/Rx 
10 60.6.2 Ome 2 sgl S 366/349 
IO .O 343 QO i1/@ 22:49 5 448/448 


The output shows the IP addresses of the neighboring routers. Verify that each neighboring RSVP router 
loopback address is listed. 


Verifying RSVP Sessions 


Purpose 


Verify that an RSVP session has been established between all RSVP neighbors. Also, verify that the 
bandwidth reservation value is active. 


Action 


From the CLI, enter the show rsvp session detail command. 


user@rl> show rsvp session detail 


Ingress RSVP: 1 sessions 


10-059. 7 
From: 10.0.6.1, LSPstate: Up, ActiveRoute: 0 





LSPname: rl-r7, LSPpath: Primary 





Bidirectional, Upstream label in: , Upstream label out: - 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 100000 
Resv style: 1 FF, Label in: -, Label out: 100000 





Time left: =, Silnees wan dam 26 I7ea7sas 2002 





Tspec: rate 10Mbps size 10Mbps peak Infbps m 20 M 1500 





Port number: sender 3 receiver 17 protocol 0 

PATH revfrom: localclient 

PATH sentto: 10.0.4.13 (ge-0/0/1.0) 1467 pkts 

RESV revirom: 10.0.4.13 (ge-0/0/1.0) 1467 pkts 
Recoel iouees <selle> WOs0 4513 IO.062.1 1050 3.10) 








The output shows the detailed information, including session IDs, bandwidth reservation, and next-hop 
addresses, for each established RSVP session. Verify the following information: 
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e Each RSVP neighbor address has an entry for each neighbor, listed by loopback address. 
e The state for each LSP session is Up. 


e For Tspec, the appropriate bandwidth value, 1OMbps, appears. 


Verifying the Presence of RSVP-Signaled LSPs 


Purpose 


Verify that the routing table of the entry (ingress) router has a configured LSP to the loopback address of 
the other router. For example, verify that the inet.3 routing table of the R1 entry router in 
Figure 58 on page 795 has a configured LSP to the loopback address of Router R7. 


Action 


From the CLI, enter the show route table inet.3 command. 


user@rl> show route table inet.3 


inet.3: 2 destinations, 2 routes (2 active, 0 holddown, O hidden) 


+ = Active Route, Last Active, * = Both 








10.0 59.7/ 32 *[RSVP/7] 00:05:29, metric 10 
PaOmel OM Ome lW/mnvel amg C010) OOF mmalo clk Ss walkte clic Gl toc thnmetaltaata’ 


The output shows the RSVP routes that exist in the inet.3 routing table. Verify that an RSVP-signaled LSP 
is associated with the loopback address of the exit (egress) router, R7, in the MPLS network. 


Example: Configuring RSVP Automatic Mesh 


IN THIS SECTION 


Requirements | 800 
Overview | 800 
Configuration | 801 


Verification | 802 


Service providers often use BGP and MPLS VPNs to efficiently scale the network while delivering 
revenue-generating services. In these environments, BGP is used to distribute the VPN routing information 
across the service provider's network, while MPLS is used to forward that VPN traffic from one VPN site 
to another. 
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When adding a new PE router that will participate in BGP and MPLS VPNs, all of the previously existing 
PE routers must be configured to peer with the new PE router for both BGP and MPLS. As each new PE 
router is added to the service provider's network, the configuration burden soon becomes too much to 
handle. 


The configuration requirements for BGP peering can be reduced with the use of route reflectors. In RSVP 
signaled MPLS networks, RSVP automatic mesh can minimize the configuration burden for the MPLS 
portion of the network. Configuring rsvp-te on all PE routers allows RSVP to automatically create the 
needed LSPs when a new PE router is added. 


Requirements 


This example uses the following hardware and software components: 


e Arouter running Junos OS Release 10.1 or later. 


e A BGP and MPLS VPN using RSVP as the MPLS label-switched path (LSP) signaling protocol. 


Overview 


This example shows how to configure RSVP automatic mesh ona PE router using the rsvp-te configuration 
statement. In order for RSVP automatic mesh to function properly, all of the PE routers in the full mesh 
configuration must have the rsvp-te statement configured. This ensures that any new PE routers that are 
added later will also benefit from the automatic mesh feature, provided that they too are configured with 
the rsvp-te statement. 


Given this requirement, this example only shows the configuration on the newly added PE router. It is 
assumed that RSVP automatic mesh has already been configured on the existing PE routers. 


Topology 


In Figure 59 on page 800, there are three existing PE routers, PE1, PE2, and PE3, in the topology. PE4 has 
been added, and RSVP automatic mesh will be configured. The cloud represents the service provider 
network, and the network address, 192.0.2.0/24, is shown in the center of the figure. 


Figure 59: Service Provider Network with PE Routers 
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Configuration 


IN THIS SECTION 


@ = Configuring RSVP Automatic Mesh | 801 
@ Results | 802 


Configuring RSVP automatic mesh involves performing these tasks: 


e Enabling the rsvp-te configuration statement at the [edit routing-options dynamic-tunnels 
dynamic-tunnel-name] hierarchy level. 


e Configuring the required destination-networks element. 


This configuration element specifies the IPv4 prefix range for the destination network. Only tunnels 
within the specified prefix range can be created. 


e Configuring the required label-switched-path-template element. 


This configuration element takes either default-template or the name of a preconfigured LSP template 
as an argument. The default-template is a system-defined template that requires no user configuration. 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


PE4 Router 


set routing-options dynamic-tunnels dt-1 rsvp-te rsvp-te-1 label-switched-path-template 
default-template 
set routing-options dynamic-tunnels dt-1 rsvp-te rsvp-te-1 destination-networks 192.0.2.0/24 


Configuring RSVP Automatic Mesh 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For instructions 
on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To enable RSVP automatic mesh: 


1. Configure rsvp-te at the [edit routing-options dynamic-tunnels] hierarchy level. 
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[edit routing-options dynamic-tunnels] 
user@PE4# set dt-1 rsvp-te rsvp-te-1 label-switched-path-template default-template 


2. Configure destination-networks at the [edit routing-options dynamic-tunnels] hierarchy level. 


[edit routing-options dynamic-tunnels] 
user@PE4# set dt-1 rsvp-te rsvp-te-1 destination-networks 192.0.2.0/24 


Results 


Issue the show command from the [edit routing-options dynamic-tunnels] hierarchy level to see the results 
of your configuration: 


[edit routing-options dynamic-tunnels] 
user@PE4#show 
dt-1 { 
rsvp-te rsvp-te-1 { 
label-switched-path-template { 
default-template; 


} 


destination-networks { 
192.0.2.0/24; 


Verification 


IN THIS SECTION 


@ = - Verifying the Existence of RSVP Automatic Mesh Tunnels on Router PE4 | 802 
@ Verifying the Existence of MPLS LSPs on Router PE4 | 803 


Verifying the Existence of RSVP Automatic Mesh Tunnels on Router PE4 


Purpose 
To verify the operation of the newly configured PE4 router, issue the show dynamic-tunnels database 
command from operational mode. This command will show the destination network to which dynamic 


tunnels can be created. 
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Action 


user@PE4> show dynamic-tunnels database 
Table: inet.3 
Destination-network: 192.0.2.0/24 


Verifying the Existence of MPLS LSPs on Router PE4 


Purpose 


To verify the existence of MPLS LSPs on the PE4 router, issue the show mpls Isp command from operational 
mode. This command will show the state of the MPLS LSPs. 


Action 


user@PE4> show mpls Isp 


Ingress LSP: O sessions 

Total O displayed, Up 0, Down O 

Egress LSP: 3 sessions 

To From State Rt Style Labelin Labelout LSPname 
192.0.2.104 192.0.2.103 Up 0 1 FF 3 - PE2-PE4 
192.0.2.104 192.0.2.102 Up O 1 FF 3 - PE2-PE4 
192.0.2.104 192.0.2.101 Up 0 1 FF 3 - PE1-PE4 
Total 3 displayed, Up 3, Down O 

Transit LSP: 0 sessions 

Total O displayed, Up 0, Down O 


Configuring Hello Acknowledgments for Nonsession RSVP Neighbors 


The hello-acknowledgements statement controls the hello acknowledgment behavior between RSVP 
neighbors regardless of whether or not they are in the same session. 


Hello messages received from RSVP neighbors that are not part of acommon RSVP session are discarded. 
If you configure the hello-acknowledgements statement at the [edit protocols rsvp] hierarchy level, hello 
messages from nonsession neighbors are acknowledged with a hello acknowledgment message. When 
hellos are received from nonsession neighbors, an RSVP neighbor relationship is created and periodic hello 
messages can now be received from the nonsession neighbor. The hello-acknowledgements statement 
is disabled by default. Configuring this statement allows RSVP-capable routers to be discovered using hello 
packets and verifies that the interface is able to receive RSVP packets before sending any MPLS LSP setup 
messages. 


Once you enable hello acknowledgments for nonsession RSVP neighbors, the router continues to 
acknowledge hello messages from any nonsession RSVP neighbors unless the interface itself goes down 
or you change the configuration. Interface-based neighbors are not automatically aged out. 


hello-acknowledgements; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 


Switching LSPs Away from a Network Node 


You can configure the router to switch active LSPs away from a network node using a bypass LSP enabled 
for an interface. This feature might be used to maintain active networks when a device needs to be replaced 
without interrupting traffic transiting the network. The LSPs can be either static or dynamic. 


1. You first need to configure either link or node protection for the traffic that needs to pass around the 
network device you intend to disable. To function properly, the bypass LSP must use a different logical 
interface than the protected LSP. 


2. To prepare the router to begin switching traffic away from a network node, configure the 
always-mark-connection-protection-tlv statement: 


always-mark-connection-protection-tlv; 


The router then marks all OAM traffic transiting this interface in preparation for switching the traffic 
to an alternate path based on the OAM functionality. 


You can configure this statement at the following hierarchy levels: 


e [edit protocols mpls interface interface-name] 
e [edit logical-systems logical-system-name protocols mpls interface interface-name] 


3. You then need to configure the switch-away-lsps statement to switch the traffic from the protected 
LSP to the bypass LSP, effectively bypassing the default downstream network device. The actual link 
itself is not brought down by this configuration. 


To configure the router to switch traffic away from a network node, configure the switch-away-Isps 
statement: 


switch-away-lsps; 
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You can configure this statement at the following hierarchy levels: 


e [edit protocols mpls interface interface-name] 


e [edit logical-systems logical-system-name protocols mpls interface interface-name] 
Note the following limitations related to switching active LSPs away from a network node: 


e The switch-away feature is supported on MX Series routers only. 


e The switch-away feature is not supported for switching traffic from primary point-to-multipoint LSPs 
to bypass point-to-multipoint LSPs. If you configure the switch-away-lsps statement for a 
point-to-multipoint LSP, traffic is not switched to the bypass point-to-multipoint LSP. 


e If you configure the switch-away feature on an interface along the path of a dynamic LSP, new dynamic 
LSPs cannot be established over that path. The switch-away feature prevents the make-before-break 
behavior of RSVP-signaled LSPs. The make-before-break behavior normally causes the router to first 
attempt to re-signal a dynamic LSP before tearing down the original. 


Configuring RSVP Setup Protection 


You can configure the facility-backup fast reroute mechanism to provide setup protection for LSPs which 
are in the process of being signaled. Both point-to-point LSPs and point-to-multipoint LSPs are supported. 
This feature is applicable in the following scenario: 


1. A failed link or node is present on the strict explicit path of an LSP before the LSP is signaled. 
2. There is also a bypass LSP protecting the link or node. 


3. RSVP signals the LSP through the bypass LSP. The LSP appears as if it was originally set up along its 
primary path and then failed over to the bypass LSP because of the link or node failure. 


4. When the link or node has recovered, the LSP can be automatically reverted to the primary path. 


You should configure the setup-protection statement at the [edit protocols rsvp] on each of the routers 
along the LSP path on which you want to enable LSP setup protection. You should also configure IGP 
traffic engineering on all of the routers on the LSP path. You can issue a show rsvp session command to 
determine whether or not the LSP has setup protection enabled on a router acting as a point of local repair 
(PLR) or a merge point. 


To enable RSVP setup protection, include the setup-protection statement 


setup-protection; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 
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Configuring Load Balancing Across RSVP LSPs 


By default, when you have configured several RSVP LSPs to the same egress router, the LSP with the 
lowest metric is selected and carries all traffic. If all of the LSPs have the same metric, one of the LSPs is 
selected at random and all traffic is forwarded over it. 


Alternatively, you can load-balance traffic across all of the LSPs by enabling per-packet load balancing. 


To enable per-packet load balancing on an ingress LSP, configure the policy-statement statement as 
follows: 


[edit policy-options] 
policy-statement policy-name { 
then { 
load-balance per-packet; 


} 


accept; 


You then need to apply this statement as an export policy to the forwarding table. 
Once per-packet load balancing is applied, traffic is distributed equally between the LSPs (by default). 


You need to configure per-packet load balancing if you want to enable PFE fast reroute. To enable PFE 
fast reroute, include the policy-statement statement for per-packet load balancing shown in this section 
in the configuration of each of the routers where a reroute might take place. See also “Configuring Fast 
Reroute” on page 474. 


You can also load-balance the traffic between the LSPs in proportion to the amount of bandwidth configured 
for each LSP. This capability can better distribute traffic in networks with asymmetric bandwidth capabilities 
across external links, since the configured bandwidth of an LSP typically reflects the traffic capacity of 
that LSP. 


To configure RSVP LSP load balancing, include the load-balance statement with the bandwidth option: 


load-balance { 
bandwidth; 


You can configure this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 
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Keep the following information in mind when you use the load-balance statement: 


e If you configure the load-balance statement, the behavior of currently running LSPs is not altered. To 
force currently running LSPs to use the new behavior, you can issue a clear mpls Isp command. 


e The load-balance statement only applies to ingress LSPs that have per-packet load balancing enabled. 


e For Differentiated Services-aware traffic engineered LSPs, the bandwidth of an LSP is calculated by 
summing the bandwidth of all of the class types. 


Configuring RSVP Automatic Mesh 


You can configure RSVP to establish point-to-point label-switched paths (LSPs) automatically for any new 
PE router added to a full mesh of LSPs. To enable this feature, you must configure the rsvp-te statement 
on all of the PE routers in the full mesh. 


NOTE: You cannot configure RSVP automatic mesh in conjunction with CCC. CCC cannot use 
the dynamically generated LSPs. 


To configure RSVP automatic mesh, include the rsvp-te statement: 


rsvp-te { 
destination-networks network-prefix; 
label-switched-path-template (Multicast) { 
default-template; 
template-name; 


} 


You can configure these statements at the following hierarchy levels: 


e [edit routing-options dynamic-tunnels tunnel-name] 


e [edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name] 
You must also configure the following statements to enable RSVP automatic mesh: 


e destination-networks—Specify the IP version 4 (IPv4) prefix range for the destination network. Dynamic 
tunnels within the specified IPv4 prefix range can be initiated. 


e label-switched-path-template (Multicast)—You can configure either the default template explicitly using 
the default-template option, or you can configure an LSP template of your own using the template-name 
option. The LSP template acts as a model configuration for the dynamically generated LSPs. 
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Configuring Timers for RSVP Refresh Messages 


RSVP uses two related timing parameters: 


e refresh-time—The refresh time controls the interval between the generation of successive refresh 
messages. The default value for the refresh time is 45 seconds. This number is derived from the 
refresh-time statement’s default value of 30, multiplied by a fixed value of 1.5. This computation differs 
from RFC 2205, which states that the refresh time should be multiplied by a random value in the range 
from 0.5 through 1.5. 


Refresh messages include path and Resv messages. Refresh messages are sent periodically so that 
reservation states in neighboring nodes do not time out. Each path and Resv message carries the refresh 
timer value, and the receiving node extracts this value from the messages. 


e keep-multiplier—The keep multiplier is a small, locally configured integer from 1 through 255. The default 
value is 3. It indicates the number of messages that can be lost before a particular state is declared stale 
and must be deleted. The keep multiplier directly affects the lifetime of an RSVP state. 


To determine the lifetime of a reservation state, use the following formula: 





lifetime = (keep-multiplier + 0.5) x (1.5 x refresh-time) 


In the worst case, (keep-multiplier - 1) successive refresh messages must be lost before a reservation state 
is deleted. 


We do not recommend configuring a short RSVP hello timer. If quick discovery of a failed neighbor is 
needed, configure short IGP (OSPF or IS-IS) hello timers. 


By default, the refresh timer value is 30 seconds. To modify this value, include the refresh-time statement: 


refresh-time seconds; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 


The default value of the keep multiplier is 3. To modify this value, include the keep-multiplier statement: 


keep-multiplier number; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 
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Preempting RSVP Sessions 


Whenever bandwidth is insufficient to handle all RSVP sessions, you can control the preemption of RSVP 
sessions. By default, an RSVP session is preempted only by a new higher-priority session. 


To always preempt a session when the bandwidth is insufficient, include the preemption statement with 
the aggressive option: 


preemption aggressive; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 
To disable RSVP session preemption, include the preemption statement with the disabled option: 
preemption disabled; 


To return to the default (that is, preempt a session only for a new higher-priority session), include the 
preemption statement with the normal option: 


preemption normal; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 


Configuring MTU Signaling in RSVP 


IN THIS SECTION 


@ Enabling MTU Signaling in RSVP | 810 
@ Enabling Packet Fragmentation | 810 


To configure maximum transmission unit (MTU) signaling in RSVP, you need to configure MPLS to allow 
IP packets to be fragmented before they are encapsulated in MPLS. You also need to configure MTU 


810 


signaling in RSVP. For troubleshooting purposes, you can configure MTU signaling alone without enabling 
packet fragmentation. 


To configure MTU signaling in RSVP, include the path-mtu statement: 


path-mtu { 
allow-fragmentation; 
rsvp { 
mtu-signaling; 


You can include this statement at the following hierarchy levels: 

e [edit protocols mpls] 

e [edit logical-systems logical-system-name protocols mpls] 

The following sections describe how to enable packet fragmentation and MTU signaling in RSVP: 


Enabling MTU Signaling in RSVP 
To enable MTU signaling in RSVP, include the rsvp mtu-signaling statement: 


rsvp mtu-signaling; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls path-mtu] 


e [edit logical-systems logical-system-name protocols mpls path-mtu] 


Once you have committed the configuration, changes in the MTU signaling behavior for RSVP take effect 
the next time the path is refreshed. 


You can configure the mtu-signaling statement by itself at the [edit protocols mpls path-mtu rsvp] hierarchy 
level. This can be useful for troubleshooting. If you configure just the mtu-signaling statement, you can 
use the show rsvp session detail command to determine what the smallest MTU is on an LSP. The show 
rsvp session detail command displays the MTU value received and sent in the Adspec object. 


Enabling Packet Fragmentation 


To allow IP packets to be fragmented before they are encapsulated in MPLS, include the 
allow-fragmentation statement: 


allow-fragmentation; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls path-mtu] 


e [edit logical-systems logical-system-name protocols mpls path-mtu] 


NOTE: Do not configure the allow-fragmentation statement alone. Always configure it in 
conjunction with the mtu-signaling statement. 


Configuring Ultimate-Hop Popping for LSPs 


By default, RSVP-signaled LSPs use penultimate-hop popping (PHP). Figure 43 on page 560 illustrates a 
penultimate-hop popping LSP between Router PE1 and Router PE2. Router CE1 forwards a packet to its 
next hop (Router PE1), which is also the LSP ingress. Router PE1 pushes label 1 on the packet and forwards 
the labeled packet to Router P1. Router P1 completes the standard MPLS label swapping operation, 
swapping label 1 for label 2, and forwards the packet to Router P2. Since Router P2 is the penultimate-hop 
router for the LSP to Router PE2, it first pops the label and then forwards the packet to Router PE2. When 
Router PE2 receives it, the packet can have a service label, an explicit-null label, or just be a plain IP or 
VPLS packet. Router PE2 forwards the unlabeled packet to Router CE2. 


Figure 60: Penultimate-Hop Popping for an LSP 


[IP] IP mh 


i _@ 6 4 6 @ 


You can also configure ultimate-hop popping (UHP) (as shown in Figure 44 on page 561) for RSVP-signaled 
LSPs. Some network applications can require that packets arrive at the egress router (Router PE2) with a 
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non-null outer label. For an ultimate- hop popping LSP, the penultimate router (Router P2 in 

Figure 44 on page 561) performs the standard MPLS label swapping operation (in this example, label 2 for 
label 3 ) before forwarding the packet to egress Router PE2. Router PE2 pops the outer label and performs 
a second lookup of the packet address to determine the end destination. It then forwards the packet to 
the appropriate destination (either Router CE2 or Router CE4). 


811 


812 


Figure 61: Ultimate-Hop Popping for an LSP 
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The following network applications require that you configure UHP LSPs: 


e MPLS-TP for performance monitoring and in-band OAM 
e Edge protection virtual circuits 


The following features do not support the UHP behavior: 


e LDP-signaled LSPs 

e Static LSPs 

e Point-to-multipoint LSPs 
e CCC 


e traceroute command 


For more information about UHP behavior, see Internet draft 
draft-ietf-mpls-rsvp-te-no-php-oob-mapping-01.txt, Non PHP behavior and Out-of-Band Mapping for RSVP-TE 
LSPs. 


For point-to-point RSVP-signaled LSPs, UHP behavior is signaled from the LSP ingress. Based on the 
ingress router configuration, RSVP can signal the UHP LSP with the non-PHP flag set. RSVP PATH messages 
carry the two flags in the LSP-ATTRIBUTES object. When the egress router receives the PATH message, 
it assigns a non-null label to the LSP. RSVP also creates and installs two routes in the mpls.O routing table. 
S refers to the S bit of the MPLS label, which indicates whether or not the bottom of the label stack has 
been reached. 


e Route S=O—Indicates that there are more labels in the stack. The next hop for this route points to the 
mpls.O routing table, triggering a chained MPLS label lookup to discover the remaining MPLS labels in 
the stack. 


e Route S=1—Indicates that there are no more labels. The next hop points to the inet.O routing table if 
the platform supports chained and multi-family lookup. Alternatively, the label route can point to a VT 
interface to initiate IP forwarding. 


If you enable UHP LSPs, MPLS applications such as Layer 3 VPNs, VPLS, Layer 2 VPNs, and Layer 2 circuits 
can use the UHP LSPs. The following explains how UHP LSPs affect the different types of MPLS applications: 


e Layer 2 VPNs and Layer 2 circuits—A packet arrives at the PE router (egress of the UHP LSP) with two 
labels. The outer label (S=O) is the UHP label, and the inner label (S=1) is the VC label. A lookup based 
on the transport label results in a table handle for the mpls.O routing table. There is an additional route 
in the mpls.O routing table corresponding to the inner label. A lookup based on the inner label results in 
the CE router next hop. 


e Layer 3 VPN—A packet arrives at the PE router (egress of the UHP LSP) with two labels. The outer label 
(S=0) is the UHP label, and the inner label is the VPN label (S=1). A lookup based on the transport label 
results in the table handle for the mpls.O routing table. There are two cases in this scenario. By default, 
Layer 3 VPNs advertise the per-next hop label. A lookup based on the inner label results in the next hop 
toward the CE router. However, if you have configured the vrf-table-label statement for the Layer 3 
VPN routing instance, the inner LSI label points to the VRF routing table. An IP lookup is also completed 
for the VRF routing table. 


NOTE: UHP for Layer 3 VPNs configured with the vrf-table-label statement is supported on 
MX Series 5G Universal Routing Platforms only. 


VPLS—A packet arrives at the PE router (egress of the UHP LSP) with two labels. The outer label is the 
transport label (S=O) and the inner label is the VPLS label (S=1). A lookup based on the transport label 
results in the table handle for the mpls.O routing table. A lookup based on the inner label in mpls.O routing 


table results in the LSI tunnel interface of the VPLS routing instance if tunnel-services is not configured 
(or a VT interface not available). MX 3D Series routers support chained lookup and multi-family lookup. 


NOTE: UHP for VPLS configured with the no-tunnel-service statement is supported on MX 
3D Series routers only. 


IPv4 over MPLS—A packet arrives at the PE router (egress of the UHP LSP) with one label (S=1). A lookup 
based on this label returns a VT tunnel interface. Another IP lookup is completed on the VT interface 


to determine where to forward the packet. If the routing platform supports multi-family and chained 
lookups (for example, MX 3D routers and PTX Series Packet Transport Routers), lookup based on label 
route (S=1) points to the inet.O routing table. 


IPv6 over MPLS—For IPvé6 tunneling over MPLS, PE routers advertise IPv6é routes to each other with a 


label value of 2. This is the explicit null label for IPv6. As a result, the forwarding next hops for IPvé 
routes that are learned from remote PE routers normally push two labels. The inner label is 2 (it could 
be different if the advertising PE router is from another vendor), and the router label is the LSP label. 
Packets arrive at the PE router (egress of the UHP LSP) with two labels. The outer label is the transport 
label (S=O), and the inner label is the IPv6 explicit-null label (label 2). Lookup based on the inner label in 
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the mpls.O routing table redirects back to the mpls.O routing table. On MX 3D Series routers, the inner 
label (label 2) is stripped off and an IPv6 lookup is done using the inet6.0 routing table. 


e Enabling both PHP and UHP LSPs—You can configure both PHP and UHP LSPs over the same network 
paths. You can separate PHP and UHP traffic by selecting forwarding LSP next hops using a regular 
expression with the install-nexthop statement. You can also separate traffic by simply naming the LSPs 
appropriately. 


The following statements enable ultimate-hop popping for an LSP. You can enable this feature on a specific 
LSP or for all of the ingress LSPs configured on the router. Configure these statements on the router at 
the LSP ingress. 


1. To enable ultimate-hop popping, include the ultimate-hop-popping statement: 


ultimate-hop-popping; 


Include this statement at the [edit protocols mpls label-switched-path label-switched-path-name] 
hierarchy level to enable ultimate-hop popping on a specific LSP. Include this statement at the [edit 
protocols mpls] hierarchy level to enable ultimate-hop popping on all of the ingress LSPs configured 
on the router. You can also configure the ultimate-hop-popping statement under the equivalent [edit 
logical-routers] hierarchy levels. 


NOTE: When you enable ultimate-hop popping, RSVP attempts to resignal existing LSPs as 
ultimate-hop popping LSPs in a make-before-break fashion. If an egress router does not 
support ultimate-hop popping, the existing LSP is torn down (RSVP sends a PathTear message 
along an LSP’s path, removing the path state and dependent reservation state and releasing 
the associated networking resources). 


If you disable ultimate-hop popping, RSVP resignals existing LSPs as penultimate-hop popping 
LSPs in a make-before-break fashion. 


2. If you want to enable both ultimate-hop-popping and chained next hops on MX 3D Series routers only, 
you also need to configure the enhanced-ip option for the network-services statement: 


network-services enhanced-ip; 


You configure this statement at the [edit chassis] hierarchy level. Once you have configured the 
network-services statement, you need to reboot the router to enable UHP behavior. 
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Configuring RSVP to Pop the Label on the Ultimate-Hop Router 


You can control the label value advertised on the egress router of an LSP. The default advertised label is 
label 3 (Implicit Null label). If label 3 is advertised, the penultimate-hop router removes the label and sends 
the packet to the egress router. When ultimate-hop popping is enabled, label O (IP version 4 [IPv4] Explicit 
Null label) is advertised. Ultimate-hop popping ensures that any packets traversing an MPLS network 
include a label. 


NOTE: Juniper Networks routers queue packets based on the incoming label. Routers from 
other vendors might queue packets differently. Keep this in mind when working with networks 
containing routers from multiple vendors. 


To configure ultimate-hop popping for RSVP, include the explicit-null statement: 


explicit-null; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


Enabling Ultimate-Hop Popping on Point-to-Multipoint LSPs 


By default, for both point-to-point and point-to-multipoint LSPs, penultimate-hop popping is used for 
MPLS traffic. MPLS labels are removed from packets on the router just before the egress router of the 
LSP. The plain IP packets are then forwarded to the egress router. For ultimate-hop popping, the egress 
router is responsible for both removing the MPLS label and processing the plain IP packet. 


It can be beneficial to enable ultimate-hop popping on point-to-multipoint LSPs, particularly when transit 
traffic is traversing the same egress device. If you enable ultimate-hop popping, a single copy of traffic 
can be sent over the incoming link, saving significant bandwidth. By default, ultimate-hop popping is 
disabled. 


You enable ultimate-hop popping for point-to-multipoint LSPs by configuring the tunnel-services statement. 
When you enable ultimate-hop popping, the Junos OS selects one of the available virtual loopback tunnel 
(VT) interfaces to loop back the packets to the PFE for IP forwarding. By default, the VT interface selection 
process is performed automatically. Bandwidth admission control is used to limit the number of LSPs that 
can be used on one VT interface. Once all the bandwidth is consumed on one interface, the Junos OS 
selects another VT interface with sufficient bandwidth for admission control. 
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If an LSP requires more bandwidth than is available from any of the VT interfaces, ultimate-hop popping 
cannot be enabled and penultimate-hop popping is enabled instead. 


For ultimate-hop popping on point-to-multipoint LSPs to function properly, the egress router must have 
a PIC that provides tunnel services, such as the tunnel services PIC or the adaptive services PIC. Tunnel 
services are needed for popping the final MPLS label and for returning packets for IP address lookups. 


You can explicitly configure which VT interfaces handle the RSVP traffic by including the devices option 
for the tunnel-services statement. The devices option allows you to specify which VT interfaces are to be 
used by RSVP. If you do not configure this option, all of the VT interfaces available to the router can be 
used. 


To enable ultimate-hop popping for the egress point-to-multipoint LSPs on a router, configure the 
tunnel-services statement: 


tunnel-services { 
devices device-names; 


You can configure this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 


To enable ultimate-hop popping for egress point-to-multipoint LSPs, you must also configure the interface 
statement with the all option: 


interface all; 


You must configure this statement at the [edit protocols rsvp] hierarchy level. 


Tracing RSVP Protocol Traffic 


To trace RSVP protocol traffic, include the traceoptions statement: 


traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag <flag-modifier> <disable>; 


You can include this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 
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You can specify the following RSVP-specific flags in the RSVP traceoptions statement: 


Use the file statement to specify the name of the file that receives the output of the tracing operation. All 
files are placed in the directory /var/log. We recommend that you place RSVP tracing output in the file 
rsvp-log. 


e all—All tracing operations. 


error—All detected error conditions 


event—RSVP-related events (helps to trace events related to RSVP graceful restart) 


e Imp—RSVP-Link Management Protocol (LMP) interactions 
packets—All RSVP packets 


path—All path messages 


pathtear—PathTear messages 


e resv—Resv messages 


resvtear—ResvTear messages 
e route—Routing information 


e state—Session state transitions, including when RSVP-signaled LSPs come up and go down. 


NOTE: Use the all trace flag and the detail flag modifier with caution because these might cause 
the CPU to become very busy. 


To view the log file generated when you enable RSVP traceoptions, issue the show log file-name command, 
where file-name is the file you specified using the traceoptions statement. 


For general information about tracing and global tracing options, see the Junos OS Routing Protocols Library. 


Examples: Tracing RSVP Protocol Traffic 
Trace RSVP path messages in detail: 


[edit] 
protocols { 
rsvp { 
traceoptions { 
file rsvp size 10m files 5; 
flag path; 


Trace all RSVP messages: 


[edit] 
protocols { 
rsvp { 
traceoptions { 
file rsvp size 10m files 5; 
flag packets; 


Trace all RSVP error conditions: 


[edit] 
protocols { 
rsvp { 
traceoptions { 
file rsvp size 10m files 5; 
flag error; 


} 


Trace RSVP state transitions: 


[edit] 
protocols { 
rsvp { 
traceoptions { 
file rsvp-data; 


flag state; 
} 


RSVP Log File Output 


The following is sample output generated by issuing the show log file-name command on a router on which 
RSVP traceoptions have been enabled with the state flag configured. The RSVP-signaled LSP E-D is shown 
being torn down on Mar 11 14:04:36.707092. On Mar 11 14:05:30.101492, it is shown coming back up. 
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user@host> show log rsvp-data 





aie ii ISobeeSi tracaoms Wrecime to YW /waie/log/m/eswo-cata” sitarced 

aie iil ISebeeSil 2364s weyjoairleainge ioe we wil we-l/2/0, 69206016 

ar 11 13:58:51.286718 RSVP add interface vt—-1/2/0.69206016, ifindex 101, ifaddr 
(null), family 1, is_appl_vt 0, already known 

ave Wi USeSe Sil. 2NOGIs INS recie Wie 1/2 /O.CO20G01S Wallin — siselewirq/ 2/0, C2060 





Up 

ar 11 13:58:51.286978 RSVP add interface vt—-1/2/0.69206016, ifindex 101, ifaddr 
(null), family 3, is_appl_vt 0, already known 

aie ii IssSesSi  2879o2 inswe ack aimeerirace Irol/2/0.2, aitaimeles 11s, aitaclele (amlil) , 
family 2, is_appl_vt 0, already known 

gue Lil 13s Sse bil ASSso29) iIRxSWwe -clel sumcemicaee Ine—il/2/0.2, asciincle< ils, slieaickele i10),.0.0.2, 
family 1, is_appl_vt 0, already known 


ar 11 13:58:;511.288996 RSVP add interface 1t-1/2/0.17, ifindex 114, iffaddr (null), 


aie iil is eSiesi 2859s SWE cls dimcsicraes Ike-1/2/O oi), aitiumelese Wil4), aitecleke (immlil) , 


family 2, is_appl_vt 0, already known 

















family 3, is_appl_vt 0, already known 
ave lil Iss SeieSil Beas inswae ache! aimeGietecs Weol/2/O., 17, aitainees il“! satevelehe 
10.0.0.17, family 1, is_appl_vt 0, already known 
am ill LSaSeie5l. 290049 iInSwe weer le-1/2/0,17 waailaiak _ _iaoclglte-1/2/0.17 wi 
aig iil ISseS9905 042034 ins men Infos EWiOSSS—S10 0,0. 18 om ainieeirace Ie—/2/0. 17 
cO© 10.0,0.18 awoicl 0.0.0.0 
ar 11 14:04:36.707092 LSP "E-D" is Down (Reason: Reservation state deleted) 
Sessiomg 192.163 .,0.4 (oome/cuiineil WD WOs2i ise—mp) 192. 168.0.'5)) Picoice 0) 
Sender See SeO on qo@rste/ also) ela) 
ar 11 14:04:36.707661 RSVP delete resv state, session 192.168.0.4(port/tunnel ID 
L032) Ext=t0 1427 15e.0.5)) Peete. 0 
ar 11 14:04:36.781185 RSVP delete path state, session 192.168.0.4(port/tunnel ID 
PO32) Bx -iD Toy bee.) Proto 0 
ar 11 14:04:36.781440 RSVP delete session 192.168.0.4(port/tunnel ID 10321 Ext-ID 
192 .168.0.5) Pecco O 
ar 11 14:05:30.101492 RSVP new Session 192.168.0.4(port/tunnel ID 10321 Ext-ID 
192, 1o83 0.5) wicore 0, SESSaCin ID) 3 
ar 11 14:05:30.101722 RSVP new path state, session 192.168.0.4(port/tunnel ID 
1321 wee—I0D 192 .168.0.5) Peoco O 
ar 11 14:05:30.179124 RSVP new resv state, session 192.168.0.4(port/tunnel ID 
IO3Z1 wxse—10D) 192 .168.0.5) Pecco 0 
ar 11 14:05:30.179395 RSVP PSB E-D, allocating psb resources for label 4294967295 
gue iil I4sOSs SO. 1s0s53 mse TED" ss Ue 
SecistonmlOZhos On Al(Dersta/;eunnc aD a WO S)Zaluerisce— lle GSi Om >) me Eao rom) 
Senders eo eemG SO ron (oorstey Hlsome Dey) 
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RSVP Graceful Restart 


RSVP graceful restart allows a router undergoing a restart to inform its adjacent neighbors of its condition. 
The restarting router requests a grace period from the neighbor or peer, which can then cooperate with 
the restarting router. The restarting router can still forward MPLS traffic during the restart period; 
convergence in the network is not disrupted. The restart is not visible to the rest of the network, and the 
restarting router is not removed from the network topology. RSVP graceful restart can be enabled on both 
transit routers and ingress routers. It is available for both point-to-point LSPs and point-to-multipoint LSPs. 


RSVP graceful restart is described in the following sections: 


RSVP Graceful Restart Standard 


e RSVP Graceful Restart Terminology on page 820 
e RSVP Graceful Restart Operation on page 821 


Processing the Restart Cap Object on page 822 


RSVP Graceful Restart Terminology 


Recovery time Applies only when the control channel is up (the hello exchange is complete) before the restart time. 


(in milliseconds) Applies only to nodal faults. 


When a graceful restart is in progress, the time left to complete a recovery is advertised. At other times, 


this value is zero. The maximum advertised recovery time is 2 minutes (120,000 milliseconds). 


During the recovery time, a restarting node attempts to recover its lost states with assistance from its 
neighbors. The neighbor of the restarting node must send the path messages with the recovery labels 
to the restarting node within a period of one-half the recovery time. The restarting node considers its 


graceful restart complete after its advertised recovery time. 


Restart time The default value is 60,000 milliseconds (1 minute). The restart time is advertised in the hello message. 
(in milliseconds) The time indicates how long a neighbor should wait to receive a hello message from a restarting router 


before declaring that router dead and purging states. 


The Junos OS can override a neighbor’s advertised restart time if the time is greater than one-third the 
local restart time. For example, given the default restart time of 60 seconds, a router would wait 20 seconds 
or less to receive a hello message from a restarting neighbor. If the restart time is zero, the restarting 


neighbor can immediately be declared dead. 
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RSVP Graceful Restart Operation 


For RSVP graceful restart to function, the feature must be enabled on the global routing instance. RSVP 
graceful restart can be disabled at the protocol level (for RSVP alone) or at the global level for all protocols. 


RSVP graceful restart requires the following of a restarting router and the router's neighbors: 


e For the restarting router, RSVP graceful restart attempts to maintain the routes installed by RSVP and 
the allocated labels, so that traffic continues to be forwarded without disruption. RSVP graceful restart 
is done quickly enough to reduce or eliminate the impact on neighboring nodes. 


e The neighboring routers must have RSVP graceful restart helper mode enabled, thus allowing them to 
assist a router attempting to restart RSVP. 


An object called Restart Cap that is sent in RSVP hello messages advertises a node’s restart capability. The 
neighboring node sends a Recover Label object to the restarting node to recover its forwarding state. This 
object is essentially the old label that the restarting node advertised before the node went down. 


The following lists the RSVP graceful restart behaviors, which vary depending on the configuration and 
on which features are enabled: 


If you disable helper mode, the Junos OS does not attempt to help a neighbor restart RSVP. Any 


information that arrives with a Restart Cap object from a neighbor is ignored. 


When you enable graceful restart under the routing instance configuration, the router can restart 
gracefully with the help of its neighbors. RSVP advertises a Restart Cap object (RSVP RESTART) in hello 
messages in which restart and recovery times are specified (neither value is 0). 


If you explicitly disable RSVP graceful restart under the [protocols rsvp] hierarchy level, the Restart Cap 
object is advertised with restart and recovery times specified as 0. The restart of neighboring routers is 
supported (unless helper mode is disabled), but the router itself does not preserve the RSVP forwarding 
state and cannot recover its control state. 


If after a restart RSVP realizes that no forwarding state has been preserved, the Restart Cap object is 
advertised with restart and recovery times specified as O. 


If graceful restart and helper mode are disabled, RSVP graceful restart is completely disabled. The router 
neither recognizes nor advertises the RSVP graceful restart objects. 


You cannot explicitly configure values for the restart and recovery times. 


Unlike other protocols, there is no way for RSVP to determine that it has completed a restart procedure, 
other than a fixed timeout. All RSVP graceful restart procedures are timer-based. A show rsvp version 
command might indicate that the restart is still in progress even if all RSVP sessions are back up and the 
routes are restored. 


Processing the Restart Cap Object 


The following assumptions are made about a neighbor based on the Restart Cap object (assuming that a 


control channel failure can be distinguished unambiguously from a node restart): 


A neighbor that does not advertise the Restart Cap object in its hello messages cannot assist a router 
with state or label recovery, nor can it perform an RSVP graceful restart. 


After a restart, a neighbor advertising a Restart Cap object with a restart time equal to any value and a 
recovery time equal to O has not preserved its forwarding state. When a recovery time equals O, the 
neighbor is considered dead and any states related to this neighbor are purged, regardless of the value 
of the restart time. 


After a restart, a neighbor advertising its recovery time with a value other than O can keep or has kept 
the forwarding state. If the local router is helping its neighbor with restart or recovery procedures, it 
sends a Recover Label object to this neighbor. 


Configuring RSVP Graceful Restart 


IN THIS SECTION 


Enabling Graceful Restart for All Routing Protocols | 823 
Disabling Graceful Restart for RSVP | 823 
Disabling RSVP Helper Mode | 823 


Configuring the Maximum Helper Recovery Time | 824 


Configuring the Maximum Helper Restart Time | 824 


The following RSVP graceful restart configurations are possible: 


Graceful restart and helper mode are both enabled (the default). 


Graceful restart is enabled but helper mode is disabled. A router configured in this way can restart 
gracefully, but cannot help a neighbor with its restart and recovery procedures. 


Graceful restart is disabled but helper mode is enabled. A router configured in this way cannot restart 
gracefully, but can help a restarting neighbor. 


Graceful restart and helper mode both are disabled. This configuration completely disables RSVP graceful 
restart (including restart and recovery procedures and helper mode). The router behaves like a router 
that does not support RSVP graceful restart. 
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NOTE: In order to turn on RSVP graceful restart, you must set the global graceful restart timer 
to at least 180 seconds. 


The following sections describe how to configure RSVP graceful restart: 


Enabling Graceful Restart for All Routing Protocols 


To enable graceful restart for RSVP, you need to enable graceful restart for all the protocols that support 
graceful restart on the router. For more information about graceful restart, see the Junos OS Routing 
Protocols Library. 


To enable graceful restart on the router, include the graceful-restart statement: 


graceful-restart; 


You can include this statement at the following hierarchy levels: 
e [edit routing-options] 
e [edit logical-systems logical-system-name routing-options] 


Disabling Graceful Restart for RSVP 


By default, RSVP graceful restart and RSVP helper mode are enabled when you enable graceful restart. 
However, you can disable one or both of these capabilities. 


To disable RSVP graceful restart and recovery, include the disable statement at the [edit protocols rsvp 
graceful-restart] hierarchy level: 


disable; 


Disabling RSVP Helper Mode 


To disable RSVP helper mode, include the helper-disable statement at the [edit protocols rsvp 
graceful-restart] hierarchy level: 


helper-disable; 


Configuring the Maximum Helper Recovery Time 


To configure the amount of time the router retains the state of its RSVP neighbors while they undergo a 
graceful restart, include the maximum-helper-recovery-time statement at the [edit protocols rsvp 
graceful-restart] hierarchy level. This value is applied to all neighboring routers, so it should be based on 
the time required by the slowest RSVP neighbor to recover. 


maximum-helper-recovery-time seconds; 


Configuring the Maximum Helper Restart Time 


To configure the delay between when the router discovers that a neighboring router has gone down and 
when it declares the neighbor down, include the maximum-helper-restart-time statement at the [edit 
protocols rsvp graceful-restart] hierarchy level. This value is applied to all neighboring routers, so it should 
be based on the time required by the slowest RSVP neighbor to restart. 


maximum-helper-restart-time seconds; 


RSVP LSP Tunnels Overview 


A Resource Reservation Protocol (RSVP) label-switched path (LSP) tunnel enables you to send RSVP LSPs 
inside other RSVP LSPs. This enables a network administrator to provide traffic engineering from one end 
of the network to the other. A useful application for this feature is to connect customer edge (CE) routers 
with provider edge (PE) routers by using an RSVP LSP, and then tunnel this edge LSP inside a second RSVP 
LSP traveling across the network core. 


You should have a general understanding of MPLS and label switching concepts. For more information 
about MPLS, see the Junos MPLS Applications Configuration Guide. 


An RSVP LSP tunnel adds the concept of a forwarding adjacency, similar to the one used for generalized 
Multiprotocol Label Switching (GMPLS). (For more information about GMPLS, see Junos GMPLS User Guide. 


The forwarding adjacency creates a tunneled path for sending data between peer devices in an RSVP LSP 
network. Once a forwarding adjacency LSP (FA-LSP) has been established, other LSPs can be sent over 
the FA-LSP by using Constrained Shortest Path First (CSPF), Link Management Protocol (LMP), Open 
Shortest Path First (OSPF), and RSVP. 


To enable an RSVP LSP tunnel, the Junos OS uses the following mechanisms: 


e LMP—Originally designed for GMPLS, LMP establishes forwarding adjacencies between RSVP LSP tunnel 
peers, and maintains and allocates resources for traffic engineering links. 


e OSPF extensions—OSPF was designed to route packets to physical and logical interfaces related to a 
Physical Interface Card (PIC). This protocol has been extended to route packets to virtual peer interfaces 
defined in an LMP configuration. 
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e RSVP-TE extensions—RSVP-TE was designed to signal the setup of packet LSPs to physical interfaces. 


The protocol has been extended to request path setup for packet LSPs traveling to virtual peer interfaces 


defined in an LMP configuration. 


NOTE: Beginning with Junos OS Release 15.1, multi-instance support is extended to MPLS 
RSVP-TE. This support is available only for virtual router instance type. A router can create 
and participate in multiple independent TE topology partitions, which allows each partitioned 
TE domain to scale independently. Multi-instance RSVP-TE provides the flexibility to hand 
pick the control-plane entities that need to be instance-aware, for example, a router can 
participate in multiple TE instances while still running a single BGP instance. 


The Junos OS implementation of MPLS RSVP-TE is scaled to enhance the usability, visibility, configuration, 
and troubleshooting of LSPs in Junos OS Release 16.1. 


These enhancements make the RSVP-TE configuration easier at scale by: 


Ensuring the LSP data-plane readiness during LSP resignaling before traffic traverses the LSP with the 
RSVP-TE LSP self-ping mechanism. 


An LSP should not start to carry traffic unless it is known to have been programmed in the data plane. 
Data exchange in the LSP data plane, such as LSP ping requests, happens at the ingress router before 
switching traffic to an LSP, or to its MBB instance. In large networks, this traffic can overwhelm an 
LSP egress router, as the egress LSP needs to respond to the LSP ping requests. The LSP self-ping 
mechanism enables the ingress LER to create LSP ping response messages and send them over the 
LSP data plane. On receiving these messages, the egress LER forwards them to the ingress, indicating 
the liveliness of the LSP data plane. This ensures that the LSP does not start to carry traffic before the 
data plane has been programmed. 


Removing the current hard limit of 64K LSPs on an ingress router and scaling the total number of LSPs 
with RSVP-TE signaled LSPs. There can be up to 64K LSPs configured on a per-egress basis. Earlier, 
this limit was the aggregate number of LSPs that could be configured on the ingress LER. 


Preventing abrupt tearing down of LSPs by the ingress router because of delay in signaling the LSP at 
the transit routers. 


Enabling a flexible view of LSP data-sets to facilitate LSP characteristic data visualization. 


NOTE: Starting with Junos OS Release 17.4, a default timer of 1800 seconds for self-ping is 
introduced. 
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The following limitations exist for LSP hierarchies: 


e Circuit cross-connect (CCC)-based LSPs are not supported. 
e Graceful restart is not supported. 
e Link protection is not available for FA-LSPs or at the egress point of the forwarding adjacency. 


e Point-to-multipoint LSPs are not supported across FA-LSPs. 


Example: RSVP LSP Tunnel Configuration 


Figure 62: RSVP LSP Tunnel Topology Diagram 
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End-to-end LSPs: e2e_Isp_r0r5 and e2e_Isp_r5r0 


Figure 62 on page 826 shows an end-to-end RSVP LSP called e2e_Isp_rOr5 that originates on Router O and 
terminates on Router 5. In transit, this LSP traverses the FA-LSP fa_Isp_rir4. The return path is represented 
by the end-to-end RSVP LSP e2e_Isp_r5r0 that travels over the FA-LSP fa_Isp_r4r1. 


On Router 0, configure the end-to-end RSVP LSP that travels to Router 5. Use a strict path that traverses 
Router 1 and the LMP traffic engineering link traveling from Router 1 to Router 4. 


Router O 


[edit] 


interfaces { 
so-0/0/3 { 
unit O { 
family inet { 
address 10.1.2.1/30; 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 10.255.41.222/32; 
} 


family mpls; 


} 
routing-options { 
forwarding-table { 


export pplb; 


} 
protocols { 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 


} 
mpls { 
admin-groups { 
fa 1; 
backup 2; 
other 3; 
} 


label-switched-path e2e_Isp_rOr5 { # An end-to-end LSP traveling to Router 5. 


to 10.255.41.221; 
bandwidth 30k; 


primary path-fa; # Reference the requested path here. 


} 


path path-fa { # Configure the strict path here. 
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10.1.2.2 strict; 
172.16.30.2 strict; # This traverses the TE link heading to Router 4. 

} 

interface all; 

interface fxp0.0 { 
disable; 

} 

interface so-3/2/1.0 { 
admin-group other; 

} 

interface so-0/0/3.0 { 
admin-group other; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface fxp0.0 { 
disable; 
} 


interface all; 


} 
policy-options { 
policy-statement pplb { 
then { 
load-balance per-packet; 


On Router 1, configure an FA-LSP to reach Router 4. Establish an LMP traffic engineering link and LMP 
peer relationship with Router 4. Reference the FA-LSP in the traffic engineering link and add the peer 
interface into both OSPF and RSVP. 


When the return path end-to-end LSP arrives at Router 1, the routing platform performs a routing lookup 
and can forward traffic to Router 0. Make sure you configure OSPF correctly between Routers O and 1. 


Router 1 


[edit] 
interfaces { 


so-0/0/1 { 
unit O { 
family inet { 
address 10.2.3.1/30; 
} 


family mpls; 


} 
so-0/0/2 { 
unit O { 
family inet { 
address 10.2.4.1/30; 
} 


family mpls; 


} 
so-0/0/3 { 
unit O { 
family inet { 
address 10.1.2.2/30; 
} 


family mpls; 


} 
fe-0/1/2 { 
unit O { 
family inet { 
address 10.2.5.1/30; 
} 


family mpls; 


} 
at-1/0/0 { 
atm-options { 
vpi 1; 
} 
unit O { 
vci 1.100; 
family inet { 
address 10.2.3.5/30; 
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} 


family mpls; 


} 
routing-options { 
forwarding-table { 
export [ pplb choose_Isp ]; 


} 
protocols { 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 
} 
peer-interface r4; # Apply the LMP peer interface here. 
} 
mpls { 
admin-groups { 
fa 1; 
backup 2; 
other 3; 
} 


label-switched-path fa_Isp_rir4 { # Configure your FA-LSP to Router 4 here. 


to 10.255.41.217; 
bandwidth 400k; 
primary path_rir4; # Apply the FA-LSP path here. 
} 
path path_rir4 { # Configure the FA-LSP path here. 
10.2.4.2; 
10.4.5.2; 
10.3.5.1; 
} 
interface so-0/0/3.0 { 
admin-group other; 
} 
interface so-0/0/1.0 { 
admin-group fa; 
} 
interface at-1/0/0.0 { 
admin-group backup; 
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} 

interface fe-0/1/2.0 { 
admin-group backup; 

} 

interface so-0/0/2.0 { 
admin-group fa; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface fxp0.0 { 
disable; 
} 
interface all; 
peer-interface r4; # Apply the LMP peer interface here. 


} 
link-management { # Configure LMP statements here. 
te-link link_rir4 { # Assign a name to the TE link here. 
local-address 172.16.30.1; # Configure a local address for the TE link. 
remote-address 172.16.30.2; # Configure a remote address for the TE link. 
te-metric 1; # Manually set a metric here if you are not relying on CSPF. 
label-switched-path fa_Isp_rir4; # Reference the FA-LSP here. 
} 
peer r4 { # Configure LMP peers here. 


address 10.255.41.217; # Configure the loopback address of your peer here. 


te-link link_r1r4; # Apply the LMP TE link here. 


} 
policy-options { 
policy-statement choose_lsp { 
term A { 
from community choose_e2e_Isp; 
then { 


install-nexthop strict Isp e2e_Isp_r1r4; 
accept; 


} 
term B { 


from community choose_fa_lIsp; 
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then { 
install-nexthop strict Isp fa_Isp_r1r4; 
accept; 


} 
policy-statement pplb { 


then { 
load-balance per-packet; 


} 

community choose_e2e_lsp members 1000:1000; 
community choose_fa_Isp members 2000:2000; 
community set_e2e_lsp members 1000:1000; 
community set_fa_lsp members 2000:2000; 


On Router 2, configure OSPF, MPLS, and RSVP on all interfaces that transport the FA-LSPs across the 
core network. 


Router 2 


[edit] 
interfaces { 
so-0/0/0 { 
unit O { 
family inet { 
address 10.4.5.1/30; 
} 


family mpls; 


} 
so-0/0/1 { 
unit O { 
family inet { 
address 10.1.4.2/30; 
} 


family mpls; 


} 


so-0/0/2 { 
unit O { 
family inet { 
address 10.2.4.2/30; 
} 


family mpls; 


} 
fe-0/1/2 { 
unit O { 
family inet { 
address 10.3.4.2/30; 
} 


family mpls; 


routing-options { 


} 


protocols { # OSPF, MPLS, and RSVP form the core backbone for the FA-LSPs. 


forwarding-table { 
export pplb; 


rsvp { 
interface all; 
interface fxp0.0 { 
disable; 


} 
mopls { 
admin-groups { 
fa 1; 
backup 2; 
other 3; 
} 
path path_r1 { 
10.2.4.1; 
} 
path path_r3r4 { 
10.4.5.2; 
10.3.5.1; 
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interface all; 

interface fxp0.0 { 
disable; 

} 

interface so-0/0/1.0 { 
admin-group other; 

} 

interface fe-0/1/2.0 { 
admin-group backup; 

} 

interface so-0/0/2.0 { 
admin-group fa; 

} 

interface so-0/0/0.0 { 
admin-group fa; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface fxp0.0 { 
disable; 
} 


interface all; 


} 
policy-options { 
policy-statement pplb { 
then { 
load-balance per-packet; 


On Router 3, configure OSPF, MPLS, and RSVP on all interfaces that transport the FA-LSPs across the 
core network. 


Router 3 


[edit] 
interfaces { 
so-0/0/0 { 
unit O { 
family inet { 
address 10.4.5.2/30; 
} 


family mpls; 


} 
so-0/0/1 { 
unit O { 
family inet { 
address 10.5.6.1/30; 
} 


family mpls; 


} 
so-0/0/2 { 
unit O { 
family inet { 
address 10.3.5.2/30; 
} 


family mpls; 


} 
fe-0/1/2 { 
unit O { 
family inet { 
address 10.2.5.2/30; 
} 


family mpls; 


} 
routing-options { 
forwarding-table { 
export pplb; 


} 


protocols { # OSPF, MPLS, and RSVP form the core backbone for the FA-LSPs. 


rsvp { 
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interface all; 
interface fxpO0.0 { 
disable; 


} 
mopls { 

admin-groups { 
fa 1; 
backup 2; 
other 3; 

} 

path path_r4 { 
10.3.5.1; 

} 

path path_r2r1 { 
10.4.5.1; 
10.2.4.1; 

} 

interface all; 

interface fxp0.0 { 
disable; 

} 

interface so-0/0/2.0 { 
admin-group fa; 

} 

interface fe-0/1/2.0 { 
admin-group backup; 

} 

interface so-0/0/1.0 { 
admin-group other; 

} 

interface so-0/0/0.0 { 
admin-group fa; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface fxp0.0 { 
disable; 
} 


interface all; 


836 


} 
policy-options { 
policy-statement pplb { 
then { 


load-balance per-packet; 


On Router 4, configure a return path FA-LSP to reach Router 1. Establish an LMP traffic engineering link 
and LMP peer relationship with Router 1. Reference the FA-LSP in the traffic engineering link and add the 
peer interface into both OSPF and RSVP. 


When the initial end-to-end LSP arrives at Router 4, the routing platform performs a routing lookup and 
can forward traffic to Router 5. Make sure you configure OSPF correctly between Router 4 and Router 5. 


Router 4 


[edit] 
interfaces { 
so-0/0/0 { 
unit O { 
family inet { 
address 10.3.6.1/30; 
} 
family mpls; 
} 
} 
so-0/0/1 { 
unit O { 
family inet { 
address 10.2.3.2/30; 
} 
family mpls; 
} 
} 
so-0/0/2 { 
unit O { 
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family inet { 
address 10.3.5.1/30; 
} 


family mpls; 


} 
fe-0/1/2 { 
unit O { 
family inet { 
address 10.3.4.1/30; 
} 


family mpls; 


} 
at-1/0/0 { 
atm-options { 
vpi 1; 
} 
unit O { 
vci 1.100; 
family inet { 
address 10.2.3.6/30; 
} 


family mpls; 


} 
routing-options { 
forwarding-table { 


export [ pplb choose_Isp ]; 


} 
protocols { 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 
} 
peer-interface r1; # Apply the LMP peer interface here. 
} 
mpls { 
admin-groups { 
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fa 1; 
backup 2; 
other 3; 

} 

label-switched-path fa_Isp_r4r1 { # Configure your FA-LSP here. 
to 10.255.41.216; 
bandwidth 400k; 
primary path_r4r1; # Apply the FA-LSP path here. 

} 

path path_r4r1 { # Configure the FA-LSP path here. 
10.3.5.2; 
10.4.5.1; 
10.2.4.1; 

} 

interface all; 

interface fxp0.0 { 
disable; 

} 

interface at-1/0/0.0 { 
admin-group backup; 

} 

interface so-0/0/2.0 { 
admin-group fa; 

} 

interface fe-0/1/2.0 { 
admin-group backup; 

} 

interface so-0/0/0.0 { 
admin-group other; 

} 

interface so-0/0/1.0 { 
admin-group fa; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface fxp0.0 { 
disable; 
} 
interface all; 
peer-interface r1; # Apply the LMP peer interface here. 
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} 
link-management { # Configure LMP statements here. 
te-link link_r4r1 { # Assign a name to the TE link here. 
local-address 172.16.30.2; # Configure a local address for the TE link. 
remote-address 172.16.30.1; # Configure a remote address for the TE link. 
te-metric 1; # Manually set a metric here if you are not relying on CSPF. 
label-switched-path fa_Isp_r4r1; # Reference the FA-LSP here. 
} 
peer r1 { # Configure LMP peers here. 
address 10.255.41.216; # Configure the loopback address of your peer here. 
te-link link_r4r1; # Apply the LMP TE link here. 


} 
policy-options { 
policy-statement choose_lsp { 
termA { 
from community choose_e2e_Isp; 
then { 
install-nexthop strict Isp e2e_Isp_r4r1; 
accept; 


} 
term B { 
from community choose_fa_Isp; 
then { 
install-nexthop strict Isp fa_Isp_r4r1; 
accept; 


} 
policy-statement pplb { 
then { 
load-balance per-packet; 


} 

community choose_e2e_lsp members 1000:1000; 
community choose_fa_Isp members 2000:2000; 
community set_e2e_lsp members 1000:1000; 
community set_fa_lsp members 2000:2000; 
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On Router 5, configure the return path end-to-end RSVP LSP that travels to Router O. Use a strict path 
that traverses Router 4 and the LMP traffic engineering link traveling from Router 4 to Router 1. 


Router 5 


[edit] 
interfaces { 
so-0/0/2 { 
unit O { 
family inet { 
address 10.3.6.2/30; 
} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 10.255.41.221/32; 


} 
routing-options { 
forwarding-table { 


export pplb; 


} 
protocols { 
rsvp { 
interface all; 
interface fxpO0.0 { 
disable; 


} 
mpls { 
admin-groups { 
fa 1; 
backup 2; 
other 3; 
} 
label-switched-path e2e_Isp_r5r0 { # An end-to-end LSP returning to Router O. 
to 10.255.41.222; 


bandwidth 30k; 

primary path-fa; # Reference the requested path here. 
} 
path path-fa { # Configure the strict path here. 

10.3.6.1 strict; 


172.16.30.1 strict; # This traverses the TE link heading to Router 1. 


} 

interface all; 

interface fxp0.0 { 
disable; 

} 

interface so-0/0/2.0 { 
admin-group other; 

} 

interface so-0/0/1.0 { 
admin-group other; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface fxp0.0 { 
disable; 
} 


interface all; 


} 
policy-options { 
policy-statement pplb { 
then { 
load-balance per-packet; 
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Verifying Your Work 


IN THIS SECTION 


@ = Router O | 843 
@ Router 1 | 849 
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To verify that your RSVP LSP tunnel is working correctly, issue the following commands: 


show ted database (extensive) 


show link-management 


show rsvp session name (extensive) 


show link-management te-link name (detail) 


To see these commands used with the configuration example, see the following sections: 


Router 0 


On Router O, you can verify that the FA-LSPs appear as valid paths in the traffic engineering database. In 
this case, look for the paths from Router 1 (10.255.41.216) and Router 4 (10.255.41.217) that reference 
the LMP traffic engineering link addresses of 172.16.30.1 and 172.16.30.2. You can also issue the show 
rsvp session extensive command to look for the path of the end-to-end LSP as it travels to Router 5 over 


the FA-LSP. 


user@router0> show ted database 


TED database: 0 ISIS nodes 8 INET nodes 
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Reservable BW: 


155.52Mbps 


Available BW [priority] bps: 


[0] 155.52Mbps [i] LSS. S4Moas [2 ]) 155. SziMilsyoys 
[4] 155.52Mbps [5] 155, 52Mso8 [6] 155. 52iMoos 


Interface Switching Capability Descriptor(1): 


ise 


Switching type: 

Encoding type: 

aximum LSP BW 
[0] 155.52Mbp 
[4] 155.52Mbp 





Packet 

Packet 

[qonslonsikieya loos 

s [1] ISS.S2Mgos [2] 155. 52iMojos 
s [5] 155. 52Migos [6] 155. 52iMicjos 


10.255.41.217, Local: 172.16.30.1, Remote: 172.16.30.2 
Maeeieses iL 
Static BW: 400kbps 


Reservable BW: 


400kbps 


Available BW [priority] bps: 
[0] 370kbps [1] 370kbps [2] 370kbps 
[4] 370kbps [5] 370kbps [6] 370kbps 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 


aoe 


[0] 370kbps a sHOkias [2] S70lsos 
[4] 370kbps iles70 kbs [6] 370kbps 
AO eS, Locals 1023.5, hemotes 1.3.5 
Color: 0x4 backup 
Metric: 1 


Stacie Bye 155,52 
Reservable BW: 15 


Mbps 
5.52Mbps 


LSS) 6 LZMloyoys) 
1355 . LZMloyays) 


L355 5 ILZMloyays! 
LSS » ILZMloyoys) 


SS o2Miops 
1355 5 SAMOS 


155 . S2Miloyos) 
155.52Mbps 


370kbps 
370kbps 


370kbps 
370kbps 


845 
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Available BW [priority] bps: 
ROPES Seo 2Mipos RES Sro2 Mops eas Zee Sion oe Mbps marl Sonos Mops) 
[4] 155.52Mbps [5S] 15s. S52uijxs [6] IS5.SaMig0s [7] 155, S2Auigyss 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 
OTS Seo Mbps [i] 155. 52Mie9s [2] 155.5aMo08 [3] 155. 52Mijos 
[4] 155.52Mbps [5] 155.52Mie9s [6] 1Sss.52Ma08 [7] 155. 52Misjos 
ice 10.7, 0.1-1, Locals 10.2.5. 1, Remotes 0.0.0.0 
Color: 0x4 backup 
Metric: 1 
Static BW: 100Mbps 
Reservable BW: 100Mbps 
Available BW [priority] bps: 
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps 
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] 100Mbps [1] 100Mbps [2] 100Mbps [3] 100Mbps 
[4] 100Mbps [5] 100Mbps [6] 100Mbps [7] 100Mbps 


user@router0> show ted database 10.255.41.217 extensive 
TED database: 0 ISIS nodes 8 INET nodes 
NecleinDs 10 .255—.4il, 217) 
Type: Rtr, Age: 473 secs, LinkIn: 6, LinkOut: 6 
Prococoly OsSrr (020,020) 
To: 10.255..41.216, Bocals 10.2.3.2, Remotes: 1022.3.1 
Colloie: Wxe2) ie 








Metric: 1 

Siscia hem Spm oomoe Maps 

Reservable BW: 155.52Mbps 

Available BW [priority] bps: 
(ORD SSA Mines fi] 185. 52iMijos [2] 155.5295 [3] 155. S52uiyos 
[4] 155.52Mbps [5] 155. 52uicjos [6] 155.5255 [7] 155. 52Mijos 

Interface Switching Capability Descriptor(1): 

Switching type: Packet 

Encoding type: Packet 





aximum LSP BW [priority] bps: 
ROPES Sea Mises [1 155.52Milsos 12] IS5.52Moos [3] 155.526 
[4] 155.52Mbps [S]| 155. 52Misos [6] LS5.52iMoos [7] L155. 52mg 
To: 10.255.41.216, Local: 172.16.30.2, Remote: 172.16.30.1 
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Mieieiealies AL 

Static BW: 400kbps 

Reservable BW: 400kbps 

Available BW [priority] bps: 
[0] 370kbps [1] 370kbps [2] 370kbps [3] 370kbps 
[4] 370kbps [5] 370kbps [6] 370kbps [7] 370kbps 

Interface Switching Capability Descriptor(1): 

Switching type: Packet 

Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] 370kbps [1] 370kbps [2] S7OMssios [3] S7OMssos 
[4] 370kbps [Si S7OKsies [6] 370kbps [7] 370kbps 
Zo: 10.255.41.216, Local? 10.2.3.6, Remotes: 10.2.3.5 
Color: 0x4 backup 
Metric: 1 
Siscdia hem Belo omen Maps 
Reservable BW: 155.52Mbps 
Available BW [priority] bps: 
[Ol] 15S 5 s2Mioyss [i] LSS. S2mMisos [2] LS5.52aMeos [3]) 155. 52Moyos 
[4] 155.52Mbps [5] 153. 52mlyos [6] 1s5.5aMo0s [7] 155. 52Mijos 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] 155.52Mbps [1] ISs.S2mMisos [2] 155 .52Meyos [3] 155. a2Moos 
[4] 155.52Mbps [5] 155.52Mieos [6] 1Sss.52Ma08 [7] 155. 52Mijos 
toe 20,255.41 .715>, hocel? 10,3 5.8, Remote: 10.3 75.2 
GOlloies WSe2 ie 
Metric: 1 
Static BW: 155.52Mbps 
Reservable BW: 155.52Mbps 
Available BW [priority] bps: 
OES See Minas [i] 1Ss davis [2] Iss. 1aminos [3] 155. 12uioyos 
[4] 155.12Mbps [5] 15S. avis [5] ISS 1aMigns [7] 155, d2uiyos 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] 155.12Mbps [i] 155 12Mieos [2] less .iaMogns [3] 155. 12Miojos 
[A] 155 5 L2ZMioyos [5] 155.12Mieos [6] les.1avigos [7] 155. 12Mijos 
for 10. 255.41 ,221, hocals 10,526.1, Remove: 10.5.6.2 
Color: 0x8 other 
Mieieiesleg il 


Siac ie 155, 52Nisas 


Reservable BW: 155.52Mbps 
Available BW [priority] bps: 
[0] 155.52Mbps [i] 155. 52auiyos [2] 155, 52ulyss) 
[4] 155.52Mbps Poi SSr 52 Mbps 6 leisono2 Mops 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] 155.52Mbps ERS S52 Mop seal peisionoe Mops) 
[4] 155.52Mbps [5] 15s .52Mijos [6] 155. 52iMicjos 
To? 10.3.4 51-1, Local: 10.3.4 .41, Remores 020.020 
Color: 0x4 backup 
Metric: 
Static BW: 100Mbps 
Reservable BW: 100Mbps 
Available BW [priority] bps: 
[0] 100Mbps [1] 100Mbps [2] 100Mbps 
[4] 100Mbps [5] 100Mbps [6] 100Mbps 
Interface Switching Capability Descriptor(1): 





Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] 100Mbps [1] 100Mbps [2] 100Mbps 
[4] 100Mbps [5] 100Mbps [6] 100Mbps 


user@router0> show rsvp session name e2e_Isp_rOr5 extensive 
Ingress RSVP: 1 sessions 
10.255 41,2211 
From: 10.255.41.222, LSPstate: Up, ActiveRoute: 2 
LSPname: e2e_lsp_r0Or5, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 101584 
Resv style: 1 FF, Label in: -, Label out: 101584 
Time left: , Since: Wed Sep 7 19:02:56 2005 
[spec: rate 30kbps size 30kbps peak Infbps m 20 M 1500 














Port number: sender 2 receiver 29458 protocol 0 

PATH rcevfrom: localclient 

Adspec: sent MTU 1500 

Path MTU: received 1500 

SMe Serco: LOW 2.2 (so-0/0/3.0) 15 okies 

RiGw mowsrcoms IO, 2.2 (Sso-0/0/S.0) 16 jakies 
Explct route: 10.1.2.2 172.16.30.2 10.3.6.2 
Record route: <self> 10.1.2.2 172.16.30.2 10.3.6.2 

Total 1 displayed, Up 1, Down 0 





1359 5 SAMOS 
155.52Mbps 


155.52Mbps 
155.52Mbps 


100Mbps 
100Mbps 


100Mbps 
100Mbps 


848 


849 





Egress RSVP: 1 sessions 


Total 0 displayed, Up 0, Down 0 


Transit RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Router 1 


On Router 1, verify that your LMP traffic engineering link configuration is working and that the end-to-end 
LSP is traversing the traffic engineering link by issuing the show link-management set of commands. You 
can also issue the show rsvp session extensive command to confirm that the FA-LSP is operational. 


user@routerl1> show link-management 


Peername:r4 , System identifier: 10758 
StarermUp ae Oniuroadcisesis el Om Z old lee cilay 
TE links: 


link_rir4 


TE link name: link_rir4, State: Up 





Local identifier: 16299, Remote identifier: 0, Localaddress: 172.16.30.1, Remote address: 
172.16.30.2, 


Encoding: Packet, Switching: Packet, Minimum bandwidth: Obps, Maximum bandwidth: 
400kbps, 


Total bandwidth: 400kbps, Available bandwidth: 370kbps 
Name State Local ID Remote ID Bandwidth Used LSP-name 
fa_Isp_rir4 Up 22642 (0) 400kbps Yes e2e _Isp_rOr5 


user@routerl> show link-management te-link name link_rir4 detail 





TE link name: link_rir4, State: Up 


Local identifier: 16299, Remote identifier: 0, Localaddress: 172.16.30.1, Remote address: 
172.16.30.2, 








Encoding: Packet, Switching: Packet, Minimum bandwidth: Obps, Maximum bandwidth: 
400kbps, 


Total bandwidth: 400kbps, Available bandwidth: 370kbps 


Resource: fa_lsp_rlr4, Type: LSP, System identifier: 2147483683, State: Up, 
local identifier; 22642, 


Remote identifier: 0 





Total bandwidth: 400kbps, Unallocated bandwidth: 370kbps 











Traffic parameters: Encoding: Packet, Switching: Packet, Granularity: Unknown 


Number of allocations: 1, In use: Yes 
LSP name: e2e_Isp_rOr5, Allocated bandwidth: 30kbps 


user@routerl> showrsvp session name fa_Isp_rir4 extensive 
Ingress RSVP: 1 sessions 
10.255 41,207 
From: 10.255.41.216, LSPstate: Up, ActiveRoute: 0 
LSPname: fa_lsp_rir4, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 100816 
Resv style: 1 FF, Label in: -, Label out: 100816 
Time left: , Since: Wed Sep 7 19:02:33 2005 
Tspec: rate 400kbps size 400kbps peak Infbps m 20 M 1500 











Port number: sender 2 receiver 5933 protocol 0 





PATH rcevfrom: localclient 

Adspec: sent MTU 1500 

Path MTU: received 1500 

PATH sentto: 10.2.4.2 (so-0/0/2.0) 28 pkts 
RES Vee ei isOMell OMe cs O— 0110.20) mee omokats 
Explct route: 10.2.4.2 10.4.5.2 10.3.5.1 


Record route: <self> 10.2.4.2 10.4.5.2 10.3.5.1 
Total 1 displayed, Up 1, Down 0 











Egress RSVP: 1 sessions 


Total 0 displayed, Up 0, Down 0 


Transit RSVP: 2 sessions 





Total 0 displayed, Up 0, Down 0 


Configuring Link Management Protocol Peers 


After you set up traffic engineering links, configure LMP network peers with the peer peer-name statement 
at the [edit protocols link-management] hierarchy level. A peer is the network device with which your 
routing platform communicates and establishes an FA-LSP. Designate a peer name, configure the peer 
router ID as the address (often a loopback address), and apply the traffic engineering link to be associated 
with this peer. Remember to configure both sides of a peering relationship to enable bidirectional 
communication. 


Unlike GMPLS, you must not configure a control channel for a peer. If you include a control channel, the 
commit operation fails. 
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[edit] 
protocols { 
link-management { 
peer peer-name { # Configure the name of your network peer. 
address ip-address; # Include the router ID of the peer. 
te-link te-link-name; # Assign a TE link to this peer. 


Configuring Link Management Protocol Traffic Engineering Links 


To begin your RSVP LSP tunnel configuration, configure LMP traffic engineering links on both the ingress 
and egress routing platforms. Because traffic engineering links define a unidirectional connection between 
peer devices, you must configure traffic engineering links in both directions between peers to enable the 
bidirectional transport of packets. 


To configure traffic engineering links in LMP, include the te-link te-link-name statement at the [edit 
protocols link-management] hierarchy level. Define the traffic engineering link options shown below, 
especially the label-switched path to be used as the FA-LSP to reach the peer. Optionally, you can specify 
the traffic engineering metric for the traffic engineering link (TE link). By default, the traffic engineering 
metric is derived from the CSPF computation. 


[edit] 
protocols { 
link-management { 
te-link te-link-name { # Name of the TE link. 

label-switched-path Isp-name; # LSP used for the forwarding adjacency. 
local-address ip-address; # Local IP address associated with the TE link. 
remote-address ip-address; # Remote IP address mapped to the TE link. 
te-metric value; # Traffic engineering metric used for the TE link. 


Configuring Peer Interfaces in OSPF and RSVP 


After you establish LMP peers, you must add peer interfaces to OSPF and RSVP. A peer interface is a 
virtual interface used to support the control adjacency between two peers. 


The peer interface name must match the peer peer-name statement configured in LMP at the [edit protocols 
link- management] hierarchy level. Because actual protocol packets are sent and received by peer interfaces, 
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the peer interfaces can be signaled and advertised to peers like any other physical interface configured 

for OSPF and RSVP. To configure OSPF routing for LMP peers, include the peer-interface statement at 
the [edit protocols ospf area area-number] hierarchy level. To configure RSVP signaling for LMP peers, 

include the peer-interface statement at the [edit protocols rsvp] hierarchy level. 


[edit] 
protocols { 
rsvp { 
peer-interface peer-name { # Configure the name of your LMP peer. 
} 
ospf { 
area area-number { 


peer-interface peer-name { # Configure the name of your LMP peer. 


Defining Label-Switched Paths for the FA-LSP 


Next, define your FA-LSP by including the label-switched-path statement at the [edit protocols mpls] 
hierarchy level. Include the router ID of the peer in the to statement at the [edit protocols mpls 
label-switched-path] hierarchy level. Because packet LSPs are unidirectional, you must create one FA-LSP 
to reach the peer and a second FA-LSP to return from the peer. 


[edit] 
protocols { 
mpls { 
label-switched-path Isp-name { 
from ip-address; 
to ip-address; 
primary path-name; 
secondary path-name; 
no-cspf; # This statement to disable CSPF is optional. 
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Establishing FA-LSP Path Information 


When you configure explicit LSP paths for an FA-LSP, you must use the traffic engineering link remote 
address as your next-hop address. When CSPF is supported, you can use any path option you wish. 
However, when CSPF is disabled with the no-cspf statement at the [edit protocols mpls label-switched-path 
Isp-name] hierarchy level, you must use strict paths. 


[edit] 
protocols { 
mpls { 
path path-name { 
next-hop-address (strict | loose); 


NOTE: If the end-to-end LSP originates on the same routing platform as the FA-LSP, you must 
disable CSPF and use strict paths. 


Option: Tearing Down RSVP LSPs Gracefully 


You can tear down an RSVP LSP in a two-step process that gracefully withdraws the RSVP session used 
by the LSP. For all neighbors that support graceful teardown, a request for the teardown is sent by the 
routing platform to the destination endpoint for the LSP and all RSVP neighbors in the path. The request 
is included within the ADMIN_STATUS field of the RSVP packet. When neighbors receive the request, 
they prepare for the RSVP session to be withdrawn. A second message is sent by the routing platform to 
complete the teardown of the RSVP session. If aneighbor does not support graceful teardown, the request 
is handled as a standard session teardown rather than a graceful one. 


To perform a graceful teardown of an RSVP session, issue the clear rsvp session gracefully command. 
Optionally, you can specify the source and destination address of the RSVP session, the LSP identifier of 
the RSVP sender, and the tunnel identifier of the RSVP session. To use these qualifiers, include the 
connection-source, connection-destination, Isp-id, and tunnel-id options when you issue the clear rsvp 
session gracefully command. 


You can also configure the amount of time that the routing platform waits for neighbors to receive the 
graceful teardown request before initiating the actual teardown by including the graceful-deletion-timeout 
statement at the [edit protocols rsvp] hierarchy level. The default graceful deletion timeout value is 

30 seconds, with a minimum value of 1 second and a maximum value of 300 seconds. To view the current 
value configured for graceful deletion timeout, issue the show rsvp version operational mode command. 
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Release History Table 


Release Description 
19.4R1 
164 However, starting from Junos OS Release 16.1, when RSVP hello messages time-out, 


the RSVP sessions are brought down. 
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LDP Introduction 


The Label Distribution Protocol (LDP) is a protocol for distributing labels in non-traffic-engineered 
applications. LDP allows routers to establish label-switched paths (LSPs) through a network by mapping 
network-layer routing information directly to data link layer-switched paths. 
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These LSPs might have an endpoint at a directly attached neighbor (comparable to IP hop-by-hop 
forwarding), or at a network egress node, enabling switching through all intermediary nodes. LSPs established 
by LDP can also traverse traffic-engineered LSPs created by RSVP. 


LDP associates a forwarding equivalence class (FEC) with each LSP it creates. The FEC associated with an 
LSP specifies which packets are mapped to that LSP. LSPs are extended through a network as each router 
chooses the label advertised by the next hop for the FEC and splices it to the label it advertises to all other 
routers. This process forms a tree of LSPs that converge on the egress router. 


Understanding the LDP Signaling Protocol 


LDP is a signaling protocol that runs on a device configured for MPLS support. The successful configuration 
of both MPLS and LDP initiates the exchange of TCP packets across the LDP interfaces. The packets 
establish TCP-based LDP sessions for the exchange of MPLS information within the network. Enabling 
both MPLS and LDP on the appropriate interfaces is sufficient to establish LSPs. 


LDP is a simple, fast-acting signaling protocol that automatically establishes LSP adjacencies within an 
MPLS network. Routers then share LSP updates such as hello packets and LSP advertisements across the 
adjacencies. Because LDP runs on top of an IGP such as IS-IS or OSPF, you must configure LDP and the 
IGP on the same set of interfaces. After both are configured, LDP begins transmitting and receiving LDP 
messages through all LDP-enabled interfaces. Because of LDP's simplicity, it cannot perform the true traffic 
engineering which RSVP can perform. LDP does not support bandwidth reservation or traffic constraints. 


When you configure LDP on a label-switching router (LSR), the router begins sending LDP discovery 
messages out all LDP-enabled interfaces. When an adjacent LSR receives LDP discovery messages, it 
establishes an underlying TCP session. An LDP session is then created on top of the TCP session. The TCP 
three-way handshake ensures that the LDP session has bidirectional connectivity. After they establish the 
LDP session, the LDP neighbors maintain, and terminate, the session by exchanging messages. LDP 
advertisement messages allow LSRs to exchange label information to determine the next hops within a 
particular LSP. Any topology changes, such as a router failure, generate LDP notifications that can terminate 
the LDP session or generate additional LDP advertisements to propagate an LSP change. 


Example: Configuring LDP-Signaled LSPs 


IN THIS SECTION 


@ = Requirements | 857 
@ Overview | 857 
@ Configuration | 857 
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This example shows how to create and configure LDP instances within an MPLS network. 


Requirements 


Before you begin: 


e Configure network interfaces. See Interfaces User Guide for Security Devices. 


e Configure an IGP across your network. (The LDP configuration is added to the existing IGP configuration 
and included in the MPLS configuration.) 


e Configure a network to use LDP for LSP establishment by enabling MPLS on all transit interfaces in the 
MPLS network. 


af 
y | 


~ NOTE: Because LDP runs on top of an IGP such as IS-IS or OSPF, you must configure LDP 
and the IGP on the same set of interfaces. 


Overview 


To configure LDP-signaled LSPs, you must enable the MPLS family on all transit interfaces in the MPLS 
network and include all the transit interfaces under the [protocols mpls] and [protocols Idp] hierarchy 
levels. 


In this example, you enable the MPLS family and create an LDP instance on all the transit interfaces. 
Additionally, you enable the MPLS process on all the transit interfaces in the MPLS network. In this example, 
you configure a sample network as shown in Figure 63 on page 857. 


Figure 63: Typical LDP-Signaled LSP 


Loopback address Loopback address Loopback address 
200.0.0.1 200.0.0.2 200.0.0.3 


ge-0/0/0 ge-0/0/0 
100.10.10.1/30 100.10.20.2/30 


ge-0/0/0 ge-0/0/1 
100.10.10.2/30 100.10.20.1/30 





: LDP signaled LSP between R1 and R2_ —_ LDP signaled LSP between R2 and R3 : 


LDP signaled LSP between R1 and R3 


041388 


Configuration 


CLI Quick Configuration 


858 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level and then enter commit from configuration mode. 


For Router R1, perform the following: 
set interfaces ge-0/0/0 unit 0 family mpls 


set protocols mpls ge-0/0/0 unit 0 
set protocols ldp interface ge-0/0/0.0 unit O 


For Router R2, perform the following: 


set interfaces ge-0/0/0 unit O family mpls 
set protocols mpls ge-0/0/0 unit 0 

set protocols ldp interface ge-0/0/0.0 unit O 
set interfaces ge-0/0/1 unit 0 family mpls 
set protocols mpls ge-0/0/1 unit 0 

set protocols Idp interface ge-0/0/0.1 unit O 


For Router R3, perform the following: 


set interfaces ge-0/0/0 unit O family mpls 
set protocols mpls ge-0/0/0 unit 0 
set protocols Idp interface ge-0/0/0.0 unit O 


Step-by-Step Procedure 


To enable LDP instances within an MPLS network: 


1. Enable the MPLS family on the transit interface on Router R1. 


[edit] 
user@R1# set interfaces ge-0/0/0 unit O family mpls 


2. Enable the MPLS process on the transit interface. 


[edit] 
user@R1# set protocols mpls interface ge-0/0/0 unit O 


3. Create the LDP instance on the transit interface. 


[edit] 


user@R1# set protocols Idp interface ge-0/0/0 unit 0 


Results 


Confirm your configuration by entering the show command from configuration mode. If the output does 
not display the intended configuration, repeat the configuration instructions in this example to correct it. 


For brevity, this show output includes only the configuration that is relevant to this example. Any other 
configuration on the system has been replaced with ellipses (...). 


user@R1# show 


interfaces { 
ge-0/0/0 { 
unit O { 
family inet { 
address 10.100.37.20/24, 
} 


family mpls; 


protocols { 
mpls { 
interface all; 
} 
Idp { 
interface ge-0/0/0.0; 


If you are done configuring the device, enter the commit command from the configuration mode to activate 
the configuration. 


Junos OS LDP Protocol Implementation 


The Junos OS implementation of LDP supports LDP version 1. The Junos OS supports a simple mechanism 
for tunneling between routers in an interior gateway protocol (IGP), to eliminate the required distribution 
of external routes within the core. The Junos OS allows an MPLS tunnel next hop to all egress routers in 
the network, with only an IGP running in the core to distribute routes to egress routers. Edge routers run 
BGP but do not distribute external routes to the core. Instead, the recursive route lookup at the edge 
resolves to an LSP switched to the egress router. No external routes are necessary on the transit LDP 
routers. 
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LDP Operation 


You must configure LDP for each interface on which you want LDP to run. LDP creates LSP trees rooted 
at each egress router for the router ID address that is the subsequent BGP next hop. The ingress point is 
at every router running LDP. This process provides an inet.3 route to every egress router. If BGP is running, 
it will attempt to resolve next hops by using the inet.3 table first, which binds most, if not all, of the BGP 
routes to MPLS tunnel next hops. 


Two adjacent routers running LDP become neighbors. If the two routers are connected by more than one 
interface, they become neighbors on each interface. When LDP routers become neighbors, they establish 
an LDP session to exchange label information. If per-router labels are in use on both routers, only one LDP 
session is established between them, even if they are neighbors on multiple interfaces. For this reason, an 
LDP session is not related to a particular interface. 


LDP operates in conjunction with a unicast routing protocol. LDP installs LSPs only when both LDP and 
the routing protocol are enabled. For this reason, you must enable both LDP and the routing protocol on 
the same set of interfaces. If this is not done, LSPs might not be established between each egress router 
and all ingress routers, which might result in loss of BGP-routed traffic. 


You can apply policy filters to labels received from and distributed to other routers through LDP. Policy 
filters provide you with a mechanism to control the establishment of LSPs. 


For LDP to run on an interface, MPLS must be enabled on a logical interface on that interface. For more 


information, see the Logical Interfaces. 


LDP Message Types 


IN THIS SECTION 


Discovery Messages | 861 
Session Messages | 861 


Advertisement Messages | 861 


Notification Messages | 861 
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LDP uses the message types described in the following sections to establish and remove mappings and to 
report errors. All LDP messages have a common structure that uses a type, length, and value (TLV) encoding 
scheme. 

Discovery Messages 


Discovery messages announce and maintain the presence of a router in a network. Routers indicate their 
presence in a network by sending hello messages periodically. Hello messages are transmitted as UDP 
packets to the LDP port at the group multicast address for all routers on the subnet. 


LDP uses the following discovery procedures: 


Basic discovery—A router periodically sends LDP link hello messages through an interface. LDP link hello 


messages are sent as UDP packets addressed to the LDP discovery port. Receipt of an LDP link hello 
message on an interface identifies an adjacency with the LDP peer router. 


Extended discovery—LDP sessions between routers not directly connected are supported by LDP 


extended discovery. A router periodically sends LDP targeted hello messages to a specific address. 
Targeted hello messages are sent as UDP packets addressed to the LDP discovery port at the specific 
address. The targeted router decides whether to respond to or ignore the targeted hello message. A 
targeted router that chooses to respond does so by periodically sending targeted hello messages to the 
initiating router. 


Session Messages 


Session messages establish, maintain, and terminate sessions between LDP peers. When a router establishes 
a session with another router learned through the hello message, it uses the LDP initialization procedure 
over TCP transport. When the initialization procedure is completed successfully, the two routers are LDP 
peers and can exchange advertisement messages. 


Advertisement Messages 


Advertisement messages create, change, and delete label mappings for forwarding equivalence classes 
(FECs). Requesting a label or advertising a label mapping to a peer is a decision made by the local router. 
In general, the router requests a label mapping from a neighboring router when it needs one and advertises 
a label mapping to a neighboring router when it wants the neighbor to use a label. 


Notification Messages 


Notification messages provide advisory information and signal error information. LDP sends notification 
messages to report errors and other events of interest. There are two kinds of LDP notification messages: 


e Error notifications, which signal fatal errors. If a router receives an error notification from a peer for an 
LDP session, it terminates the LDP session by closing the TCP transport connection for the session and 
discarding all label mappings learned through the session. 


e Advisory notifications, which pass information to a router about the LDP session or the status of some 
previous message received from the peer. 
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Tunneling LDP LSPs in RSVP LSPs 


You can tunnel LDP LSPs over RSVP LSPs. The following sections describe how tunneling of LDP LSPs in 
RSVP LSPs works: 


e Tunneling LDP LSPs in RSVP LSPs Overview on page 862 


e Label Operations on page 863 


Tunneling LDP LSPs in RSVP LSPs Overview 


If you are using RSVP for traffic engineering, you can run LDP simultaneously to eliminate the distribution 
of external routes in the core. The LSPs established by LDP are tunneled through the LSPs established by 
RSVP. LDP effectively treats the traffic-engineered LSPs as single hops. 


When you configure the router to run LDP across RSVP-established LSPs, LDP automatically establishes 
sessions with the router at the other end of the LSP. LDP control packets are routed hop-by-hop, rather 
than carried through the LSP. This routing allows you to use simplex (one-way) traffic-engineered LSPs. 
Traffic in the opposite direction flows through LDP-established LSPs that follow unicast routing rather 
than through traffic-engineered tunnels. 


If you configure LDP over RSVP LSPs, you can still configure multiple OSPF areas and IS-IS levels in the 
traffic engineered core and in the surrounding LDP cloud. 


Beginning with Junos OS Release 15.1, multi-instance support is extended to LDP over RSVP tunneling 
for a virtual router routing instance. This allows splitting of a single routing and MPLS domain into multiple 
domains so that each domain can be scaled independently. BGP labeled unicast can be used to stitch these 
domains for service forwarding equivalence classes (FECs). Each domain uses intra-domain LDP-over-RSVP 
LSP for MPLS forwarding. 


NOTE: With the introduction of the multi-instance support for LDP-over-RSVP LSPs, you cannot 
enable MPLS on an interface that is already assigned to another routing instance. Adding an 
interface that is part of another routing instance at the [edit protocols mpls] hierarchy level, 
throws a configuration error at the time of commit. 


Benefits of Tunneling LDP LSPs in RSVP LSPs 
Tunneling LDP LSPs in RSVP LSPs provides the following benefits: 
e Provides convergence of different traffic types such as IPv4, IPvé6, unicast, and multicast across Layer 


2 and Layer 3 VPNs. 


e Enables flexible access connectivity options that can accommodate multiple topologies, different protocols, 
and multiple administrative boundaries. 


e Enables secure interworking among multiple providers. 


Enables provision of differentiated services on a per customer basis because RSVP-TE supports traffic 


engineering, bandwidth guarantees, and link and node redundancy capabilities. 


Reduces the number of LSPs required in the core, which reduces the resource requirements of the 


protocols and routers as well as reducing convergence time. 


Provides cost-efficient rollouts with minimal network disruption because the LSPs are built using 


point-to-point TE tunnels to directly attached neighbors. These TE tunnels only go to the next hop, not 
end to end. Then when LDP is run over those tunnels, the sessions are built to the directly connected 
neighbor. When there is a change in the network, such as adding a new node, the directly connected 
neighbors of the new node have RSVP and LDP sessions. Thus, the RSVP LSPs are only to the next hop, 
and LDP takes care of advertising labels for the new addresses. 


Label Operations 


Figure 64 on page 864 depicts an LDP LSP being tunneled through an RSVP LSP. (For definitions of label 
operations, see “MPLS Label Overview” on page 422.) The shaded inner oval represents the RSVP domain, 
whereas the outer oval depicts the LDP domain. RSVP establishes an LSP through routers B, C, D, and E, 
with the sequence of labels L3, L4. LDP establishes an LSP through Routers A, B, E, F, and G, with the 
sequence of labels L1, L2, L5. LDP views the RSVP LSP between Routers B and E as a single hop. 


When the packet arrives at Router A, it enters the LSP established by LDP, and a label (L1) is pushed onto 
the packet. When the packet arrives at Router B, the label (L1) is swapped with another label (L2). Because 
the packet is entering the traffic-engineered LSP established by RSVP, a second label (L3) is pushed onto 
the packet. 


This outer label (L3) is swapped with a new label (L4) at the intermediate router (C) within the RSVP LSP 
tunnel, and when the penultimate router (D) is reached, the top label is popped. Router E swaps the label 
(L2) with a new label (L5), and the penultimate router for the LDP-established LSP (F) pops the last label. 
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Figure 64: Swap and Push When LDP LSPs Are Tunneled Through RSVP LSPs 
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Figure 65 on page 864 depicts a double push label operation (L1L2). A double push label operation is used 
when the ingress router (A) for both the LDP LSP and the RSVP LSP tunneled through it is the same device. 
Note that Router D is the penultimate hop for the LDP-established LSP, so L2 is popped from the packet 
by Router D. 


Figure 65: Double Push When LDP LSPs Are Tunneled Through RSVP LSPs 
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LDP Session Protection 


LDP session protection is based on the LDP targeted hello functionality defined in RFC 5036, LDP 
Specification, and is supported by the Junos OS as well as the LDP implementations of most other vendors. 
It involves sending unicast User Datagram Protocol (UDP) hello packets to a remote neighbor address and 
receiving similar packets from the neighbor router. 
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If you configure LDP session protection on a router, the LDP sessions are maintained as follows: 


1. An LDP session is established between a router and a remote neighboring router. 


2. If all of the direct links between the routers go down, the LDP session remains up so long as there is 
IP connectivity between the routers based on another connection over the network. 


3. When the direct link between the routers is reestablished, the LDP session is not restarted. The routers 
simply exchange LDP hellos with each other over the direct link. They can then begin forwarding 
LDP-signaled MPLS packets using the original LDP session. 


By default, LDP targeted hellos are set to the remote neighbor so long as the LDP session is up, even if 
there are no more link neighbors to that router. You can also specify the duration you would like to maintain 
the remote neighbor connection in the absence of link neighbors. When the last link neighbor for a session 
goes down, the Junos OS starts an LDP session protection timer. If this timer expires before any of the 
link neighbors come back up, the remote neighbor connection is taken down and the LDP session is 
terminated. If you configure a different value for the timer while it is currently running, the Junos OS 
updates the timer to the specified value without disrupting the current state of the LDP session. 


LDP Native IPvé6 Support Overview 


IPv6 connectivity often relies on tunneling IPv6é over an IPv4 MPLS core with IPv4-signaled MPLS 
label-switched paths (LSPs). This requires the IPv4-signaled LSPs to be configured statically or established 
dynamically by IPvé provider edge routers. Because of the growing demand of IPvé6, it has become 
imperative to deploy an IPv6 MPLS core with an IPv6-signaled LSP to provide IPvé connectivity. In Junos 
OS, LDP is supported in an IPv6 network only, and in an IPv6/IPv4 dual-stack network as described in RFC 
7552. Apart from providing a single session for both IPv4 and IPv6é networks, Junos OS LDP supports 
separate IPv4 sessions for IPv4 only, and IPvé6 sessions for IPvé only. 


You can configure the address family as inet for IPv4 or inet6 for IPvé6, or both. If the family address is not 
configured, then the default address of family inet is enabled. When both IPv4 and IPvé6 are configured, 
you can use the transport-preference statement to configure the prefered transport to be either IPv4 or 
IPv6. Based on the preference, LDP attempts to establish a TCP connection using IPv4 or IPvé. By default, 
IPvé is selected. The dual-transport statement allows Junos OS LDP to establish the TCP connection over 
IPv4 with IPv4 neighbors, and over IPv6 with IPv6 neighbors as a single-stack LSR. The inet-Isr-id and 
inet6-Isr-id IDs are the two LSR IDs that have to be configured to establish an LDP session over IPv4 and 
IPv6é TCP transport. These two IDs should be non-zero and must be configured with different values. 
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Longest Match Support for LDP Overview 


LDP is often used to establish MPLS label-switched paths (LSPs) throughout a complete network domain 
using an IGP such as OSPF or IS-IS. In such a network, all links in the domain have IGP adjacencies as well 
as LDP adjacencies. LDP establishes the LSPs on the shortest path to a destination as determined by IGP. 
In Junos OS, the LDP implementation does an exact match lookup on the IP address of the forwarding 
equivalence class (FEC) in the routing information base (RIB) or IGP routes for label mapping. This exact 
mapping requires MPLS end-to-end LDP endpoint IP addresses to be configured in all the label edge 
routers (LERs). This defeats the purpose of IP hierarchical design or default routing in access devices. 
Configuring longest-match allows LDP to set up LSP based on the routes aggregated or summarized across 
OSPF areas or IS-IS levels in the inter-domain. 


Release History Table 


Release Description 


15.1 Beginning with Junos OS Release 15.1, multi-instance support is extended to LDP over 
RSVP tunneling for a virtual router routing instance. 
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Minimum LDP Configuration 


To enable LDP with minimal configuration: 
1. Enable all relevant interfaces under family MPLS. In the case of directed LDP, the loopback interface 
needs to be enabled with family MPLS. 


2. (Optional) Configure the relevant interfaces under the [edit protocol mpls] hierarchy level. 


3. Enable LDP ona single interface, include the Idp statement and specify the interface using the interface 
statement. 


This is the minimum LDP configuration. All other LDP configuration statements are optional. 


Idp { 
interface interface-name; 


To enable LDP on all interfaces, specify all for interface-name. 
For a list of hierarchy levels at which you can include these statements, see the statement summary 


sections. 


Enabling and Disabling LDP 


LDP is routing-instance-aware. To enable LDP on a specific interface, include the following statements: 


Idp { 
interface interface-name; 


For a list of hierarchy levels at which you can include these statements, see the statement summary 
sections. 


To enable LDP on all interfaces, specify all for interface-name. 
If you have configured interface properties on a group of interfaces and want to disable LDP on one of 


the interfaces, include the interface statement with the disable option: 


interface interface-name { 
disable; 
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For a list of hierarchy levels at which you can include this statement, see the statement summary section. 


Configuring the LDP Timer for Hello Messages 


LDP hello messages enable LDP nodes to discover one another and to detect the failure of a neighbor or 
the link to the neighbor. Hello messages are sent periodically on all interfaces where LDP is enabled. 


There are two types of LDP hello messages: 


e Link hello messages—Sent through the LDP interface as UDP packets addressed to the LDP discovery 
port. Receipt of an LDP link hello message on an interface identifies an adjacency with the LDP peer 
router. 


e Targeted hello messages—Sent as UDP packets addressed to the LDP discovery port at a specific address. 
Targeted hello messages are used to support LDP sessions between routers that are not directly 
connected. A targeted router determines whether to respond or ignore a targeted hello message. A 
targeted router that chooses to respond does so by periodically sending targeted hello messages back 
to the initiating router. 


By default, LDP sends hello messages every 5 seconds for link hello messages and every 15 seconds for 
targeted hello messages. You can configure the LDP timer to alter how often both types of hello messages 
are sent. However, you cannot configure a time for the LDP timer that is greater than the LDP hold time. 
For more information, see “Configuring the Delay Before LDP Neighbors Are Considered Down” on 
page 870. 


Configuring the LDP Timer for Link Hello Messages 


To modify how often LDP sends link hello messages, specify a new link hello message interval for the LDP 
timer using the hello-interval statement: 


hello-interval seconds; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 
Configuring the LDP Timer for Targeted Hello Messages 


To modify how often LDP sends targeted hello messages, specify a new targeted hello message interval 
for the LDP timer by configuring the hello-interval statement as an option for the targeted-hello statement: 


targeted-hello { 
hello-interval seconds; 


For alist of hierarchy levels at which you can include these statements, see the statement summary sections 
for these statements. 
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Configuring the Delay Before LDP Neighbors Are Considered Down 


The hold time determines how long an LDP node should wait for a hello message before declaring a 
neighbor to be down. This value is sent as part of a hello message so that each LDP node tells its neighbors 
how long to wait. The values sent by each neighbor do not have to match. 


The hold time should normally be at least three times the hello interval. The default is 15 seconds for link 
hello messages and 45 seconds for targeted hello messages. However, it is possible to configure an LDP 
hold time that is close to the value for the hello interval. 


NOTE: By configuring an LDP hold time close to the hello interval (less than three times the 
hello interval), LDP neighbor failures might be detected more quickly. However, this also increases 
the possibility that the router might declare an LDP neighbor down that is still functioning 
normally. For more information, see “Configuring the LDP Timer for Hello Messages” on page 869. 


The LDP hold time is also negotiated automatically between LDP peers. When two LDP peers advertise 
different LDP hold times to one another, the smaller value is used. If an LDP peer router advertises a 
shorter hold time than the value you have configured, the peer router's advertised hold time is used. This 
negotiation can affect the LDP keepalive interval as well. 


If the local LDP hold time is not shortened during LDP peer negotiation, the user-configured keepalive 
interval is left unchanged. However, if the local hold time is reduced during peer negotiation, the keepalive 
interval is recalculated. If the LDP hold time has been reduced during peer negotiation, the keepalive 
interval is reduced to one-third of the new hold time value. For example, if the new hold-time value is 45 
seconds, the keepalive interval is set to 15 seconds. 


This automated keepalive interval calculation can cause different keepalive intervals to be configured on 
each peer router. This enables the routers to be flexible in how often they send keepalive messages, 
because the LDP peer negotiation ensures they are sent more frequently than the LDP hold time. 


When you reconfigure the hold-time interval, changes do not take effect until after the session is reset. 
The hold time is negotiated when the LDP peering session is initiated and cannot be renegotiated as long 
as the session is up (required by RFC 5036, LDP Specification). To manually force the LDP session to reset, 
issue the clear Idp session command. 


Configuring the LDP Hold Time for Link Hello Messages 


To modify how long an LDP node should wait for a link hello message before declaring the neighbor down, 
specify a new time in seconds using the hold-time statement: 


hold-time seconds; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 
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Configuring the LDP Hold Time for Targeted Hello Messages 


To modify how long an LDP node should wait for a targeted hello message before declaring the neighbor 
down, specify a new time in seconds using the hold-time statement as an option for the targeted-hello 
statement: 


targeted-hello { 
hold-time seconds; 


For alist of hierarchy levels at which you can include these statements, see the statement summary sections 
for these statements. 


Enabling Strict Targeted Hello Messages for LDP 


Use strict targeted hello messages to prevent LDP sessions from being established with remote neighbors 
that have not been specifically configured. If you configure the strict-targeted-hellos statement, an LDP 
peer does not respond to targeted hello messages coming from a source that is not one of its configured 
remote neighbors. Configured remote neighbors can include: 


e Endpoints of RSVP tunnels for which LDP tunneling is configured 


e Layer 2 circuit neighbors 
If an unconfigured neighbor sends a hello message, the LDP peer ignores the message and logs an error 
(with the error trace flag) indicating the source. For example, if the LDP peer received a targeted hello 


from the Internet address 10.0.0.1 and no neighbor with this address is specifically configured, the following 
message is printed to the LDP log file: 


LDP: Ignoring targeted hello from 10.0.0.1 


To enable strict targeted hello messages, include the strict-targeted-hellos statement: 


strict-targeted-hellos; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Configuring the Interval for LDP Keepalive Messages 


The keepalive interval determines how often a message is sent over the session to ensure that the keepalive 
timeout is not exceeded. If no other LDP traffic is sent over the session in this much time, a keepalive 
message is sent. The default is 10 seconds. The minimum value is 1 second. 
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The value configured for the keepalive interval can be altered during LDP session negotiation if the value 
configured for the LDP hold time on the peer router is lower than the value configured locally. For more 
information, see “Configuring the Delay Before LDP Neighbors Are Considered Down” on page 870. 


To modify the keepalive interval, include the keepalive-interval statement: 


keepalive-interval seconds; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Configuring the LDP Keepalive Timeout 


After an LDP session is established, messages must be exchanged periodically to ensure that the session 
is still working. The keepalive timeout defines the amount of time that the neighbor LDP node waits before 
deciding that the session has failed. This value is usually set to at least three times the keepalive interval. 
The default is 30 seconds. 


To modify the keepalive interval, include the keepalive-timeout statement: 


keepalive-timeout seconds; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


The value configured for the keepalive-timeout statement is displayed as the hold time when you issue 
the show Idp session detail command. 


Configuring Longest Match for LDP 


In order to allow LDP to learn the routes aggregated or summarized across OSPF areas or ISIS levels in 
inter -domain, Junos OS allows you to configure longest match for LDP based on RFC5283. 


Before you configure longest match for LDP, you must do the following: 


1. Configure the device interfaces. 


2. Configure the MPLS protocol. 


3. Configure the OSPF protocol. 


To configure longest match for LDP, you must do the following: 


1. Configure longest match for the LDP protocol. 
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[edit protocols Idp] 
user@host# set longest-match 


2. Configure the LDP protocol on the interface. 


[edit protocols Idp] 
user@host# set interface interface-name 


For example, to configure the interfaces: 


[edit protocols Idp] 
user@host# set interface ge-0/0/2.0 
user@host# set interface lo0.0 


Example: Configuring Longest Match for LDP 


IN THIS SECTION 


Requirements | 873 
Overview | 874 
Configuration | 874 


Verification | 881 


This example shows how to configure longest match for LDP based on RFC5283. This allows LDP to learn 
the routes aggregated or summarized across OSPF areas or ISIS levels in inter-domain.. The longest match 
policy provides per prefix granularity. 


Requirements 


This example uses the following hardware and software components: 


e Six MX Series routers with OSPF protocol, and LDP enabled on the connected interfaces. 


e Junos OS Release 16.1 or later running on all devices. 
Before you begin: 


e Configure the device interfaces. 


e Configure OSPF. 
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Overview 


LDP is often used to establish MPLS label-switched paths (LSPs) throughout a complete network domain 
using an IGP such as OSPF or IS-IS. In such a network, all links in the domain have IGP adjacencies as well 
as LDP adjacencies. LDP establishes the LSPs on the shortest path to a destination as determined by IP 
forwarding. In Junos OS, the LDP implementation does an exact match lookup on the IP address of the 
FEC in the RIB or IGP routes for label mapping. This exact mapping requires MPLS end-to-end LDP endpoint 
IP addresses to be configured in all the LERs. This defeats the purpose of IP hierarchical design or default 
routing in access devices. Configuring longest-match helps to overcome this by suppressing the exact 
match behaviour and setup LSP based on the longest matching route on per-prefix basis. 


Topology 
In the topology, Figure 66 on page 874shows the longest match for LDP is configured on Device RO. 


Figure 66: Example Longest Match for LDP 
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Configuration 


CLI Quick Configuration 

To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


RO 


set interfaces ge-0/0/0 unit 0 family inet address 22.22.22.1/24 
set interfaces ge-0/0/1 unit 0 family inet address 15.15.15.1/24 
set interfaces ge-0/0/2 unit 0 family inet address 11.11.11.1/24 


R1 


R2 


set interfaces ge-0/0/2 unit 0 family iso 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.112.1/32 primary 
set interfaces loO unit O family inet address 10.255.112.1/32 preferred 
set interfaces loO unit O family iso address 49.0002.0192.0168.0001.00 
set routing-options router-id 10.255.112.1 

set protocols mpls interface ge-0/0/2.0 

set protocols ospf area 0.0.0.1 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.1 interface lo0.0 passive 

set protocols Idp longest-match 

set protocols Idp interface ge-0/0/2.0 

set protocols Idp interface lo0.0 


set interfaces ge-0/0/0 unit 0 family inet address 11.11.11.2/24 

set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 12.12.12.1/24 

set interfaces ge-0/0/1 unit 0 family iso 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.112.2/32 primary 
set interfaces loO unit O family inet address 10.255.112.2/32 preferred 
set interfaces loO unit O family iso address 49.0002.0192.0168.0002.00 
set routing-options router-id 10.255.112.2 

set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.1 interface ge-0/0/0.0 

set protocols Idp longest-match 

set protocols Idp interface ge-0/0/0.0 

set protocols Idp interface ge-0/0/1.0 

set protocols Idp interface lo0.0 
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set interfaces ge-0/0/0 unit 0 family inet address 24.24.24.1/24 
set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 12.12.12.2/24 
set interfaces ge-0/0/1 unit 0 family iso 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 23.23.23.1/24 
set interfaces ge-0/0/2 unit 0 family iso 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 22.22.22.2/24 
set interfaces ge-0/0/4 unit 0 family inet address 25.25.25.1/24 
set interfaces ge-0/0/4 unit 0 family iso 

set interfaces ge-0/0/4 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.111.4/32 primary 
set interfaces loO unit O family inet address 10.255.111.4/32 preferred 
set interfaces loO unit O family iso address 49.0003.0192.0168.0003.00 
set routing-options router-id 10.255.111.4 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface ge-0/0/4.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.2 area-range 10.255.111.0/24 

set protocols ospf area 0.0.0.2 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.2 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.2 interface ge-0/0/4.0 

set protocols Idp interface ge-0/0/0.0 

set protocols Idp interface ge-0/0/1.0 

set protocols Idp interface ge-0/0/2.0 

set protocols Idp interface ge-0/0/4.0 

set protocols Idp interface lo0.0 


set interfaces ge-0/0/0 unit 0 family inet address 35.35.35.1/24 
set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 23.23.23.2/24 
set interfaces ge-0/0/1 unit 0 family iso 
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R5 


set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 34.34.34.1/24 

set interfaces ge-0/0/2 unit 0 family iso 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.111.1/32 primary 
set interfaces loO unit O family inet address 10.255.111.1/32 preferred 
set interfaces loO unit O family iso address 49.0003.0192.0168.0004.00 
set routing-options router-id 10.255.111.1 

set protocols mpls interface ge-0/0/1.0 

set protocols ospf area 0.0.0.2 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.2 interface fxp0.0 disable 

set protocols ospf area 0.0.0.2 interface lo0.0 passive 

set protocols Idp interface ge-0/0/1.0 

set protocols Idp interface lo0.0 


set interfaces ge-0/0/0 unit 0 family inet address 45.45.45.1/24 

set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 24.24.24.2/24 

set interfaces ge-0/0/1 unit 0 family iso 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 34.34.34.2/24 

set interfaces ge-0/0/2 unit 0 family iso 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.111.2/32 primary 
set interfaces loO unit O family inet address 10.255.111.2/32 preferred 
set interfaces loO unit O family iso address 49.0003.0192.0168.0005.00 
set routing-options router-id 10.255.111.2 

set protocols mpls interface ge-0/0/1.0 

set protocols ospf area 0.0.0.2 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.2 interface fxp0.0 disable 

set protocols ospf area 0.0.0.2 interface lo0.0 passive 

set protocols Idp interface ge-0/0/1.0 

set protocols Idp interface lo0.0 
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set interfaces ge-0/0/0 unit 0 family inet address 25.25.25.2/24 

set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 15.15.15.2/24 

set interfaces ge-0/0/2 unit 0 family inet address 35.35.35.2/24 

set interfaces ge-0/0/3 unit 0 family inet address 45.45.45.2/24 

set interfaces ge-0/0/3 unit 0 family iso 

set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.111.3/32 primary 
set interfaces loO unit O family inet address 10.255.111.3/32 preferred 
set interfaces loO unit O family iso address 49.0003.0192.0168.0006.00 
set routing-options router-id 10.255.111.3 

set protocols mpls interface ge-0/0/0.0 

set protocols ospf area 0.0.0.2 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.2 interface fxp0.0 disable 

set protocols ospf area 0.0.0.2 interface lo0.0 passive 

set protocols Idp interface ge-0/0/0.0 

set protocols Idp interface lo0.0 


Configuring Device RO 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device RO: 


1. Configure the interfaces. 


[edit interfaces] 
set ge-0/0/0 unit O family inet address 22.22.22.1/24 


set ge-0/0/1 unit O family inet address 15.15.15.1/24 
set ge-0/0/2 unit O family inet address 11.11.11.1/24 


set ge-0/0/2 unit 0 family iso 
set ge-0/0/2 unit O family mpls 


2. Assign the loopback addresses to the device. 


[edit interfaces loO unit O family] 

set inet address 10.255.112.1/32 primary 
set inet address 10.255.112.1/32 preferred 
set iso address 49.0002.0192.0168.0001.00 


3. Configure the router ID. 


[edit routing-options] 
set router-id 10.255.112.1 


4. Configure the MPLS protocol on the interface. 


[edit protocols mpls] 
set interface ge-0/0/2.0 


5. Configure the OSPF protocol on the interface. 


[edit protocols ospf] 
set area 0.0.0.1 interface ge-0/0/2.0 
set area 0.0.0.1 interface lo0.0 passive 


6. Configure longest match for the LDP protocol. 


[edit protocols Idp] 
set longest-match 


7. Configure the LDP protocol on the interface. 


[edit protocols Idp] 
set interface ge-0/0/2.0 
set interface lo0.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
and show routing-options commands. If the output does not display the intended configuration, repeat 
the instructions in this example to correct the configuration. 
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user@RO# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 22.22.22.1/24; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 15.15.15.1/24; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 11.11.11.1/24; 
} 
family iso; 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 10.255.112.1/32 { 
primary; 
preferred; 


} 
family iso { 
address 49.0002.0192.0168.0001.00; 


user@RO# show protocols 
mpls { 
interface ge-0/0/2.0; 
} 
ospf { 
area 0.0.0.1 { 
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interface ge-0/0/2.0; 
interface 100.0 { 
passive; 


} 

Idp { 
longest-match; 
interface ge-0/0/2.0; 
interface 100.0; 


user@RO# show routing-options 
router-id 10.255.112.1; 


If you are done configuring the device, enter commit from the configuration mode. 


Verification 


IN THIS SECTION 


Verifying the Routes | 881 
Verifying LDP Overview Information | 886 


® 
ie) 
@ Verify the LDP Entries in the Internal Topology Table | 888 
@ ~~ Verify Only FEC Information of LDP Route | 889 

® 


Verify FEC and Shadow Routes of LDP | 890 


Confirm that the configuration is working properly. 


Verifying the Routes 


Purpose 


Verify that the expected routes are learned. 
Action 


On Device RO, from operational mode, run the show route command to display the routes in the routing 
table. 


user@RO> show route 
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inet.0: 62 destinations, 62 routes (62 active, 
+ = Active Route, Last Active, * = Both 
IO .4 20.0716 SracLe/ 5S] LdsOesOil 

Sie lO,92.391., 254 wile igo). 
10.5,0,.0/16 StactLe/S] LosOesOil 

> tO 10.92 51,254 wile iexqo0). 
106,128 0/17 Sieatee/ Sil Ol OSiOn 

> tO 10,.92.51,2454 wale exqo0). 
10.9.0.0/16 SieacLe/ 5] ldsoes@il 

Sito I0,92.31,254 wile itxqol0) . 
10 ,10.0,0/18 SiarLe/ 5] ldsoesOil 

> to 10,92, 31,254 wile igo), 
IO ,1 3,4. 0/28 SitaicLe/ S| LOsOsg@il 

> to© 10,92 31.2548 wile isqo0). 
10 .13,10 0/23 StacLe/ 5S] LOsoesOil 

Sito 10,92. 31,254 wile igo). 
10.82.0.0/15 StactLe/ 5S] LosOesOl 

> tO 10.92.51, 458 water iexqol). 
10.84.0.0/16 Static/5] 10:08:01 

> tO 10.92 51,4548 wate iexqol), 
10.85.12 .0/22 SiacLe/ 5] ldsoesOl 

> to 10,92. 31,254 wile iol). 
10.92.0,0/15 SiearLe/ 5] losoesOil 

> to 10,92, 31,2548 wile isgo0). 
19, 92,16.,.0/20 Direct/0] 10:08:01 

> wWakel i:45)0) 510) 
10.92.20 LIS / 32 Local/0] 10:08:01 

Local via fxp0.0 

10.94.0,0/1%5 StactLe/S] LosoesOil 

> tO 10.92 51,454 wile iexgol). 
10.99,0,.0/16 Sigal tee Sil NO OSiOn 

> to 10,.92.51,2454 wie exqo0). 
10,102 .,0 0/16 SieaeLe/ 5] losoesOil 

> to I0,92.31,254 wile iol). 
10,150.00 .0/16 SieacLe/ 5] LdsoesOil 

> to 10,92 31,254 wile iexqol), 
10, 155.0 0/16 Statie/ 5 HO 080i 

> to 10,92, 351,254 wile iesqol). 
10.157 .,64.0/19 StaictLe/S] LOsoesOl 

Sto 10,92. 31,254 wie iéxqoll). 
ORES OROR O16 SeactLe/ 5S] Los0esOl 

> tO 10.92.51, 2454 wile iexqol). 
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OSPF/10] 


> ct@ 11,2 wie 


Direct/0] 


Local/0] 


Local via ge-0/0/2.0 
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inet.3: 
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Last Active, * = Both 


2 via ge-0/0/2. 
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inet6.0: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


aloeele 128392 e203 175/128) 
= Dalaseic,/0)]] ILO SOs @)il 
> wile od). 0 

SSO S 8 HGS Sa OE 9 itewil § Lie e/g) 
<2 [)DalareKoucy/ (ON) blo) a (0)ts}Be)ik 


2 wie lo, 0 


Meaning 


The output shows all the routes in the routing table of Device RO. 


Verifying LDP Overview Information 


Purpose 


Display LDP overview information. 


Action 


On Device RO, from operational mode, run the show Idp overview command to display the overview of 


the LDP. 


user@RO> show lIdp overview 


TMiSsi= oie Cr aeinaicie cts 

Reference count: 2 

Romer UDR 10,255,112, 1 
essage id: 8 
Configuration sequence: 6 


Deaggregate: disabled 





Explicit null: disabled 

IPv6 tunneling: disabled 

Strict targeted hellos: disabled 
Loopback if added: yes 

Route preference: 9 

Unicast transit LSP chaining: disabled 
P2MP transit LSP chaining: disabled 


Transit LSP statistics based on route statistics: 





LDP route acknowledgement: enabled 


LDP mtu discovery: disabled 





Longest Match: enabled 





Capabilities enabled: non 


disabled 
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Egress FEC capabilities enabled: entropy-—label-capability 





Downstream unsolicited Sessions: 
Operational: 1 
Retention: liberal 
Control: ordered 
Auto targeted sessions: 
Auto targeted: disabled 
Timers: 
Keepalive interval: 10, Keepalive timeout: 30 
inaliole Joveibile) alineeiayeils 5, ikalink Inedlilke Im@Jlicl iemins3e 15 
Targeted hello interval: 15, Targeted hello hold time: 45 
Label withdraw delay: 60, Make before break timeout: 30 





Make before break switchover delay: 3 
Link protection timeout: 120 
Graceful restart: 


Restart: disabled, Helper: enabled, Restart in process: false 





Reconnect time: 60000, Max neighbor reconnect time: 120000 





Recovery time: 160000, Max neighbor recovery time: 240000 





Traffic Engineering: 

Bgp igp: disabled 

Both ribs: disabled 

Mpls forwarding: disabled 
MIGIe) 8 

Tracking igp metric: disabled 

Sync session up delay: 10 
Session protection: 

Session protection: disabled 

Session protection timeout: 0 
Interface addresses advertising: 

Tak Ab al 5 A aL eal 

10.255, 112.1 

129.,92.20 175 


Label allocation: 





Current number of LDP labels allocated: 5 
Total number of LDP labels allocated: 11 
Total number of LDP labels freed: 6 





Total number of LDP label allocation failure: 0 





Current number of labels allocated by all protocols: 5 


Meaning 


The output displays the LDP overview information of Device RO 


Verify the LDP Entries in the Internal Topology Table 


Purpose 


Display the route entries in the Label Distribution Protocol (LDP) internal topology table. 


Action 


On Device RO, from operational mode, run the show Idp route command to display the internal topology 


table of LDP. 


user@RO> show lIdp route 


Destination 
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Meaning 


The output displays the route entries in the Label Distribution Protocol (LDP) internal topology table of 
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Display only the FEC information of LDP route. 
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Action 


On Device RO, from operational mode, run the show Idp route fec-only command to display the routes 
in the routing table. 


user@RO> show ldp route fec-only 











Destination Next-hop intf/lsp/table Next-hop address 
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LO. 255, N12 2/32 ge-0/0/2.0 ILA da 5 dll 2 

Meaning 


The output displays only the FEC routes of LDP protocol available for Device RO. 


Verify FEC and Shadow Routes of LDP 


Purpose 


Display the FEC and the shadow routes in the routing table. 
Action 


On Device RO, from operational mode, run the show Idp route fec-and-route command to display the FEC 
and shadow routes in the routing table. 


user@RO> show lIdp route fec-and-route 
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Meaning 


The output displays the FEC and the shadow routes of Device RO 


Configuring LDP Route Preferences 


When several protocols calculate routes to the same destination, route preferences are used to select 
which route is installed in the forwarding table. The route with the lowest preference value is selected. 
The preference value can be a number in the range O through 255. By default, LDP routes have a preference 
value of 9. 


To modify the route preferences, include the preference statement: 


preference preference; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


LDP Graceful Restart 


LDP graceful restart enables a router whose LDP control plane is undergoing a restart to continue to 
forward traffic while recovering its state from neighboring routers. It also enables a router on which helper 
mode is enabled to assist a neighboring router that is attempting to restart LDP. 


During session initialization, a router advertises its ability to perform LDP graceful restart or to take 
advantage of a neighbor performing LDP graceful restart by sending the graceful restart TLV. This TLV 
contains two fields relevant to LDP graceful restart: the reconnect time and the recovery time. The values 
of the reconnect and recovery times indicate the graceful restart capabilities supported by the router. 
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When a router discovers that a neighboring router is restarting, it waits until the end of the recovery time 
before attempting to reconnect. The recovery time is the length of time a router waits for LDP to restart 
gracefully. The recovery time period begins when an initialization message is sent or received. This time 
period is also typically the length of time that a neighboring router maintains its information about the 
restarting router, allowing it to continue to forward traffic. 


You can configure LDP graceful restart in both the master instance for the LDP protocol and for a specific 
routing instance. You can disable graceful restart at the global level for all protocols, at the protocol level 
for LDP only, and on a specific routing instance. LDP graceful restart is disabled by default, because at the 
global level, graceful restart is disabled by default. However, helper mode (the ability to assist a neighboring 
router attempting a graceful restart) is enabled by default. 


The following are some of the behaviors associated with LDP graceful restart: 


Outgoing labels are not maintained in restarts. New outgoing labels are allocated. 


e When a router is restarting, no label-map messages are sent to neighbors that support graceful restart 
until the restarting router has stabilized (label-map messages are immediately sent to neighbors that do 
not support graceful restart). However, all other messages (keepalive, address-message, notification, 
and release) are sent as usual. Distributing these other messages prevents the router from distributing 
incomplete information. 


Helper mode and graceful restart are independent. You can disable graceful restart in the configuration, 


but still allow the router to cooperate with a neighbor attempting to restart gracefully. 


Configuring LDP Graceful Restart 


IN THIS SECTION 


Enabling Graceful Restart | 894 
Disabling LDP Graceful Restart or Helper Mode | 894 


Configuring Reconnect Time | 895 


Configuring Recovery Time and Maximum Recovery Time | 895 


When you alter the graceful restart configuration at either the [edit routing-options graceful-restart] or 
[edit protocols Idp graceful-restart] hierarchy levels, any running LDP session is automatically restarted 
to apply the graceful restart configuration. This behavior mirrors the behavior of BGP when you alter its 
graceful restart configuration. 
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By default, graceful restart helper mode is enabled, but graceful restart is disabled. Thus, the default 
behavior of a router is to assist neighboring routers attempting a graceful restart, but not to attempt a 
graceful restart itself. 


To configure LDP graceful restart, see the following sections: 


Enabling Graceful Restart 


To enable LDP graceful restart, you also need to enable graceful restart on the router. To enable graceful 
restart, include the graceful-restart statement: 


graceful-restart; 


You can include this statement at the following hierarchy levels: 


e [edit routing-options] 


e [edit logical-systems logical-system-name routing-options] 


NOTE: ACX Series routers do not support [edit logical-systems logical-system-name 
routing-options] hierarchy level. 


The graceful-restart statement enables graceful restart for all protocols supporting this feature on the 
router. For more information about graceful restart, see the Junos OS Routing Protocols Library. 


By default, LDP graceful restart is enabled when you enable graceful restart at both the LDP protocol level 
and on all the routing instances. However, you can disable both LDP graceful restart and LDP graceful 
restart helper mode. 


Disabling LDP Graceful Restart or Helper Mode 


To disable LDP graceful restart and recovery, include the disable statement: 


Idp { 
graceful-restart { 


disable; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


You can disable helper mode at the LDP protocols level only. You cannot disable helper mode for a specific 
routing instance. To disable LDP helper mode, include the helper-disable statement: 
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Idp { 
graceful-restart { 
helper-disable; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


The following LDP graceful restart configurations are possible: 


e LDP graceful restart and helper mode are both enabled. 


e LDP graceful restart is disabled but helper mode is enabled. A router configured in this way cannot 
restart gracefully but can help a restarting neighbor. 


e LDP graceful restart and helper mode are both disabled. The router does not use LDP graceful restart 
or the graceful restart type, length, and value (TLV) sent in the initialization message. The router behaves 
as a router that cannot support LDP graceful restart. 


A configuration error is issued if you attempt to enable graceful restart and disable helper mode. 


Configuring Reconnect Time 


After the LDP connection between neighbors fails, neighbors wait a certain amount of time for the gracefully 
restarting router to resume sending LDP messages. After the wait period, the LDP session can be 
reestablished. You can configure the wait period in seconds. This value is included in the fault tolerant 
session TLV sent in LDP initialization messages when LDP graceful restart is enabled. 


Suppose that Router A and Router B are LDP neighbors. Router A is the restarting Router. The reconnect 
time is the time that Router A tells Router B to wait after Router B detects that Router A restarted. 


To configure the reconnect time, include the reconnect-time statement: 


graceful-restart { 
reconnect-time seconds; 


You can set the reconnect time to a value in the range from 30 through 300 seconds. By default, it is 60 
seconds. 


For a list of hierarchy levels at which you can configure these statements, see the statement summary 
sections for these statements. 
Configuring Recovery Time and Maximum Recovery Time 


The recovery time is the amount of time a router waits for LDP to restart gracefully. The recovery time 
period begins when an initialization message is sent or received. This period is also typically the amount 
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of time that a neighboring router maintains its information about the restarting router, allowing it to 
continue to forward traffic. 


To prevent a neighboring router from being adversely affected if it receives a false value for the recovery 
time from the restarting router, you can configure the maximum recovery time on the neighboring router. 
A neighboring router maintains its state for the shorter of the two times. For example, Router A is performing 
an LDP graceful restart. It has sent a recovery time of 900 seconds to neighboring Router B. However, 
Router B has its maximum recovery time configured at 400 seconds. Router B will only wait for 400 seconds 
before it purges its LDP information from Router A. 


To configure recovery time, include the recovery-time statement and the maximum-neighbor-recovery-time 


statement: 


graceful-restart { 
maximum-neighbor-recovery-time seconds; 
recovery-time seconds; 


For a list of hierarchy levels at which you can configure these statements, see the statement summary 
sections for these statements. 


Filtering Inbound LDP Label Bindings 


You can filter received LDP label bindings, applying policies to accept or deny bindings advertised by 
neighboring routers. To configure received-label filtering, include the import statement: 


import [ policy-names ]; 
For a list of hierarchy levels at which you can include this statement, see the statement summary section 


for this statement. 


The named policy (configured at the [edit policy-options] hierarchy level) is applied to all label bindings 
received from all LDP neighbors. All filtering is done with from statements. Table 23 on page 896 lists the 
only from operators that apply to LDP received-label filtering. 


Table 23: from Operators That Apply to LDP Received-Label Filtering 


from Operator Description 


interface Matches on bindings received from a neighbor that 
is adjacent over the specified interface 


neighbor Matches on bindings received from the specified LDP 
router ID 


Table 23: from Operators That Apply to LDP Received-Label Filtering (continued) 


from Operator Description 


next-hop Matches on bindings received from a neighbor 
advertising the specified interface address 


route-filter Matches on bindings with the specified prefix 


If a binding is filtered, it still appears in the LDP database, but is not considered for installation as part of 
a label-switched path (LSP). 


Generally, applying policies in LDP can be used only to block the establishment of LSPs, not to control 
their routing. This is because the path that an LSP follows is determined by unicast routing, and not by 
LDP. However, when there are multiple equal-cost paths to the destination through different neighbors, 
you can use LDP filtering to exclude some of the possible next hops from consideration. (Otherwise, LDP 
chooses one of the possible next hops at random.) 


LDP sessions are not bound to interfaces or interface addresses. LDP advertises only per-router (not 
per-interface) labels; so if multiple parallel links exist between two routers, only one LDP session is 
established, and it is not bound to a single interface. When a router has multiple adjacencies to the same 
neighbor, take care to ensure that the filter does what is expected. (Generally, using next-hop and interface 
is not appropriate in this case.) 


If a label has been filtered (meaning that it has been rejected by the policy and is not used to construct an 
LSP), it is marked as filtered in the database: 


user@host> show Idp database 


Input label database, 10.10.255.1:0-10.10.255.6:0 
Label Prefix 

3 10.10.255.6/32 (Filtered) 

GuepuLlabeclMdavabasc, lO nnOr2Z > onules 0S hp Om a5) 6210) 
Label Prefix 

SO en ORebione/23) 2a (Blatter call) 


For more information about how to configure policies for LDP, see the Routing Policies, Firewall Filters, and 
Traffic Policers User Guide. 


Examples: Filtering Inbound LDP Label Bindings 
Accept only /32 prefixes from all neighbors: 


[edit] 
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protocols { 


Idp { 
import only-32; 


} 
policy-options { 
policy-statement only-32 { 
term first { 
from { 
route-filter 0.0.0.0/0 upto /31; 
} 
then reject; 
} 


then accept; 


Accept 131.108/16 or longer from router ID 10.10.255.2 and accept all prefixes from all other neighbors: 


[edit] 
protocols { 
Idp { 
import nosy-neighbor; 


} 
policy-options { 
policy-statement nosy-neighbor { 
term first { 
from { 
neighbor 10.10.255.2; 


route-filter 131.108.0.0/16 orlonger accept 
route-filter 0.0.0.0/0 orlonger reject; 


} 


then accept; 
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Filtering Outbound LDP Label Bindings 


You can configure export policies to filter LDP outbound labels. You can filter outbound label bindings by 
applying routing policies to block bindings from being advertised to neighboring routers. To configure 
outbound label filtering, include the export statement: 


export [policy-name]; 
For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


The named export policy (configured at the [edit policy-options] hierarchy level) is applied to all label 
bindings transmitted to all LDP neighbors. The only from operator that applies to LDP outbound label 
filtering is route-filter, which matches bindings with the specified prefix. The only to operators that apply 
to outbound label filtering are the operators in Table 24 on page 899. 


Table 24: to Operators for LDP Outbound-Label Filtering 


to Operator Description 


interface Matches on bindings sent to a neighbor that is adjacent over the specified 
interface 

neighbor Matches on bindings sent to the specified LDP router ID 

next-hop Matches on bindings sent to a neighbor advertising the specified interface 
address 


If a binding is filtered, the binding is not advertised to the neighboring router, but it can be installed as part 
of an LSP on the local router. You can apply policies in LDP to block the establishment of LSPs, but not to 
control their routing. The path an LSP follows is determined by unicast routing, not by LDP. 


LDP sessions are not bound to interfaces or interface addresses. LDP advertises only per-router (not 
per-interface) labels. If multiple parallel links exist between two routers, only one LDP session is established, 
and it is not bound to a single interface. 


Do not use the next-hop and interface operators when a router has multiple adjacencies to the same 
neighbor. 


Filtered labels are marked in the database: 


user@host> show Idp database 


Input label database, 10.10.255.1:0-10.10.255.3:0 
Label Prefix 
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IOOOO? 10,10 .255,.2/ 32 

3 10, 10.255 3/32 

Ouepuie labels database, LOR ln 255. k0- Oe Om Z255n Sei) 
Label Prefix 

3 10.10.2565. 1/32 

100001 10.10.255.6/32 (Filtered) 


For more information about how to configure policies for LDP, see the Routing Policies, Firewall Filters, and 
Traffic Policers User Guide. 


Examples: Filtering Outbound LDP Label Bindings 
Block transmission of the route for 10.10.255.6/32 to any neighbors: 


[edit protocols] 
Idp { 
export block-one; 
} 
policy-options { 
policy-statement block-one { 
term first { 
from { 
route-filter 10.10.255.6/32 exact; 
} 
then reject; 
} 


then accept; 


Send only 131.108/16 or longer to router ID 10.10.255.2, and send all prefixes to all other routers: 


[edit protocols] 
Idp { 
export limit-Isps; 
} 
policy-options { 
policy-statement limit-Isps { 
term allow-one { 
from { 
route-filter 131.108.0.0/16 orlonger; 
} 
to { 


neighbor 10.10.255.2; 
} 


then accept; 


} 
term block-the-rest { 
to { 
neighbor 10.10.255.2; 
} 


then reject; 


} 


then accept; 


Specifying the Transport Address Used by LDP 


Routers must first establish a TCP session between each other before they can establish an LDP session. 
The TCP session enables the routers to exchange the label advertisements needed for the LDP session. 
To establish the TCP session, each router must learn the other router's transport address. The transport 
address is an IP address used to identify the TCP session over which the LDP session will run. 


To configure the LDP transport address, include the transport-address statement: 


transport-address (router-id | interface); 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


If you specify the router-id option, the address of the router identifier is used as the transport address 
(unless otherwise configured, the router identifier is typically the same as the loopback address). If you 
specify the interface option, the interface address is used as the transport address for any LDP sessions 
to neighbors that can be reached over that interface. Note that the router identifier is used as the transport 
address by default. 


You cannot specify the interface option when there are multiple parallel links to the same LDP neighbor, 
because the LDP specification requires that the same transport address be advertised on all interfaces to 
the same neighbor. If LDP detects multiple parallel links to the same neighbor, it disables interfaces to that 
neighbor one by one until the condition is cleared, either by disconnecting the neighbor on an interface 
or by specifying the router-id option. 
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Control Transport Address Used for Targeted-LDP Session 


IN THIS SECTION 
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Troubleshooting Transport Address Configuration | 903 


To establish a TCP session between two devices, each device must learn the other device’s transport 
address. The transport address is an IP address used to identify the TCP session over which the LDP session 
operates. Earlier, this transport address could only be the router-ID or an interface address. With the LDP 
transport-address feature, you can explicitly configure any IP address as the transport address for targeted 
LDP neighbors for Layer 2 circuit, MPLS, and VPLS adjacencies. This enables you to control the targeted-LDP 
sessions using transport-address configuration. 


Benefits of Controlling Transport Address Used for Targeted-LDP Session 


Configuring transport address for establishing targeted-LDP sessions has the following benefits: 


e Flexible interface configurations—Provides the flexibility of configuring multiple IP addresses for one 


loopback interface without interrupting the creation of LDP session between the targeted-LDP neighbors. 


e Ease of operation—Transport address configured at the interface-level, allows you to use more than 


one protocol in the IGP backbone for LDP. This enables smooth and easy operations. 


Targeted-LDP Transport Address Overview 


Prior to Junos OS Release 19.1R1, LDP provided support only for router-ID or the interface address as 


the transport address on any LDP interface. The adjacencies formed on that interface used one of the IP 


addresses assigned to the interface or the router-ID. In case of targeted adjacency, the interface is the 


loopback interface. When multiple loopback addresses were configured on the device, the transport 
address could not be derived for the interface, and as a result, the LDP session could not be established. 


Starting in Junos OS Release 19.1R1, in addition to the default IP addresses used for transport address of 


targeted-LDP sessions, you can configure any other IP address as the transport address under the session, 


session-group, and interface configuration statements. The transport address configuration is applicable 


for configured neighbors only including Layer 2 circuits, MPLS, and VPLS adjacencies. This configuration 


does not apply to discovered adjacencies (targeted or not). 


Transport Address Preference 


You can configure transport address for targeted-LDP sessions at the session, session-group, and interface 


level. 
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After the transport address is configured, the targeted-LDP session is established based on the transport 
address preference of LDP. 


The order of preference of transport address for targeted neighbor (configured through Layer 2 circuit, 
MPLS, VPLS, and LDP configuration) is as follows: 


1. Under [edit protocols Idp session] hierarchy. 
2. Under [edit protocols Idp session-group] hierarchy. 
3. Under [edit protocols Idp interfcae loO] hierarchy. 
4. Under [edit protocols Idp] hierarchy. 

5. Default address. 


The order of preference of transport address for the discovered neighbors is as follows: 


1. Under [edit protocols Idp interfcae] hierarchy. 
2. Under [edit protocols Idp] hierarchy. 
3. Default address. 


The order of preference of transport address for auto-targeted neighbors where LDP is configured to 
accept hello packets is as follows: 


1. Under [edit protocols Idp interfcae loO] hierarchy. 
2. Under [edit protocols Idp] hierarchy. 


3. Default address. 


Troubleshooting Transport Address Configuration 

You can use the following show command outputs to troubleshoot targeted-LDP sessions: 
e show lIdp session 

e show Idp neighbor 


The detail level of output of the show Idp neighbor command displays the transport address sent in the 
hello messages to the targeted neighbor. If this address is not reachable from the neighbor, the LDP 
session does not come up. 


e show configuration protocols Idp 
You can also enable LDP traceoptions for further troubleshooting. 


e If the configuration is changed from using a transport address that is invalid (non reachable) to transport 
address that is valid, the following traces can be observed: 
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ay 29 10:47:11.570799 LDP: Session param Max PDU length 4096 from 10.55.1.4, 
negotiated 4096 
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1.570768 Session 10.55.1.4 state Initialized -> OpenRec 





























e If the configuration is changed from using a transport address that is valid to transport address that is 
invalid (non reachable),the following traces can be observed: 


May 29 10:42:36.317942 Session 10.55.1.4 GR state Operational -> Nonexistent 

aw 29 I0g4e2s sa. sisi Session 10.55,1,4 sitace Ooseireicaomel —> Closing 

ay 29 10:42:36.318208 LDP session 10.55.1.4 is down, reason: received notification 
from peer 


May 29 10:42:36.318236 RPD_LDP_SESSIONDOWN: LDP session 10.55.1.4 is down, reason: 





received notification from peer 
May 29 10:42:36.320081 Connection 10.55.1.4 state Open -> Closed 
ay 29 10:42:36.322411 Session 10.55.1.4 state Closing -> Nonexistent 











In case of faulty configuration, perform the following troubleshooting tasks: 


e Check the address family. The transport address that is configured under the session statement must 
belong to the same address family as the neighbor or session. 


e The address that is configured as the transport address under a neighbor or session statement must be 
local to the router for the targeted hello messages to start. You can check if the address is configured. 
If the address is not configured under any interface, the configuration is rejected. 


Configuring the Prefixes Advertised into LDP from the Routing Table 
You can control the set of prefixes that are advertised into LDP and cause the router to be the egress 


router for those prefixes. By default, only the loopback address is advertised into LDP. To configure the 
set of prefixes from the routing table to be advertised into LDP, include the egress-policy statement: 


egress-policy policy-name; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 
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NOTE: If you configure an egress policy for LDP that does not include the loopback address, it 
is no longer advertised in LDP. To continue to advertise the loopback address, you need to 
explicitly configure it as a part of the LDP egress policy. 


The named policy (configured at the [edit policy-options] or [edit logical-systems logical-system-name 
policy-options] hierarchy level) is applied to all routes in the routing table. Those routes that match the 
policy are advertised into LDP. You can control the set of neighbors to which those prefixes are advertised 
by using the export statement. Only from operators are considered; you can use any valid from operator. 
For more information, see the Junos OS Routing Protocols Library. 


NOTE: ACX Series routers do not support [edit logical-systems] hierarchy level. 


Example: Configuring the Prefixes Advertised into LDP 


Advertise all connected routes into LDP: 


[edit protocols] 
Idp { 

egress-policy connected-only; 
} 
policy-options { 

policy-statement connected-only { 

from { 
protocol direct; 


} 


then accept; 


} 


Configuring FEC Deaggregation 


When an LDP egress router advertises multiple prefixes, the prefixes are bound to a single label and 
aggregated into a single forwarding equivalence class (FEC). By default, LDP maintains this aggregation as 
the advertisement traverses the network. 


Normally, because an LSP is not split across multiple next hops and the prefixes are bound into a single 
LSP, load-balancing across equal-cost paths does not occur. You can, however, load-balance across 
equal-cost paths if you configure a load-balancing policy and deaggregate the FECs. 


Deaggregating the FECs causes each prefix to be bound to a separate label and become a separate LSP. 
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To configure deaggregated FECs, include the deaggregate statement: 


deaggregate; 
For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 
For all LDP sessions, you can configure deaggregated FECs only globally. 


Deaggregating a FEC allows the resulting multiple LSPs to be distributed across multiple equal-cost paths 
and distributes LSPs across the multiple next hops on the egress segments but installs only one next hop 
per LSP. 


To aggregate FECs, include the no-deaggregate statement: 


no-deaggregate; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


For all LDP sessions, you can configure aggregated FECs only globally. 


Configuring Policers for LDP FECs 


You can configure the Junos OS to track and police traffic for LDP FECs. LDP FEC policers can be used 
to do any of the following: 


e Track or police the ingress traffic for an LDP FEC. 

e Track or police the transit traffic for an LDP FEC. 

e Track or police LDP FEC traffic originating from a specific forwarding class. 

e Track or police LDP FEC traffic originating from a specific virtual routing and forwarding (VRF) site. 


e Discard false traffic bound for a specific LDP FEC. 


To police traffic for an LDP FEC, you must first configure a filter. Specifically, you need to configure either 
the interface statement or the interface-set statement at the [edit firewall family protocol-family filter 
filter-name term term-name from] hierarchy level. The interface statement allows you to match the filter 
to a single interface. The interface-set statement allows you to match the filter to multiple interfaces. 


For more information on how to configure the interface statement, the interface-set statement, and 
policers for LDP FECs, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide. 


Once you have configured the filters, you need to include them in the policing statement configuration 
for LDP. To configure policers for LDP FECs, include the policing statement: 
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policing { 
fec fec-address { 
ingress-traffic filter-name; 
transit-traffic filter-name; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


The policing statement includes the following options: 


e fec—Specify the FEC address for the LDP FEC you want to police. 
e ingress-filter—Specify the name of the ingress traffic filter. 


e transit-traffic—Specify the name of the transit traffic filter. 


Configuring LDP IPv4 FEC Filtering 


By default, when a targeted LDP session is established, the Junos OS always exchanges both the IPv4 
forwarding equivalence classes (FECs) and the Layer 2 circuit FECs over the targeted LDP session. For an 
LDP session to an indirectly connected neighbor, you might only want to export Layer 2 circuit FECs to 
the neighbor if the session was specifically configured to support Layer 2 circuits or VPLS. 


In a mixed vendor network where all non-BGP prefixes are advertised into LDP, the LDP database can 
become large. For this type of environment, it can be useful to prevent the advertisement of IPv4 FECs 
over LDP sessions formed because of Layer 2 circuit or LDP VPLS configuration. Similarly, it can be useful 
to filter any IPv4 FECs received in this sort of environment. 


If all the LDP neighbors associated with an LDP session are Layer 2 only, you can configure the Junos OS 
to advertise only Layer 2 circuit FECs by configuring the I2-smart-policy statement. This feature also 
automatically filters out the IPv4 FECs received on this session. Configuring an explicit export or import 
policy that is activated for I2-smart-policy disables this feature in the corresponding direction. 


If one of the LDP session’s neighbors is formed because of a discovered adjacency or if the adjacency is 
formed because of an LDP tunneling configuration on one or more RSVP LSPs, the IPv4 FECs are advertised 
and received using the default behavior. 


To prevent LDP from exporting IPv4 FECs over LDP sessions with Layer 2 neighbors only and to filter out 
IPv4 FECs received over such sessions, include the I2-smart-policy statement: 


|2-smart-policy; 
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For a list of hierarchy levels at which you can configure this statement, see the statement summary for 
this statement. 


Configuring BFD for LDP LSPs 


You can configure Bidirectional Forwarding Detection (BFD) for LDP LSPs. The BFD protocol is a simple 
hello mechanism that detects failures in a network. Hello packets are sent at a specified, regular interval. 
A neighbor failure is detected when the router stops receiving a reply after a specified interval. BFD works 
with a wide variety of network environments and topologies. The failure detection timers for BFD have 
shorter time limits than the failure detection mechanisms of static routes, providing faster detection. 


An error is logged whenever a BFD session for a path fails. The following shows how BFD for LDP LSP 
log messages might appear: 


RPD_LDP_BFD_UP: LDP BFD session for FEC 10.255.16.14/32 is up 
RPD_LDP_BFD_DOWN: LDP BFD session for FEC 10.255.16.14/32 is down 








You can also configure BFD for RSVP LSPs, as described in “Configuring BFD for RSVP-Signaled LSPs” on 
page 144. 


The BFD failure detection timers are adaptive and can be adjusted to be more or less aggressive. For 
example, the timers can adapt to a higher value if the adjacency fails, or a neighbor can negotiate a higher 
value for a timer than the configured value. The timers adapt to a higher value when a BFD session flap 
occurs more than three times in a span of 15 seconds. A back-off algorithm increases the receive (Rx) 
interval by two if the local BFD instance is the reason for the session flap. The transmission (Tx) interval 
is increased by two if the remote BFD instance is the reason for the session flap. You can use the clear 
bfd adaptation command to return BFD interval timers to their configured values. The clear bfd adaptation 
command is hitless, meaning that the command does not affect traffic flow on the routing device. 


To enable BFD for LDP LSPs, include the oam and bfd-liveness-detection statements: 


oam { 
bfd-liveness-detection { 
detection-time threshold milliseconds; 
ecmp; 
failure-action { 
remove-nexthop; 
remove-route; 
} 
holddown-interval seconds; 
ingress-policy ingress-policy-name; 
minimum-interval milliseconds; 


} 


minimum-receive-interval milliseconds; 
minimum-transmit-interval milliseconds; 
multiplier detection-time-multiplier, 
no-adaptation; 

transmit-interval { 


minimum-interval milliseconds; 
threshold milliseconds; 


version (0 | 1 | automatic); 


fec fec-address { 


bfd-liveness-detection { 


detection-time threshold milliseconds; 
ecmp; 
failure-action { 
remove-nexthop; 
remove-route; 
} 
holddown-interval milliseconds; 
ingress-policy ingress-policy-name; 
minimum-interval milliseconds; 
minimum-receive-interval milliseconds; 
minimum-transmit-interval milliseconds; 
multiplier detection-time-multiplier; 
no-adaptation; 
transmit-interval { 
minimum-interval milliseconds; 
threshold milliseconds; 
} 


version (0 | 1 | automatic); 


no-bfd-liveness-detection; 
periodic-traceroute { 


disable; 

exp exp-value; 

fanout fanout-value; 
frequency minutes; 
paths number-of-paths; 
retries retry-attempts; 
source address; 

ttl ttl-value; 

wait seconds; 
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Isp-ping-interval seconds; 
periodic-traceroute { 
disable; 
exp exp-value; 
fanout fanout-value; 
frequency minutes; 
paths number-of-paths; 
retries retry-attempts; 
source address; 
ttl ttl-value; 
Wait seconds; 


You can enable BFD for the LDP LSPs associated with a specific forwarding equivalence class (FEC) by 
configuring the FEC address using the fec option at the [edit protocols Idp] hierarchy level. Alternatively, 
you can configure an Operation Administration and Management (OAM) ingress policy to enable BFD on 
a range of FEC addresses. For more information, see “Configuring OAM Ingress Policies for LDP” on 
page 1148. 


You cannot enable BFD LDP LSPs unless their equivalent FEC addresses are explicitly configured or OAM 
is enabled on the FECs using an OAM ingress policy. If BFD is not enabled for any FEC addresses, the BFD 
session will not come up. 


You can configure the oam statement at the following hierarchy levels: 


e [edit protocols Idp] 


e [edit logical-systems logical-system-name protocols Idp] 


NOTE: ACX Series routers do not support [edit logical-systems] hierarchy level. 


The oam statement includes the following options: 


e fec—Specify the FEC address. You must either specify a FEC address or configure an OAM ingress policy 
to ensure that the BFD session comes up. 


e Isp-ping-interval—Specify the duration of the LSP ping interval in seconds. To issue a ping on an 
LDP-signaled LSP, use the ping mpls Idp command. For more information, see the CLI Explorer. 


910 


The bfd-liveness-detection statement includes the following options: 


e ecmp—Cause LDP to establish BFD sessions for all ECMP paths configured for the specified FEC. If you 
configure the ecmp option, you must also configure the periodic-traceroute statement for the specified 
FEC. If you do not do so, the commit operation fails. You can configure the periodic-traceroute statement 
at the global hierarchy level ([edit protocols Idp oam]) while only configuring the ecmp option for a 
specific FEC ([edit protocols Idp oam fec address bfd-liveness-detection]). 


holddown-interval—Specify the duration the BFD session should remain up before adding the route or 
next hop. Specifying a time of O seconds causes the route or next hop to be added as soon as the BFD 
session comes back up. 


minimum-interval—Specify the minimum transmit and receive interval. If you configure the 
minimum-interval option, you do not need to configure the minimum-receive-interval option or the 
minimum-transmit-interval option. 


minimum-receive-interval—Specify the minimum receive interval. The range is from 1 through 
255,000 milliseconds. 


minimum-transmit-interval—Specify the minimum transmit interval. The range is from 1 through 
255,000 milliseconds. 


multiplier—Specify the detection time multiplier. The range is from 1 through 255. 


version—Specify the BFD version. The options are BFD version O or BFD version 1. By default, the Junos 


OS software attempts to automatically determine the BFD version. 


Configuring ECMP-Aware BFD for LDP LSPs 


When you configure BFD for a FEC, a BFD session is established for only one active local next-hop for 
the router. However, you can configure multiple BFD sessions, one for each FEC associated with a specific 
equal-cost multipath (ECMP) path. For this to function properly, you also need to configure LDP LSP 
periodic traceroute. (See “Configuring LDP LSP Traceroute” on page 1052.) LDP LSP traceroute is used to 
discover ECMP paths. A BFD session is initiated for each ECMP path discovered. Whenever a BFD session 
for one of the ECMP paths fails, an error is logged. 


LDP LSP traceroute is run periodically to check the integrity of the ECMP paths. The following might occur 
when a problem is discovered: 


e If the latest LDP LSP traceroute for a FEC differs from the previous traceroute, the BFD sessions 
associated with that FEC (the BFD sessions for address ranges that have changed from previous run) 
are brought down and new BFD sessions are initiated for the destination addresses in the altered ranges. 


e If the LDP LSP traceroute returns an error (for example, a timeout), all the BFD sessions associated with 
that FEC are torn down. 


To configure LDP to establish BFD sessions for all ECMP paths configured for the specified FEC, include 
the ecmp statement. 


911 


912 


ecmp; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Along with the ecmp statement, you must also include the periodic-traceroute statement, either in the 
global LDP OAM configuration (at the [edit protocols Idp oam] or [edit logical-systems logical-system-name 
protocols Idp oam] hierarchy level) or in the configuration for the specified FEC (at the [edit protocols Idp 
oam fec address] or [edit logical-systems logical-system-name protocols Idp oam fec address] hierarchy 
level). Otherwise, the commit operation fails. 


NOTE: ACX Series routers do not support [edit logical-systems] hierarchy level. 


Configuring a Failure Action for the BFD Session on an LDP LSP 


You can configure route and next-hop properties in the event of a BFD session failure event on an LDP 
LSP. The failure event could be an existing BFD session that has gone down or could be a BFD session 
that never came up. LDP adds back the route or next hop when the relevant BFD session comes back up. 


You can configure one of the following failure action options for the failure-action statement in the event 
of a BFD session failure on the LDP LSP: 


e remove-nexthop—Removes the route corresponding to the next hop of the LSP's route at the ingress 
node when a BFD session failure event is detected. 


e remove-route—Removes the route corresponding to the LSP from the appropriate routing tables when 
a BFD session failure event is detected. If the LSP is configured with ECMP and a BFD session 
corresponding to any path goes down, the route is removed. 


To configure a failure action in the event of a BFD session failure on an LDP LSP, include either the 
remove-nexthop option or the remove-route option for the failure-action statement: 


failure-action { 
remove-nexthop; 
remove-route; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 
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Configuring the Holddown Interval for the BFD Session 


You can specify the duration the BFD session should be up before adding a route or next hop by configuring 
the holddown-interval statement at either the [edit protocols Idp oam bfd-livenesss-detection] hierarchy 
level or at the [edit protocols Idp oam fec address bfd-livenesss-detection] hierarchy level. Specifying a 
time of 0 seconds causes the route or next hop to be added as soon as the BFD session comes back up. 


holddown-interval seconds; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Configuring LDP Link Protection 
You can configure Label Distribution Protocol (LDP) link protection for both unicast and multicast LDP 
label-switched paths (LSPs) to provide resiliency during link or node failure. 
Before you begin: 
1. Configure the device interfaces. 
2. Configure the router ID and autonomous system number for the device. 
3. Configure the following protocols: 
a. RSVP 
b. MPLS with traffic engineering capability. 


c. OSPF with traffic engineering capability. 


NOTE: For multicast LDP link protection with loop-free alternative (LFA), enable link 
protection. 


[edit protocols] 
user@RO# set ospf area 0 interface all link-protection 


To configure LDP link protection: 


1. Enable point-to-multipoint LDP LSPs. 


[edit protocols] 
user@RO# set Idp p2mp 
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2. Enable LDP on all the interfaces of Router RO (excluding the management interface) and configure link 
protection with dynamic RSVP bypass LSP. 


[edit protocols] 
user@RO# set Idp interface all link-protection dynamic-rsvp-Isp 
user@RO# set Idp interface fxp0.0 disable 


3. Verify and commit the configuration. 


For example: 


[edit protocols] 
user@RO# show protocols 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 


} 
mpls { 
traffic-engineering; 
interface all; 
interface fxp0.0 { 
disable; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface all { 
metric 1; 
} 
interface fxp0.0 { 
disable; 


} 
Idp { 
interface all { 
link-protection { 
dynamic-rsvp-lsp; 


} 
interface fxp0.0 { 
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disable; 


} 
p2mp; 


[edit] 
user@RO# commit 
commit complete 


Example: Configuring LDP Link Protection 
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Introduction to LDP 


The Label Distribution Protocol (LDP) is a protocol for distributing labels in non-traffic-engineered 
applications. LDP allows routers to establish label-switched paths (LSPs) through a network by mapping 
network-layer routing information directly to the data link LSPs. 


These LSPs might have an endpoint at a directly attached neighbor (comparable to IP hop-by-hop forwarding) 
or at a network egress node, enabling switching through all intermediary nodes. LSPs established by LDP 
can also traverse traffic-engineered LSPs created by RSVP. 


LDP associates a forwarding equivalence class (FEC) with each LSP it creates. The FEC associated with an 
LSP specifies which packets are mapped to that LSP. LSPs are extended through a network as each router 
chooses the label advertised by the next hop for the FEC and splices it to the label it advertises to all other 
routers. This process forms a tree of LSPs that converge on the egress router. 


Junos OS LDP Protocol Implementation 


The Junos OS implementation of LDP supports LDP version 1. Junos OS supports a simple mechanism for 
tunneling between routers in an interior gateway protocol (IGP), to eliminate the required distribution of 
external routes within the core. Junos OS allows an MPLS tunnel next hop to all egress routers in the 
network, with only an IGP running in the core to distribute routes to egress routers. Edge routers run BGP 
but do not distribute external routes to the core. Instead, the recursive route lookup at the edge resolves 
to an LSP switched to the egress router. No external routes are necessary on the transit LDP routers. 


Understanding Multipoint Extensions to LDP 


An LDP defines mechanisms for setting up point-to-point, multipoint-to-point, point-to-multipoint, and 
multipoint-to-multipoint LSPs in the network. The point-to-multipoint and multipoint-to-multipoint LSPs 
are collectively referred to as multipoint LSPs, where traffic flows from a single source to multiple 
destinations, and from multiple sources to multiple destinations, respectively. The destination or egress 
routers are called leaf nodes, and traffic from the source traverses one or more transit nodes before 
reaching the leaf nodes. 


NOTE: Junos OS does not provide support for multipoint-to-multipoint LSPs. 


By taking advantage of the MPLS packet replication capability of the network, multipoint LSPs avoid 
unnecessary packet replication at the ingress router. Packet replication takes place only when packets are 
forwarded to two or more different destinations requiring different network paths. 


Using Multipoint Extensions to LDP on Targeted LDP Sessions 


The specification for the multipoint extensions to LDP requires that the two endpoints of an LDP session 
are directly connected by a Layer 2 medium, or are considered to be neighbors by the network's IGP. This 
is referred to as an LDP link session. When the two endpoints of an LDP session are not directly connected, 
the session is referred to as a targeted LDP session. 
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Past Junos OS implementations support multicast LDP for link sessions only. With the introduction of the 
LDP link protection feature, the multicast LDP capabilities are extended to targeted LDP sessions. 
Figure 67 on page 917 shows a sample topology. 


Figure 67: Multicast LDP Support for Targeted LDP Session 
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Routers R7 and R8 are the upstream (LSR-U) and downstream (LSR-D) label-switched routers (LSRs), 
respectively, and deploy multicast LDP. The core router, Router R5, has RSVP-TE enabled. 


When LSR-D is setting up the point-to-multipoint LSP with root and LSP ID attributes, it determines the 
upstream LSR-U as a next-hop on the best path to the root (currently, this next-hop is assumed to be an 
IGP next hop). 


With the multicast LDP support on targeted LDP sessions, you can determine if there is an LSP next hop 
to LSR-U which is on LSR-D's path to root, where LSR-D and LSR-U are not directly connected neighbors, 
but targeted LDP peers. The point-to-multipoint label advertised on the targeted LDP session between 
LSR-D and LSR-U is not used unless there is an LSP between LSR-D and LSR-U. Therefore, a corresponding 
LSP in the reverse direction from LSR-U to LSR-D is required. 


Data is transmitted on the point-to-multipoint LSP using unicast replication of packets, where LSR-U sends 
one copy to each downstream LSR of the point-to-multipoint LSP. 


The data transmission is implemented in the following ways: 
1. The point-to-multipoint capabilities on the targeted LDP session are negotiated. 
2. The algorithm to select the upstream LSR is changed, where if IGP next hops are unavailable, or in other 


words, there is no LDP link session between LSR-D and LSR-U, an RSVP LSP is used as the next hop 
to reach LSR-U. 


3. The incoming labels received over the targeted LDP sessions are installed as a branch next hop for this 
point-to-multipoint FEC route with the LDP label as the inner label and the RSVP label as the outer 
label. 


Current Limitations of LDP Link Protection 


When there is a link or node failure in an LDP network deployment, fast traffic recovery should be provided 
to recover impacted traffic flows for mission-critical services. In the case of multipoint LSPs, when one of 
the links of the point-to-multipoint tree fails, the subtrees might get detached until the IGP reconverges 
and the multipoint LSP is established using the best path from the downstream router to the new upstream 
router. 


In fast reroute using local repair for LDP traffic, a backup path (repair path) is pre-installed in the Packet 
Forwarding Engine. When the primary path fails, traffic is rapidly moved to the backup path without having 
to wait for the routing protocols to converge. Loop-free alternate (LFA) is one of the methods used to 
provide IP fast reroute capability in the core and service provider networks. 


Without LFA, when a link or a router fails or is returned to service, the distributed routing algorithms 
compute the new routes based on the changes in the network. The time during which the new routes are 
computed is referred to as routing transition. Until the routing transition is completed, the network 
connectivity is interrupted because the routers adjacent to a failure continue to forward the data packets 
through the failed component until an alternative path is identified. 


However, LFA does not provide full coverage in all network deployments because of the IGP metrics. As 
a result, this is a limitation to the current LDP link protection schemes. 


Figure 68 on page 918 illustrates a sample network with incomplete LFA coverage, where traffic flows from 
the source router (S) to the destination router (D) through Router R1. Assuming that each link in the 
network has the same metric, if the link between the Router S and Router R11 fails, Router R4 is not an 
LFA that protects the S-R1 link, so traffic resiliency is lost. Thus, full coverage is not achieved by using 
plain LFA. In typical networks, there is always some percentage of LFA coverage gap with plain LFA. 


Figure 68: Incomplete Coverage Problem with LFA 
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Using RSVP LSP as a Solution 


IN THIS SECTION 


@ = Manually Configured RSVP LSPs | 919 
@ Dynamically Configured RSVP LSPs | 920 


The key to protect the traffic flowing through LDP LSPs is to have an explicit tunnel to re-route the traffic 
in the event of a link or node failure. The explicit path has to terminate on the next downstream router, 
and the traffic needs to be accepted on the explicit path, where the RPF check should pass. 


RSVP LSPs help overcome the current limitations of loop-free alternate (LFA) for both point-to-point and 
point-to-multipoint LDP LSPs by extending the LFA coverage in the following methods: 


Manually Configured RSVP LSPs 


Considering the example used in Figure 68 on page 918, when the S-R11 link fails, and Router R4 is not an 
LFA for that particular link, a manually created RSVP LSP is used as a patch to provide complete LFA 
coverage. The RSVP LSP is pre-signaled and pre-installed in the Packet Forwarding Engine of Router S, so 
that it can be used as soon as Router S detects that the link has failed. 


Figure 69: Manually Configured RSVP LSP Coverage 
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In this case, an RSVP LSP is created between Routers S, R4, and R3 as illustrated in Figure 69 on page 919. 
A targeted LDP session is created between Router S and Router R3, as a result of which, when the S-R1 
link fails, traffic reaches Router R3. Router R3 forwards the traffic to Router R2, as it is the shortest path 
to reach the destination, Router D. 
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Dynamically Configured RSVP LSPs 


In this method, the RSVP LSPs are created automatically and pre-installed in the system so that they can 
be used immediately when there is a link failure. Here, the egress is the node on the other side of the link 
being protected, thereby improving the LFA coverage. 


Benefits of Enabling Dynamic RSVP LSPs 


e Ease of configuration. 


e 100 percent coverage against link failure as long as there is an alternate path to the far end of the link 
being protected. 


Setting up and tearing down of the RSVP bypass LSP is automatic. 


e RSVP LSP only used for link protection and not for forwarding traffic while the link being protected is 
up. 


e Reduces the total number of RSVP LSPs required on the system. 


Considering the example used in Figure 68 on page 918, in order to protect traffic against the potential 
failure of the S-R1 link, because Router R4 is not an LFA for that particular link, an RSVP bypass LSP is 
automatically created to Router R1, which is the node on the far side of the protected link as illustrated 
in Figure 70 on page 920. From Router R1, traffic is forwarded to its original destination, Router D. 


The RSVP LSP is pre-signaled and pre-installed in the Packet Forwarding Engine of Router S so that it can 
be used as soon as Router S detects that the link has failed. 


Figure 70: Dynamically Configured RSVP LSP Coverage 
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An alternative mode of operation is not to use LFA at all, and to always have the RSVP LSP created to 
cover all link failures. 


To enable dynamic RSVP LSPs, include the dynamic-rsvp-Isp statement at the [edit protocols Idp interface 
interface-name link-protection] hierarchy level, in addition to enabling the RSVP protocol on the appropriate 
interfaces. 


Understanding Multicast LDP Link Protection 


A point-to-multipoint LDP label-switched path (LSP) is an LDP-signaled LSP that is point-to-multipoint, 
and is referred to as multicast LDP. 


A multicast LDP LSP can be used to send traffic from a single root or ingress node to a number of leaf or 
egress nodes traversing one or more transit nodes. Multicast LDP link protection enables fast reroute of 
traffic carried over point-to-multipoint LDP LSPs in case of a link failure. When one of the links of the 
point-to-multipoint tree fails, the subtrees might get detached until the IGP reconverges and the multipoint 
LSP is established using the best path from the downstream router to the new upstream router. 


To protect the traffic flowing through the multicast LDP LSP, you can configure an explicit tunnel to 
re-route the traffic in the event of link failure. The explicit path has to terminate on the next downstream 
router. The reverse path forwarding for the traffic should be successful. 


Multicast LDP link protection introduces the following features and functionality: 


Use of dynamic RSVP LSP as bypass tunnels 


The RSVP LSP's Explicit Route Object (ERO) is calculated using Constrained Shortest Path First (CSPF) 
with the constraint as the link to avoid. The LSP is signaled and torn down dynamically whenever link 
protection is necessary. 


Make-before-break 


The make-before-break feature ensures that there is minimum packet loss when attempting to signal a 
new LSP path before tearing down the old LSP path for the multicast LDP LSP. 


Targeted LDP session 
A targeted adjacency to the downstream label-switching router (LSR) is created for two reasons: 
e To keep the session up after link failure. 


e To use the point-to-multipoint label received from the session to send traffic to the downstream LSR 
on the RSVP LSP bypass tunnel. 


When the downstream LSR sets up the multicast LDP LSP with the root node and LSP ID, it uses that 
upstream LSR, which is on the best path toward the root. 


NOTE: Multicast LDP link protection is not required when there are multiple link adjacencies 
(parallel links) to the downstream LSR. 
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Different Modes for Providing LDP Link Protection 


Following are three different modes of operation available for unicast and multicast LDP link protection: 


e Case A: LFA only 


Under this mode of operation, multicast LDP link protection is provided using an existing viable loop-free 
alternate (LFA). In the absence of a viable LFA, link protection is not provided for the multicast LDP LSP. 


e Case B: LFA and Dynamic RSVP LSP 


Under this mode of operation, multicast LDP link protection is provided using an existing viable LFA. In 
the absence of a viable LFA, an RSVP bypass LSP is created automatically to provide link protection for 
the multicast LDP LSP. 


e Case C: Dynamic RSVP LSP only 


Under this mode of operation, LFA is not used for link protection. Multicast LDP link protection is 
provided by using automatically created RSVP bypass LSP. 


Figure 71 on page 922 is a sample topology illustrating the different modes of operation for multicast LDP 
link protection. Router R5 is the root connecting to two leaf nodes, Routers R3 and R4. Router RO and 
Router R1 are the upstream and downstream label-switched routers (LSRs), respectively. A multicast LDP 
LSP runs among the root and leaf nodes. 


Figure 71: Multicast LDP Link Protection Sample Topology 
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== =~ Protection Tunnel 


Considering that Router RO needs to protect the multicast LDP LSP in the case that the RO-R11 link fails, 
the different modes of link protection operate in the following manner: 


e Case A: LFA only 


Router RO checks if a viable LFA path exists that can avoid the RO-R1 link to reach Router R1. Based on 
the metrics, Router R2 is a valid LFA path for the RO-R1 link and is used to forward unicast LDP traffic. 
If multiple multicast LDP LSPs use the RO-R1 link, the same LFA (Router R2) is used for multicast LDP 
link protection. 
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When the RO-R1 link fails, the multicast LDP LSP traffic is moved onto the LFA path by Router RO, and 
the unicast LDP label to reach Router R1 (L100) is pushed on top of the multicast LDP label (L21). 


Case B: LFA and Dynamic RSVP LSP 


Router RO checks if a viable LFA path exists that can avoid the RO-R1 link to reach Router R1. Based on 
the metrics, Router R2 is a valid LFA path for the RO-R1 link and is used to forward unicast LDP traffic. 
If multiple multicast LDP LSPs use the RO-R1 link, the same LFA (Router R2) is used for multicast LDP 
link protection. When the RO-R1 link fails, the multicast LDP LSP traffic is moved onto the LFA path by 
Router RO. 


However, if the metric on the R2-R1 link was 50 instead of 10, Router 2 is a not a valid LFA for the 
RO-R1 link. In this case, an RSVP LSP is automatically created to protect the multicast LDP traffic traveling 
between Routers RO and R1. 


Case C: Dynamic RSVP LSP only 


An RSVP LSP is signaled automatically from Router RO to Router R1 through Router R2, avoiding interface 
ge-1/1/0. If multiple multicast LDP LSPs use the RO-R11 link, the same RSVP LSP is used for multicast 
LDP link protection. 


When the RO-R1 link fails, the multicast LDP LSP traffic is moved onto the RSVP LSP by Router RO, and 
the RSVP label to reach Router R1 (L100) is pushed on top of the multicast LDP label (L21). 


Label Operation for LDP Link Protection 


IN THIS SECTION 


@ Case A: LFA Only | 924 
@ Case B: LFA and Dynamic RSVP LSP | 928 
@ Case C: Dynamic RSVP LSP Only | 930 


Using the same network topology as in Figure 5, Figure 72 on page 924 illustrates the label operation for 
unicast and multicast LDP link protection. 


Figure 72: LDP Label Operation Sample Topology 
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Router R5 is the root connecting to two leaf nodes, Routers R3 and R4. Router RO and Router R1 are the 
upstream and downstream label-switched routers (LSRs), respectively. A multicast LDP LSP runs among 
the root and leaf nodes. An unicast LDP path connects Router R1 to Router R5. 


The label operation is performed differently under the following modes of LDP link protection: 


Case A: LFA Only 


Using the show route detail command output on Router RO, the unicast LDP traffic and multicast LDP 
traffic can be derived. 


user@RO> show route detail 


299840 (1 entry, 1 announced) 

SIL ID2) Preference: 9 
Next hop type: Router 
Address: 0x93bc22c 
Next-hop reference count: 1 


Next hop: 11.0.0.6 via ge-0/0/1.0 weight 0x1, selected 





Label operation: Swap 299824 
Session Id: Oxl 
Next hop: 11.0.0.10 via ge-0/0/2.0 weight Oxf000 





Label operation: Swap 299808 
Session Id: 0x3 

State: <Active Int> 

Ages B36 Metric: 1 
Validation State: unverified 


Task: LDP 


924 


925 


Announcement bits (1): O-KRT 
AS@p athe mer 
Prefixes bound to route: 192.168.0.4/32 


299856 (1 entry, 1 announced) 

PSTD) Preference: 9 
Next hop type: Flood 
Address: 0x9340e04 





Next-hop reference count: 3 

Next hop type: Router, Next hop index: 262143 
Address UxJcbesde 

Next-hop reference count: 2 

Next hop: 11.0.0.6 via ge-0/0/1.0 weight 0x1 
Label operation: Swap 299888 

NeExte hop hl 0h Onl 0s varanqe—0)/0)/2.0mwerghtn Ox £01010 
Label operation: Swap 299888, Push 299776 (top) 











KAlgei WWI) BSELOMs joc e-cielL, jocM—icicill (item) 

State: <Active Int AckRequest> 

NGISS S816 Metric: 1 

Validation State: unverified 

Task: LDP 

Announcement bits (1): O-KRT 

AS» patch i 

FECs bound to route: P2MProot-addr 192.168.0.5, lsp-id 99 





Label 299840 is traffic arriving at Router RO that corresponds to unicast LDP traffic to Router R1. Label 
299856 is traffic arriving at Router O that corresponds to multicast LDP traffic from the root node R5 to 
the leaf egress nodes, R3 and R4. 


The main path for both unicast and multicast LDP LSPs is through interface ge-0/0/1 (the link to Router 
R1), and the LFA path is through interface ge-0/0/2 (the link to Router R2). The LFA path is not used unless 
the ge-0/0/1 interface goes down. 


In the label operation for Case A, the LFA-only mode of operation is different for unicast and multicast 
LDP traffic: 


e Unicast label operation 


For unicast LDP traffic, the FECs and associated labels are advertised on all the links in the network on 
which LDP is enabled. This means that in order to provide LFA action for the unicast LDP traffic to 
Router R4, instead of swapping the incoming label for label 299824 advertised by Router R1 for FEC 
R4, Router RO simply swaps the incoming label for label 299808 advertised by Router R2 for FEC R4. 
This is the standard Junos OS LFA operation for unicast LDP traffic. 


Figure 73 on page 926 illustrates the label operation for unicast traffic when the RO-R11 link fails. The 
grey boxes show the label operation for unicast LDP traffic under normal condition, and the dotted 
boxes show the label operation for unicast LDP traffic when the RO-R11 link fails. 


Figure 73: Unicast LDP Label Operation 
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Multicast label operation 


The label operation for multicast LDP traffic differs from the unicast LDP label operation, because 
multipoint LSP labels are only advertised along the best path from the leaf node to the ingress node. As 
a result, Router R2 has no knowledge of the multicast LDP. To overcome this, the multicast LDP LSP 
traffic is simply tunneled inside the unicast LDP LSP path through Router R2 that terminates at Router 
R1. 


In order to achieve this, Router RO first swaps the incoming multicast LDP LSP label 299856 to label 
299888 advertised by Router R1. Label 299776 is then pushed on top, which is the LDP label advertised 
by Router R2 for FEC R1. When the packet arrives at Router R2, the top label is popped out due to 
penultimate hop-popping. This means that the packet arrives at Router R1 with the multicast LDP label 
299888 that Router R1 had originally advertised to Router RO. 


Figure 74 on page 927 illustrates the label operation for multicast LDP traffic when the RO-R1 link fails. 
The blue boxes show the label operation for multicast LDP traffic under normal condition, and the dotted 
boxes show the label operation for multicast LDP traffic when the RO-R1 link fails. 
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Figure 74: Multicast LDP Label Operation 
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When the metric on the R2-R1 link is set to 1000 instead of 1, Router R2 is not a valid LFA for Router RO. 
In this case, if Router R2 receives a packet destined for Router R1, R3, or R4 before its IGP has converged, 
the packet is sent back to Router RO, resulting in looping packets. 


Because Router RO has no viable LFA, no backup paths are installed in the Packet Forwarding Engine. If 
the RO-R1 link fails, traffic flow is interrupted until the IGP and LDP converge and new entries are installed 
on the affected routers. 


The show route detail command displays the state when no LFA is available for link protection. 


user@host> show 


299840 (1 entry, 
* LDP 


route detail 


1 announced) 

Preference: 9 

Next hop type: Router, Next hop index: 578 
Address: 0x9340d20 





Next-hop reference count: 2 
Next hop: 11.0.0.6 via ge-0/0/1.0, selected 





Label operation: Swap 299824 

Session Id: 0xl 

State: <Active Int> 

Age: 5:38 Metric: 1 

Validation State: unverified 

Tek ILD 

Announcement bits (1): O-KRT 

ASM path ier 

Prefixes bound to route: 192.168.0.4/32 


928 


299856 (1 entry, 1 announced) 

eILID2) Preference: 9 
Next hop type: Flood 
Address: 0x9340e04 





Next-hop reference count: 3 
Next hop type: Router, Next hop index: 579 
Address: 0x93407c8 





Next-hop reference count: 2 
Next hop: 11.0.0.6 via ge-0/0/1.0 





Label operation: Swap 299888 





State: <Active Int AckRequest> 

Age: 5:38 Me teases 

Validation State: unverified 

Task: LDP 

Announcement bits (1): O-KRT 

AS path: I 

FECs bound to route: P2MProot-addr 192.168.0.5, lsp-id 99 





Case B: LFA and Dynamic RSVP LSP 


In this mode of operation, if there is a viable LFA neighbor, the label operation behavior is similar to that 
of Case A, LFA only mode. However, if there is no viable LFA neighbor, an RSVP bypass tunnel is 
automatically created. 


If the metric on the link R2-R1 is set to 1000 instead of 1, Router R2 is not an LFA for Router RO. On 
learning that there are no LFA paths to protect the RO-R11 link failure, an RSVP bypass tunnel is automatically 
created with Router R1 as the egress node and follows a path that avoids the RO-R1 link (for instance, 
RO-R2-R1). 


If the RO-R1 link fails, the unicast LDP and multicast LDP traffic is tunneled through the RSVP bypass 
tunnel. The RSVP bypass tunnel is not used for normal forwarding and is used only to provide link protection 
to LDP traffic in the case of RO-R1 link failure. 


Using the show route detail command, the unicast and multicast LDP traffic can be derived. 


user@host> show route detail 


299840 (1 entry, 1 announced) 

SIL ID2) Preference: 9 
Next hop type: Router 
Address: 0x940c3dc 





Next-hop reference count: 1 


Next hop: 11.0.0.6 via ge-0/0/1.0 weight 0x1, selected 





Label operation: Swap 299824 
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Session Id: 0Oxl 

Next hop: 11.0.0.10 via ge-0/0/2.0 weight 0x8001 
Label-—switched-path ge-0/0/1.0:BypassLSP—->192.168.0.1 
Label operation: Swap 299824, Push 299872 (top) 





Inaloeil WWI BGELOME joc e-icicll, jeeM—iticll (tem) 
Session Id: 0x3 

State: <Active Int NhAckRequest> 

Age: 19 Metric: 1 

Validation State: unverified 

WSS 8 ILD? 

Announcement bits (1): O-KRT 

NS jOenclag I 

Prefixes bound to route: 192.168.0.4/32 


299856 (1 entry, 1 announced) 

ee ILID2) Preference: 9 
Next hop type: Flood 
Address: 0x9340e04 
Next-hop reference count: 3 
Next hop type: Router, Next hop index: 262143 
Address: 0x940c154 
Next-hop reference count: 2 
Next hop: 11.0.0.6 via ge-0/0/1.0 weight 0x1 
Label operation: Swap 299888 
Next. hops J, 0R0nl0N valarge=0/ 0/250 werght Oss 0l0n 
Label-switched-path ge-0/0/1.0:BypassLSP->192.168.0.1 
Label operation: Swap 299888, Push 299872 (top) 
aloe Mimactel on OrOO> tie Manor Opa rela (deem) 











State: < Active Int AckRequest> 

Age: 20 Metric: 1 

Validation State: unverified 

WWI 9 ILD? 

Announcement bits (1): O-KRT 

AS path: I 

FECs bound to route: P2MProot-addr 192.168.0.5, lsp-id 99 





The main path for both unicast and multicast LDP LSP is through interface ge-0/0/1 (the link to Router 
R1), and the LFA path is through interface ge-0/0/2 (the link to Router R2). The LFA path is not used unless 
the ge-0/0/1 interface goes down. 


Label 299840 is traffic arriving at Router RO that corresponds to unicast LDP traffic to Router R4. Label 
299856 is traffic arriving at Router O that corresponds to multicast LDP traffic from the root node R5 to 
the leaf egress nodes, R3 and R4. 
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As seen in the show route detail command output, the label operations for the protection path are the 
same for unicast LDP and multicast LDP traffic. The incoming LDP label at Router RO is swapped to the 
LDP label advertised by Router R1 to Router RO. The RSVP label 299872 for the bypass tunnel is then 
pushed onto the packet. Penultimate hop-popping is used on the bypass tunnel, causing Router R2 to pop 
that label. Thus the packet arrives at Router R1 with the LDP label that it had originally advertised to 
Router RO. 


Figure 75 on page 930 illustrates the label operation for unicast LDP and multicast LDP traffic protected 
by the RSVP bypass tunnel. The grey and blue boxes represent label values used under normal conditions 
for unicast and multicast LDP traffic, respectively. The dotted boxes represent label values used when the 
RO-R11 link fails. 


Figure 75: LDP Link Protection Label Operation 
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===> Unicast LDP ==== RO-R!1 link failure 


Case C: Dynamic RSVP LSP Only 


In this mode of operation, LFA is not used at all. A dynamic RSVP bypass LSP is automatically created in 
order to provide link protection. The output from the show route detail command and the label operations 
are similar to Case B, LFA and dynamic RSVP LSP mode. 


Sample Multicast LDP Link Protection Configuration 


To enable multicast LDP link protection, the following configuration is required on Router RO: 


= ENG 


‘NOTE: In this sample, multicast LDP link protection is enabled on the ge-1/0/0 interface of 
Router RO that connects to Router R1, although typically all the interfaces need to be configured 
for link protection. 


Router RO 


protocols { 
rsvp { 
interface all; 
interface ge-0/0/0.0 { 
disable; 


} 
mpls { 
interface all; 
interface ge-0/0/0.0 { 
disable; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface 100.0; 
interface ge-0/0/1.0 { 
link-protection; 
} 
interface ge-0/0/2.0; 
interface ge-0/0/3.0; 


} 
Idp { 
make-before-break { 
timeout seconds; 
switchover-delay seconds; 
} 
interface ge-1/1/0.0 { 
link-protection { 
disable; 
dynamic-rsvp-Isp; 


The following configuration statements apply to the different modes of multicast LDP protection as follows: 


e link-protection statement at [edit protocols ospf interface ge-0/0/1.0] 
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This configuration is applied only for Case A (LFA only) and Case B (LFA and dynamic RSVP LSP) modes 
of multicast LDP link protection. Configuring link protection under an IGP is not required for Case C 
(dynamic RSVP LSP only). 


link-protection statement at [edit protocols Idp interface ge-0/0/1.0] 


This configuration is required for all modes of multicast LDP protection. However, if the only LDP traffic 
present is unicast, and dynamic RSVP bypasses are not required, then this configuration is not required, 
as the link-protection statement at the [edit protocols ospf interface ge-0/0/1.0] hierarchy level results 
in LFA action for the LDP unicast traffic. 


dynamic-rsvp-Isp statement at [edit protocols Idp interface ge-0/0/1.0 link-protection] 


This configuration is applied only for Case B (LFA and dynamic RSVP LSP) and Case C (dynamic RSVP 
LSP only) modes of LDP link protection. Dynamic RSVP LSP configuration does not apply to Case A (LFA 
only). 


Make-Before-Break 


The make-before-break feature is enabled by default on Junos OS and provides some benefits for 
point-to-multipoint LSPs. 


For a point-to-multipoint LSP, a label-switched router (LSR) selects the LSR that is its next hop to the root 
of the LSP as its upstream LSR. When the best path to reach the root changes, the LSR chooses a new 
upstream LSR. During this period, the LSP might be temporarily broken, resulting in packet loss until the 
LSP reconverges to a new upstream LSR. The goal of make-before-break in this case is to minimize the 
packet loss. In cases where the best path from the LSR to the root changes but the LSP continues to 
forward traffic to the previous next hop to the root, a new LSP should be established before the old LSP 
is withdrawn to minimize the duration of packet loss. 


Taking for example, after a link failure, a downstream LSR (for instance, LSR-D) still receives and/or forwards 
packets to the other downstream LSRs, as it continues to receive packets from the one hop RSVP LSP. 
Once routing converges, LSR-D selects a new upstream LSR (LSR-U) for this point-to-multipoint LSP's FEC 
(FEC-A). The new LSR might already be forwarding packets for FEC-A to the downstream LSRs other than 
LSR-D. After LSR-U receives a label for FEC-A from LSR-D, it notifies LSR-D when it has learnt that LSP 
for FEC-A has been established from the root to itself. When LSR-D receives such a notification, it changes 
its next hop for the LSP root to LSR-U. This is a route delete and add operation on LSR-D. At this point, 
LSR-D does an LSP switchover, and traffic tunneled through RSVP LSP or LFA is dropped, and traffic from 
LSR-U is accepted. The new transit route for LSR-U is added. The RPF check is changed to accept traffic 
from LSR-U and to drop traffic from the old upstream LSR, or the old route is deleted and the new route 
is added. 


The assumption is that LSR-U has received a make-before-break notification from its upstream router for 
the FEC-A point-to-multipoint LSP and has installed a forwarding state for the LSP. At that point it should 
signal LSR-D by means of make-before-break notification that it has become part of the tree identified by 
FEC-A and that LSR-D should initiate its switchover to the LSP. Otherwise, LSR-U should remember that 
it needs to send notification to LSR-D when it receives a make-before-break notification from the upstream 
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LSR for FEC-A and installs a forwarding state for this LSP. LSR-D continues to receive traffic from the old 
next hop to the root node using one hop RSVP LSP or LFA path until it switches over to the new 
point-to-multipoint LSP to LSR-U. 


The make-before-break functionality with multicast LDP link protection includes the following features: 


Make-before-break capability 


An LSR advertises that it is capable of handling make-before-break LSPs using the capability advertisement. 
If the peer is not make-before-break capable, the make-before-break parameters are not sent to this 
peer. If an LSR receives a make-before-break parameter from a downstream LSR (LSR-D) but the upstream 
LSR (LSR-U) is not make-before-break capable, the LSR immediately sends a make-before-break 
notification to LSR-D, and the make-before-break capable LSP is not established. Instead, the normal 
LSP is established. 


Make-before-break status code 
The make-before-break status code includes: 
e 1—make-before-break request 


e 2—make-before-break acknowledgment 


When a downstream LSR sends a label-mapping message for point-to-multipoint LSP, it includes the 
make-before-break status code as 1 (request). When the upstream LSR updates the forwarding state 
for the point-to-multipoint LSP, it informs the downstream LSR with a notification message containing 
the make-before-break status code as 2 (acknowledgment). At that point, the downstream LSR does an 
LSP switchover. 


Caveats and Limitations 


The Junos OS implementation of the LDP link protection feature has the following caveats and limitations: 


e Make-before-break is not supported for the following point-to-multipoint LSPs on an egress LSR: 


e Next-generation multicast virtual private network (MVPN) with virtual routing and forwarding (VRF) 
label 


e Static LSP 


e The following features are not supported: 


e Nonstop active routing for point-to-multipoint LSP in Junos OS Releases 12.3, 13.1 and 13.2 
e Graceful restart switchover point-to-multipoint LSP 


e Link protection for routing instance 


Example: Configuring LDP Link Protection 


IN THIS SECTION 


Requirements | 934 
Overview | 934 
Configuration | 936 


Verification | 942 


This example shows how to configure Label Distribution Protocol (LDP) link protection for both unicast 
and multicast LDP label-switched paths (LSPs). 

Requirements 

This example uses the following hardware and software components: 


e Six routers that can be a combination of M Series, MX Series, or T Series routers with one root node 
and two leaf nodes running a point-to-multipoint LDP LSP. 


e Junos OS Release 12.3 or later running on all the routers. 
Before you begin: 


1. Configure the device interfaces. 
2. Configure the following protocols: 
a. RSVP 
b. MPLS 
c. OSPF or any other IGP 
d. LDP 


Overview 


LDP link protection enables fast reroute of traffic carried over LDP LSPs in case of a link failure. LDP 
point-to-multipoint LSPs can be used to send traffic from a single root or ingress node to a number of leaf 
nodes or egress nodes traversing one or more transit nodes. When one of the links of the point-to-multipoint 
tree fails, the subtrees can get detached until the IGP reconverges and multicast LDP initiates label mapping 
using the best path from the downstream router to the new upstream router. To protect the traffic in the 
event of a link failure, you can configure an explicit tunnel so that traffic can be rerouted using the tunnel. 
Junos OS supports make-before-break capabilities to ensure minimum packet loss when attempting to 
signal a new LSP path before tearing down the old LSP path. This feature also adds targeted LDP support 
for multicast LDP link protection. 
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When configuring LDP link protection, be aware of the following considerations: 


Configure traffic engineering under IGP (if it is not supported by default), and include the interfaces 
configured for MPLS and RSVP so that constrained-based link protected dynamic RSVP LSP is signaled 
by RSVP using Constrained Shortest Path First (CSPF). When this condition is not satisfied, RSVP LSP 
might not come up and LDP cannot use it as a protected next hop. 


Configure a path between two label-switched routers (LSRs) to provide IP connectivity between the 
routers when there is a link failure. This enables CSPF to calculate an alternate path for link protection. 
When the connectivity between the routers is lost, the LDP targeted adjacency does not come up and 
dynamic RSVP LSP cannot be signaled, resulting in no protection for the LDP forwarding equivalence 
class (FEC) for which the peer is the downstream LSR. 


If link protection is active only on one LSR, then the other LSR should not be configured with the 
strict-targeted-hellos statement. This enables the LSR without link protection to allow asymmetric 
remote neighbor discovery and send periodic targeted hellos to the LSR that initiated the remote neighbor. 
When this condition is not satisfied, LDP targeted adjacency is not formed. 


LDP must be enabled on the loopback interface of the LSR to create remote neighbors based on LDP 
tunneling, LDP-based virtual private LAN service (VPLS), Layer 2 circuits, or LDP session protection. 
When this condition is not satisfied, LDP targeted adjacency is not formed. 


For unicast LDP LSP, loop-free alternate (LFA) should be configured in IGP. 


e The ingress route to merge point should have at least one next hop avoiding the primary link between 
the merge point and the point of local repair for unicast LDP LSP. 


Point of local repair should have a unicast LDP label for the backup next hop to reach the merge point. 


Topology 


Figure 76: LDP Link Protection 
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In this example, Router R5 is the root connecting to two leaf nodes, Routers R3 and R4. Router RO is the 
point of local repair. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


R5 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/30 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.1.5/32 

set routing-options router-id 10.255.1.5 

set routing-options autonomous-system 100 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls traffic-engineering 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all metric 1 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all link-protection dynamic-rsvp-Isp 
set protocols Idp interface fxp0.0 disable 

set protocols Idp p2mp 


RO 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.2/30 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 20.10.10.1/30 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 30.10.10.1/30 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.1.0/32 

set routing-options router-id 10.255.1.0 

set routing-options autonomous-system 100 


R1 


R2 


set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls traffic-engineering 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all metric 1 
set protocols ospf area 0.0.0.0 interface fxp0.0 disable 
set protocols Idp interface all link-protection dynamic-rsvp-Isp 
set protocols Idp interface fxp0.0 disable 

set protocols Idp p2mp 


set interfaces ge-0/0/0 unit 0 family inet address 60.10.10.2/30 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 40.10.10.1/30 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 30.10.10.2/30 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 50.10.10.1/30 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.1.1/32 

set routing-options router-id 10.255.1.1 

set routing-options autonomous-system 100 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls traffic-engineering 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all metric 1 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all link-protection dynamic-rsvp-Isp 
set protocols Idp interface fxp0.0 disable 

set protocols Idp p2mp 
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R3 


R4 


set interfaces ge-0/0/0 unit 0 family inet address 60.10.10.1/30 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 20.10.10.2/30 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.1.2/32 

set routing-options router-id 10.255.1.2 

set routing-options autonomous-system 100 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls traffic-engineering 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all link-protection dynamic-rsvp-Isp 
set protocols Idp interface fxp0.0 disable 

set protocols Idp p2mp 


set interfaces ge-0/0/1 unit 0 family inet address 40.10.10.2/30 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.1.3/32 

set routing-options router-id 10.255.1.3 

set routing-options autonomous-system 100 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls traffic-engineering 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all metric 1 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all link-protection dynamic-rsvp-Isp 
set protocols Idp interface fxp0.0 disable 

set protocols Idp p2mp root-address 10.255.1.5 Isp-id 1 
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set interfaces ge-0/0/3 unit 0 family inet address 50.10.10.2/30 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.1.4/32 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls traffic-engineering 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all metric 1 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all link-protection dynamic-rsvp-Isp 
set protocols Idp interface fxp0.0 disable 

set protocols Idp p2mp root-address 10.255.1.5 Isp-id 1 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode. 


To configure Router RO: 


1. Configure the Router RO interfaces. 


[edit interfaces] 

user@RO# set ge-0/0/0 unit 0 family inet address 10.10.10.2/30 
user@RO# set ge-0/0/0 unit 0 family mpls 

user@RO# set ge-0/0/1 unit O family inet address 20.10.10.1/30 
user@RO# set ge-0/0/1 unit 0 family mpls 

user@RO# set ge-0/0/2 unit 0 family inet address 30.10.10.1/30 
user@RO# set ge-0/0/2 unit 0 family mpls 

user@RO# set lo0 unit O family inet address 10.255.1.0/32 


2. Configure the router ID and autonomous system of Router RO. 
[edit routing-options] 


user@RO# set router-id 10.255.1.0 
user@RO# set autonomous-system 100 


3. Enable RSVP on all the interfaces of Router RO (excluding the management interface). 
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[edit protocols] 
user@RO# set rsvp interface all 
user@RO# set rsvp interface fxp0.0 disable 


4. Enable MPLS on all the interfaces of Router RO (excluding the management interface) along with traffic 
engineering capabilities. 


[edit protocols] 

user@RO# set mpls traffic-engineering 
user@RO# set mpls interface all 

user@RO# set mpls interface fxp0.0 disable 


5. Enable OSPF onall the interfaces of Router RO (excluding the management interface), assign equal cost 


metric for the links, and enable traffic engineering capabilities. 


[edit protocols] 

user@RO# set ospf traffic-engineering 

user@RO# set ospf area 0.0.0.0 interface all metric 1 
user@RO# set ospf area 0.0.0.0 interface fxp0.0 disable 


NOTE: For multicast LDP link protection with loop-free alternative (LFA), enable the following 
configuration under the [edit protocols] hierarchy level: 


set ospf area 0 interface all link-protection 


6. Enable LDP on all the interfaces of Router RO (excluding the management interface) and configure link 
protection with dynamic RSVP bypass LSP. 


[edit protocols] 

user@RO# set Idp interface all link-protection dynamic-rsvp-Isp 
user@RO# set Idp interface fxp0.0 disable 

user@RO# set Idp p2mp 


Results 
From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 
and show protocols commands. If the output does not display the intended configuration, repeat the 


instructions in this example to correct the configuration. 


user@RO# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 10.10.10.2/30; 
} 


family mpls; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 20.10.10.1/30; 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 30.10.10.1/30; 
} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 10.255.1.0/32; 


user@RO# show routing-options 
router-id 10.255.1.0; 
autonomous-system 100; 


user@RO# show protocols 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 
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} 
mpls { 
traffic-engineering; 
interface all; 
interface fxp0.0 { 
disable; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface all { 
metric 1; 
} 
interface fxp0.0 { 
disable; 


} 
Idp { 
interface all { 
link-protection { 
dynamic-rsvp-lsp; 


} 
interface fxp0.0 { 


disable; 


} 
p2mp; 


Verification 


IN THIS SECTION 


@ Verifying the Bypass RSVP LSP Path | 943 
@ Verifying Label Operation | 944 


Verify that the configuration is working properly. 
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Verifying the Bypass RSVP LSP Path 


Purpose 


Verify that the bypass RSVP LSP path has been created on the point of local repair (PLR). 


Action 


From operational mode, run the show route tale mpls.0 command. 


user@RO> show route tale mpls.0O 
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Meaning 
When the RO-R1 link goes down, the RSVP bypass LSP is used to route traffic. 


Verifying Label Operation 


Purpose 


Verify the label swapping at the PLR. 
Action 


From operational mode, run the show route table mpls.0 label label extensive command. 


user@RO> show route table mpls.0O label 300000 extensive 


mpls.0: 17 destinations, 17 routes (17 active, 0 holddown, 0 hidden) 
300000 (1 entry, 1 announced) 
Sal g 
KRT in-kernel 300000 /52 -> {Swap 300016} 
*LDP Preference: 9 
Next hop type: Router, Next hop index: 589 
Address: 0x9981610 





Next-hop reference count: 2 

Next hop: 30.10.10.2 via ge-0/0/2.0, selected 
Label operation: Swap 300016 

Load balance label: Label 300016: None; 





Session Id: 0x2 

State: <Active Int> 

Local AS: 100 

Age: 12:50 Metric: 1 

Validation State: unverified 

Task: LDP 

Announcement bits (1): 1-KRT 

AS path: I 

Prefixes bound to route: 10.255.1.4/32 


Meaning 


The label is bound to reach Router R4, which is a leaf node. 


Understanding Multicast-Only Fast Reroute 


IN THIS SECTION 


MoFRR Overview | 945 
PIM Functionality | 948 
Multipoint LDP Functionality | 949 
Packet Forwarding | 950 


Limitations and Caveats | 951 


Multicast-only fast reroute (MoFRR) minimizes packet loss for traffic in a multicast distribution tree when 
link failures occur, enhancing multicast routing protocols like Protocol Independent Multicast (PIM) and 
multipoint Label Distribution Protocol (multipoint LDP) on devices that support these features. 


NOTE: On switches, MoFRR with MPLS label-switched paths and multipoint LDP is not supported. 


For MX Series routers, MoFRR is supported only on MX Series routers with MPC line cards. As 
a prerequisite, you must configure the router into network-services enhanced-ip mode, and all 
the line cards in the router must be MPCs. 


With MoFRR enabled, devices send join messages on primary and backup upstream paths toward a multicast 
source. Devices receive data packets from both the primary and backup paths, and discard the redundant 
packets based on priority (weights that are assigned to the primary and backup paths). When a device 

detects a failure on the primary path, it immediately starts accepting packets from the secondary interface 
(the backup path). The fast switchover greatly improves convergence times upon primary path link failures. 


One application for MoFRR is streaming IPTV. IPTV streams are multicast as UDP streams, so any lost 
packets are not retransmitted, leading to a less-than-satisfactory user experience. MoFRR can improve 
the situation. 


MoFRR Overview 


With fast reroute on unicast streams, an upstream routing device preestablishes MPLS label-switched 
paths (LSPs) or precomputes an IP loop-free alternate (LFA) fast reroute backup path to handle failure of 
a segment in the downstream path. 
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In multicast routing, the receiving side usually originates the traffic distribution graphs. This is unlike unicast 
routing, which generally establishes the path from the source to the receiver. PIM (for IP), multipoint LDP 
(for MPLS), and RSVP-TE (for MPLS) are protocols that are capable of establishing multicast distribution 
graphs. Of these, PIM and multipoint LDP receivers initiate the distribution graph setup, so MoFRR can 
work with these two multicast protocols where they are supported. 


In a multicast tree, if the device detects a network component failure, it takes some time to perform a 
reactive repair, leading to significant traffic loss while setting up an alternate path. MoFRR reduces traffic 
loss in a multicast distribution tree when a network component fails. With MoFRR, one of the downstream 
routing devices sets up an alternative path toward the source to receive a backup live stream of the same 
multicast traffic. When a failure happens along the primary stream, the MoFRR routing device can quickly 
switch to the backup stream. 


With MoFRR enabled, for each (S,G) entry, the device uses two of the available upstream interfaces to 
send a join message and to receive multicast traffic. The protocol attempts to select two disjoint paths if 
two such paths are available. If disjoint paths are not available, the protocol selects two non-disjoint paths. 
If two non-disjoint paths are not available, only a primary path is selected with no backup. MoFRR prioritizes 
the disjoint backup in favor of load balancing the available paths. 


MoFRR is supported for both IPv4 and IPv6 protocol families. 


Figure 77 on page 947 shows two paths from the multicast receiver routing device (also referred to as the 
egress provider edge (PE) device) to the multicast source routing device (also referred to as the ingress PE 
device). 
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Figure 77: MoFRR Sample Topology 
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With MoFRR enabled, the egress (receiver side) routing device sets up two multicast trees, a primary path 
and a backup path, toward the multicast source for each (S,G). In other words, the egress routing device 
propagates the same (S,G) join messages toward two different upstream neighbors, thus creating two 
multicast trees. 


One of the multicast trees goes through plane 1 and the other through plane 2, as shown in 
Figure 77 on page 947. For each (S,G), the egress routing device forwards traffic received on the primary 
path and drops traffic received on the backup path. 


MoFRR is supported on both equal-cost multipath (ECMP) paths and non-ECMP paths. The device needs 
to enable unicast loop-free alternate (LFA) routes to support MoFRR on non-ECMP paths. You enable LFA 
routes using the link-protection statement in the interior gateway protocol (IGP) configuration. When you 
enable link protection on an OSPF or IS-IS interface, the device creates a backup LFA path to the primary 
next hop for all destination routes that traverse the protected interface. 


Junos OS implements MoFRR in the IP network for IP MoFRR and at the MPLS label-edge routing device 
(LER) for multipoint LDP MoFRR. 


Multipoint LDP MoFRR is used at the egress device of an MPLS network, where the packets are forwarded 
to an IP network. With multipoint LDP MoFRR, the device establishes two paths toward the upstream PE 
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routing device for receiving two streams of MPLS packets at the LER. The device accepts one of the 
streams (the primary), and the other one (the backup) is dropped at the LER. IF the primary path fails, the 
device accepts the backup stream instead. Inband signaling support is a prerequisite for MoFRR with 
multipoint LDP (see “Understanding Multipoint LDP Inband Signaling for Point-to-Multipoint LSPs” on 
page 1003). 


PIM Functionality 


Junos OS supports MoFRR for shortest-path tree (SPT) joins in PIM source-specific multicast (SSM) and 
any-source multicast (ASM). MoFRR is supported for both SSM and ASM ranges. To enable MoFRR for 
(*,G) joins, include the mofrr-asm-starg configuration statement at the [edit routing-options multicast 
stream-protection] hierarchy. For each group G, MoFRR will operate for either (S,G) or (*,G), but not both. 
(S,G) always takes precedence over (*,G). 


With MoFRR enabled, a PIM routing device propagates join messages on two upstream reverse-path 
forwarding (RPF) interfaces to receive multicast traffic on both links for the same join request. MoFRR 
gives preference to two paths that do not converge to the same immediate upstream routing device. PIM 
installs appropriate multicast routes with upstream RPF next hops with two interfaces (for the primary 
and backup paths). 


When the primary path fails, the backup path is upgraded to primary status, and the device forwards traffic 
accordingly. If there are alternate paths available, MoFRR calculates a new backup path and updates or 
installs the appropriate multicast route. 


You can enable MoFRR with PIM join load balancing (see the join-load-balance automatic statement). 
However, in that case the distribution of join messages among the links might not be even. When a new 
ECMP link is added, join messages on the primary path are redistributed and load-balanced. The join 
messages on the backup path might still follow the same path and might not be evenly redistributed. 


You enable MoFRR using the stream-protection configuration statement at the [edit routing-options 
multicast] hierarchy. MoFRR is managed by a set of filter policies. 


When an egress PIM routing device receives a join message or an IGMP report, it checks for an MoFRR 
configuration and proceeds as follows: 


If the MoFRR configuration is not present, PIM sends a join message upstream toward one upstream 
neighbor (for example, plane 2 in Figure 77 on page 947). 


If the MoFRR configuration is present, the device checks for a policy configuration. 


If a policy is not present, the device checks for primary and backup paths (upstream interfaces), and 
proceeds as follows: 


e If primary and backup paths are not available—PIM sends a join message upstream toward one upstream 
neighbor (for example, plane 2 in Figure 77 on page 947). 


e If primary and backup paths are available—PIM sends the join message upstream toward two of the 
available upstream neighbors. Junos OS sets up primary and secondary multicast paths to receive 
multicast traffic (for example, plane 1 in Figure 77 on page 947). 


e If a policy is present, the device checks whether the policy allows MoFRR for this (S,G), and proceeds 
as follows: 


e If this policy check fails—PIM sends a join message upstream toward one upstream neighbor (for 
example, plane 2 in Figure 77 on page 947). 


e If this policy check passes—The device checks for primary and backup paths (upstream interfaces). 


e If the primary and backup paths are not available, PIM sends a join message upstream toward one 
upstream neighbor (for example, plane 2 in Figure 77 on page 947). 


e If the primary and backup paths are available, PIM sends the join message upstream toward two of 
the available upstream neighbors. The device sets up primary and secondary multicast paths to 
receive multicast traffic (for example, plane 1 in Figure 77 on page 947). 


Multipoint LDP Functionality 


To avoid MPLS traffic duplication, multipoint LDP usually selects only one upstream path. (See section 
2.4.1.1. Determining One's 'upstream LSR' in RFC 6388, Label Distribution Protocol Extensions for 
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths.) 


For multipoint LDP with MoFRR, the multipoint LDP device selects two separate upstream peers and 
sends two separate labels, one to each upstream peer. The device uses the same algorithm described in 
RFC 6388 to select the primary upstream path. The device uses the same algorithm to select the backup 
upstream path but excludes the primary upstream LSR as a candidate. The two different upstream peers 
send two streams of MPLS traffic to the egress routing device. The device selects only one of the upstream 
neighbor paths as the primary path from which to accept the MPLS traffic. The other path becomes the 
backup path, and the device drops that traffic. When the primary upstream path fails, the device starts 
accepting traffic from the backup path. The multipoint LDP device selects the two upstream paths based 
on the interior gateway protocol (IGP) root device next hop. 


A forwarding equivalency class (FEC) is a group of IP packets that are forwarded in the same manner, over 
the same path, and with the same forwarding treatment. Normally, the label that is put on a particular 
packet represents the FEC to which that packet is assigned. In MoFRR, two routes are placed into the 
mpls.O table for each FEC—one route for the primary label and the other route for the backup label. 


If there are parallel links toward the same immediate upstream device, the device considers both parallel 
links to be the primary. At any point in time, the upstream device sends traffic on only one of the multiple 
parallel links. 


A bud node is an LSR that is an egress LSR, but also has one or more directly connected downstream LSRs. 
For a bud node, the traffic from the primary upstream path is forwarded to a downstream LSR. If the 
primary upstream path fails, the MPLS traffic from the backup upstream path is forwarded to the 
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downstream LSR. This means that the downstream LSR next hop is added to both MPLS routes along with 
the egress next hop. 


As with PIM, you enable MoFRR with multipoint LDP using the stream-protection configuration statement 
at the [edit routing-options multicast] hierarchy, and it’s managed by a set of filter policies. 


If you have enabled the multipoint LDP point-to-multipoint FEC for MoFRR, the device factors the following 
considerations into selecting the upstream path: 


e The targeted LDP sessions are skipped if there is a nontargeted LDP session. If there is a single targeted 
LDP session, the targeted LDP session is selected, but the corresponding point-to-multipoint FEC loses 
the MoFRR capability because there is no interface associated with the targeted LDP session. 


e All interfaces that belong to the same upstream LSR are considered to be the primary path. 
e For any root-node route updates, the upstream path is changed based on the latest next hops from the 


IGP. If a better path is available, multipoint LDP attempts to switch to the better path. 


Packet Forwarding 
For either PIM or multipoint LDP, the device performs multicast source stream selection at the ingress 
interface. This preserves fabric bandwidth and maximizes forwarding performance because it: 


e Avoids sending out duplicate streams across the fabric 


e Prevents multiple route lookups (that result in packet drops). 


For PIM, each IP multicast stream contains the same destination address. Regardless of the interface on 
which the packets arrive, the packets have the same route. The device checks the interface upon which 
each packet arrives and forwards only those that are from the primary interface. If the interface matches 
a backup stream interface, the device drops the packets. If the interface doesn’t match either the primary 
or backup stream interface, the device handles the packets as exceptions in the control plane. 


Figure 78 on page 950 shows this process with sample primary and backup interfaces for routers with PIM. 
Figure 79 on page 951 shows this similarly for switches with PIM. 


Figure 78: MoFRR IP Route Lookup in the Packet Forwarding Engine on Routers 
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Figure 79: MoFRR IP Route Handling in the Packet Forwarding Engine on Switches 
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For MoFRR with multipoint LDP on routers, the device uses multiple MPLS labels to control MoFRR stream 
selection. Each label represents a separate route, but each references the same interface list check. The 
device only forwards the primary label, and drops all others. Multiple interfaces can receive packets using 


the same label. 


Figure 80 on page 951 shows this process for routers with multipoint LDP. 


Figure 80: MoFRR MPLS Route Lookup in the Packet Forwarding Engine 
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MoFRR Limitations and Caveats on Switching and Routing Devices 


MoFRR has the following limitations and caveats on routing and switching devices: 


MoFRR failure detection is supported for immediate link protection of the routing device on which 
MoFRR is enabled and not on all the links (end-to-end) in the multicast traffic path. 


MoFRR supports fast reroute on two selected disjoint paths toward the source. Two of the selected 
upstream neighbors cannot be on the same interface—in other words, two upstream neighbors on a LAN 
segment. The same is true if the upstream interface happens to be a multicast tunnel interface. 


Detection of the maximum end-to-end disjoint upstream paths is not supported. The receiver side (egress) 
routing device only makes sure that there is a disjoint upstream device (the immediate previous hop). 
PIM and multipoint LDP do not support the equivalent of explicit route objects (EROs). Hence, disjoint 
upstream path detection is limited to control over the immediately previous hop device. Because of this 
limitation, the path to the upstream device of the previous hop selected as primary and backup might 
be shared. 


You might see some traffic loss in the following scenarios: 
e A better upstream path becomes available on an egress device. 


e MoFRR is enabled or disabled on the egress device while there is an active traffic stream flowing. 


PIM join load balancing for join messages for backup paths are not supported. 


For a multicast group G, MoFRR is not allowed for both (S,G) and (*,G) join messages. (S,G) join messages 
have precedence over (*,G). 


MoEFRR is not supported for multicast traffic streams that use two different multicast groups. Each (S,G) 
combination is treated as a unique multicast traffic stream. 


The bidirectional PIM range is not supported with MoFRR. 
PIM dense-mode is not supported with MoFRR. 


Multicast statistics for the backup traffic stream are not maintained by PIM and therefore are not available 
in the operational output of show commands. 


Rate monitoring is not supported. 


MoFRR Limitations on Switching Devices with PIM 


MoFRR with PIM has the following limitations on switching devices: 


MoFRR is not supported when the upstream interface is an integrated routing and bridging (IRB) interface, 
which impacts other multicast features such as Internet Group Management Protocol version 3 (IGMPv3) 
snooping. 


Packet replication and multicast lookups while forwarding multicast traffic can cause packets to recirculate 
through PFEs multiple times. As a result, displayed values for multicast packet counts from the show 
pfe statistics traffic command might show higher numbers than expected in output fields such as Input 
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packets and Output packets. You might notice this behavior more frequently in MoFRR scenarios because 
duplicate primary and backup streams increase the traffic flow in general. 


MoFRR Limitations and Caveats on Routing Devices with Multipoint LDP 


MoFRR has the following limitations and caveats on routers when used with multipoint LDP: 


e MoFRR does not apply to multipoint LDP traffic received on an RSVP tunnel because the RSVP tunnel 
is not associated with any interface. 


Mixed upstream MoFRR is not supported. This refers to PIM multipoint LDP in-band signaling, wherein 
one upstream path is through multipoint LDP and the second upstream path is through PIM. 


Multipoint LDP labels as inner labels are not supported. 


e If the source is reachable through multiple ingress (source-side) provider edge (PE) routing devices, 
multipoint LDP MoFRR is not supported. 


e Targeted LDP upstream sessions are not selected as the upstream device for MoFRR. 


Multipoint LDP link protection on the backup path is not supported because there is no support for 
MoFRR inner labels. 


Configuring Multicast-Only Fast Reroute 


You can configure multicast-only fast reroute (MoFRR) to minimize packet loss in a network when there 
is a link failure. 


When fast reroute is applied to unicast streams, an upstream router preestablishes MPLS label-switched 
paths (LSPs) or precomputes an IP loop-free alternate (LFA) fast reroute backup path to handle failure of 
a segment in the downstream path. 


In multicast routing, the traffic distribution graphs are usually originated by the receiver. This is unlike 
unicast routing, which usually establishes the path from the source to the receiver. Protocols that are 
capable of establishing multicast distribution graphs are PIM (for IP), multipoint LDP (for MPLS) and 
RSVP-TE (for MPLS). Of these, PIM and multipoint LDP receivers initiate the distribution graph setup, and 
therefore: 


e On the QFX series, MoFRR is supported in PIM domains. 


e On the MX Series and SRX Series, MoFRR is supported in PIM and multipoint LDP domains. 


The configuration steps are the same for enabling MoFRR for PIM on all devices that support this feature, 
unless otherwise indicated. Configuration steps that are not applicable to multipoint LDP MoFRR are also 
indicated. 


(For MX Series routers only) MoFRR is supported on MX Series routers with MPC line cards. As a 
prerequisite,all the line cards in the router must be MPCs. 
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To configure MoFRR on routers or switches: 


1. (For MX Series and SRX Series routers only) Set the router to enhanced IP mode. 


[edit chassis] 
user@host# set network-services enhanced-ip 


2. Enable MoFRR. 


[edit routing-options multicast] 
user@host# set stream-protection 


3. (Optional) Configure a routing policy that filters for a restricted set of multicast streams to be affected 
by your MoFRR configuration. 


You can apply filters that are based on source or group addresses. 


For example: 


[edit policy-options] 
policy-statement mofrr-select { 
term A { 
from { 
source-address-filter 225.1.1.1/32 exact; 
} 
then { 
accept; 


} 
term B { 
from { 
source-address-filter 226.0.0.0/8 orlonger; 
} 
then { 
accept; 


} 
term C { 
from { 
source-address-filter 227.1.1.0/24 orlonger; 
source-address-filter 227.4.1.0/24 orlonger; 
source-address-filter 227.16.1.0/24 orlonger; 
} 
then { 
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accept; 


} 
term D { 
from { 
source-address-filter 227.1.1.1/32 exact 


} 
then { 
reject; #MoFRR disabled 


4. (Optional) If you configured a routing policy to filter the set of multicast groups to be affected by your 
MoFRR configuration, apply the policy for MoFRR stream protection. 


[edit routing-options multicast stream-protection] 
user@host# set policy policy-name 


For example: 


routing-options { 
multicast { 
stream-protection { 
policy mofrr-select 


5. (Optional) In a PIM domain with MoFRR, allow MoFRR to be applied to any-source multicast (ASM) 
(*,G) joins. 


This is not supported for multipoint LDP MoFRR. 


[edit routing-options multicast stream-protection] 
user@host# set mofrr-asm-starg 


6. (Optional) In a PIM domain with MoFRR, allow only a disjoint RPF (an RPF on a separate plane) to be 
selected as the backup RPF path. 
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This is not supported for multipoint LDP MoFRR. In a multipoint LDP MoFRR domain, the same label 
is shared between parallel links to the same upstream neighbor. This is not the case in a PIM domain, 
where each link forms a neighbor. The mofrr-disjoint-upstream-only statement does not allow a backup 
RPF path to be selected if the path goes to the same upstream neighbor as that of the primary RPF 

path. This ensures that MoFRR is triggered only on a topology that has multiple RPF upstream neighbors. 


[edit routing-options multicast stream-protection] 
user@host# set mofrr-disjoint-upstream-only 


7. (Optional) In a PIM domain with MoFRR, prevent sending join messages on the backup path, but retain 
all other MoFRR functionality. 


This is not supported for multipoint LDP MoFRR. 


[edit routing-options multicast stream-protection] 
user@host# set mofrr-no-backup-join 


8. (Optional) In a PIM domain with MoFRR, allow new primary path selection to be based on the unicast 
gateway selection for the unicast route to the source and to change when there is a change in the 
unicast selection, rather than having the backup path be promoted as primary. This ensures that the 
primary RPF hop is always on the best path. 


When you include the mofrr-primary-selection-by-routing statement, the backup path is not guaranteed 
to get promoted to be the new primary path when the primary path goes down. 


This is not supported for multipoint LDP MoFRR. 


[edit routing-options multicast stream-protection] 
user@host# set mofrr-primary-path-selection-by-routing 


Example: Configuring Multicast-Only Fast Reroute in a Multipoint LDP Domain 
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This example shows how to configure multicast-only fast reroute (MoFRR) to minimize packet loss in a 
network when there is a link failure. 


Multipoint LDP MoFRR is used at the egress node of an MPLS network, where the packets are forwarded 
to an IP network. In the case of multipoint LDP MoFRR, the two paths toward the upstream provider edge 
(PE) router are established for receiving two streams of MPLS packets at the label-edge router (LER). One 
of the streams (the primary) is accepted, and the other one (the backup) is dropped at the LER. The backup 
stream is accepted if the primary path fails. 

Requirements 


No special configuration beyond device initialization is required before configuring this example. 


Ina multipoint LDP domain, for MoFRR to work, only the egress PE router needs to have MoFRR enabled. 
The other routers do not need to support MoFRR. 


MoFRR is supported on MX Series platforms with MPC line cards. As a prerequisite, the router must be 
set to network-services enhanced-ip mode, and all the line-cards in the platform must be MPCs. 


This example requires Junos OS Release 14.1 or later on the egress PE router. 


Overview 


In this example, Device R3 is the egress edge router. MoFRR is enabled on this device only. 
OSPF is used for connectivity, though any interior gateway protocol (IGP) or static routes can be used. 


For testing purposes, routers are used to simulate the source and the receiver. Device R4 and Device R8 
are configured to statically join the desired group by using the set protocols igmp interface interface-name 
static group group command. In the case when a real multicast receiver host is not available, as in this 
example, this static IGMP configuration is useful. On the receivers, to make them listen to the multicast 
group address, this example uses set protocols sap listen group. 


MoFRR configuration includes a policy option that is not shown in this example, but is explained separately. 


The option is configured as follows: 


stream-protection { 
policy policy-name; 


Topology 


Figure 81 on page 958 shows the sample network. 
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Figure 81: MoFRR in a Multipoint LDP Domain 
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“CLI Quick Configuration” on page 958 shows the configuration for all of the devices in Figure 81 on page 958. 


The section “Configuration” on page 966 describes the steps on Device R3. 


CLI Quick Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


Device src1 


set interfaces ge-1/2/10 unit 0 description src1-to-R1 

set interfaces ge-1/2/10 unit 0 family inet address 1.1.0.1/30 

set interfaces ge-1/2/11 unit 0 description src1-to-R1 

set interfaces ge-1/2/11 unit 0 family inet address 192.168.219.11/24 
set interfaces loO unit O family inet address 1.1.1.17/32 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 


Device src2 
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set interfaces ge-1/2/24 unit 0 description src2-to-R5 

set interfaces ge-1/2/24 unit 0 family inet address 1.5.0.2/30 
set interfaces loO unit O family inet address 1.1.1.18/32 

set protocols rsvp interface all 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 


Device R1 


set interfaces ge-1/2/12 unit 0 description R1-to-R2 

set interfaces ge-1/2/12 unit 0 family inet address 1.1.2.1/30 
set interfaces ge-1/2/12 unit 0 family mpls 

set interfaces ge-1/2/13 unit 0 description R1-to-R6 

set interfaces ge-1/2/13 unit 0 family inet address 1.1.6.1/30 
set interfaces ge-1/2/13 unit 0 family mpls 

set interfaces ge-1/2/10 unit 0 description R1-to-src1 

set interfaces ge-1/2/10 unit 0 family inet address 1.1.0.2/30 
set interfaces ge-1/2/11 unit 0 description R1-to-src1 

set interfaces ge-1/2/11 unit 0 family inet address 192.168.219.9/30 
set interfaces loO unit O family inet address 1.1.1.1/32 

set protocols rsvp interface all 

set protocols mpls interface all 

set protocols bgp group ibgp local-address 1.1.1.1 

set protocols bgp group ibgp export static-route-tobgp 

set protocols bgp group ibgp peer-as 10 

set protocols bgp group ibgp neighbor 1.1.1.3 

set protocols bgp group ibgp neighbor 1.1.1.7 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols Idp interface ge-1/2/12.0 

set protocols Idp interface ge-1/2/13.0 

set protocols Idp interface lo0.0 

set protocols Idp p2mp 

set protocols pim mldp-inband-signalling policy mldppim-ex 
set protocols pim rp static address 1.1.1.5 

set protocols pim interface lo0.0 

set protocols pim interface ge-1/2/10.0 

set protocols pim interface ge-1/2/11.0 
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set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 
orlonger 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 
orlonger 

set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 1.1.1.2 

set policy-options policy-statement mldppim-ex term B then accept 

set policy-options policy-statement mldppim-ex term A from source-address-filter 1.1.1.7/32 orlonger 

set policy-options policy-statement mldppim-ex term A from source-address-filter 1.1.0.0/30 orlonger 

set policy-options policy-statement mldppim-ex term A then accept 

set policy-options policy-statement static-route-tobgp term static from protocol static 

set policy-options policy-statement static-route-tobgp term static from protocol direct 

set policy-options policy-statement static-route-tobgp term static then accept 

set routing-options autonomous-system 10 


Device R2 


set interfaces ge-1/2/12 unit 0 description R2-to-R1 

set interfaces ge-1/2/12 unit 0 family inet address 1.1.2.2/30 
set interfaces ge-1/2/12 unit 0 family mpls 

set interfaces ge-1/2/14 unit 0 description R2-to-R3 

set interfaces ge-1/2/14 unit 0 family inet address 1.2.3.1/30 
set interfaces ge-1/2/14 unit 0 family mpls 

set interfaces ge-1/2/16 unit 0 description R2-to-R5 

set interfaces ge-1/2/16 unit 0 family inet address 1.2.5.1/30 
set interfaces ge-1/2/16 unit 0 family mpls 

set interfaces ge-1/2/17 unit 0 description R2-to-R7 

set interfaces ge-1/2/17 unit 0 family inet address 1.2.7.1/30 
set interfaces ge-1/2/17 unit 0 family mpls 

set interfaces ge-1/2/15 unit 0 description R2-to-R3 

set interfaces ge-1/2/15 unit 0 family inet address 1.2.94.1/30 
set interfaces ge-1/2/15 unit 0 family mpls 

set interfaces loO unit O family inet address 1.1.1.2/32 

set interfaces loO unit O family mpls 

set protocols rsvp interface all 

set protocols mpls interface all 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols Idp interface all 

set protocols Idp p2mp 
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set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 
orlonger 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 
orlonger 

set policy-options policy-statement mldppim-ex term B then p2mp-Isp-root address 1.1.1.2 

set policy-options policy-statement mldppim-ex term B then accept 

set routing-options autonomous-system 10 


Device R3 


set chassis network-services enhanced-ip 

set interfaces ge-1/2/14 unit 0 description R3-to-R2 

set interfaces ge-1/2/14 unit 0 family inet address 1.2.3.2/30 
set interfaces ge-1/2/14 unit 0 family mpls 

set interfaces ge-1/2/18 unit 0 description R3-to-R4 

set interfaces ge-1/2/18 unit 0 family inet address 1.3.4.1/30 
set interfaces ge-1/2/18 unit 0 family mpls 

set interfaces ge-1/2/19 unit 0 description R3-to-R6 

set interfaces ge-1/2/19 unit 0 family inet address 1.3.6.2/30 
set interfaces ge-1/2/19 unit 0 family mpls 

set interfaces ge-1/2/21 unit 0 description R3-to-R7 

set interfaces ge-1/2/21 unit 0 family inet address 1.3.7.1/30 
set interfaces ge-1/2/21 unit 0 family mpls 

set interfaces ge-1/2/22 unit 0 description R3-to-R8 

set interfaces ge-1/2/22 unit 0 family inet address 1.3.8.1/30 
set interfaces ge-1/2/22 unit 0 family mpls 

set interfaces ge-1/2/15 unit 0 description R3-to-R2 

set interfaces ge-1/2/15 unit 0 family inet address 1.2.94.2/30 
set interfaces ge-1/2/15 unit 0 family mpls 

set interfaces ge-1/2/20 unit 0 description R3-to-R6 

set interfaces ge-1/2/20 unit 0 family inet address 1.2.96.2/30 
set interfaces ge-1/2/20 unit 0 family mpls 

set interfaces loO unit O family inet address 1.1.1.3/32 primary 
set routing-options autonomous-system 10 

set routing-options multicast stream-protection 

set protocols rsvp interface all 

set protocols mpls interface all 

set protocols bgp group ibgp local-address 1.1.1.3 

set protocols bgp group ibgp peer-as 10 

set protocols bgp group ibgp neighbor 1.1.1.1 
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set protocols bgp group ibgp neighbor 1.1.1.5 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols Idp interface all 

set protocols Idp p2mp 

set protocols pim mldp-inband-signalling policy mldppim-ex 

set protocols pim interface lo0.0 

set protocols pim interface ge-1/2/18.0 

set protocols pim interface ge-1/2/22.0 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 
orlonger 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 
orlonger 

set policy-options policy-statement mldppim-ex term B then accept 

set policy-options policy-statement mldppim-ex term A from source-address-filter 1.1.0.1/30 orlonger 

set policy-options policy-statement mldppim-ex term A then accept 

set policy-options policy-statement static-route-tobgp term static from protocol static 

set policy-options policy-statement static-route-tobgp term static from protocol direct 

set policy-options policy-statement static-route-tobgp term static then accept 


Device R4 


set interfaces ge-1/2/18 unit 0 description R4-to-R3 

set interfaces ge-1/2/18 unit 0 family inet address 1.3.4.2/30 

set interfaces ge-1/2/18 unit 0 family mpls 

set interfaces ge-1/2/23 unit 0 description R4-to-R7 

set interfaces ge-1/2/23 unit 0 family inet address 1.4.7.1/30 

set interfaces loO unit O family inet address 1.1.1.4/32 

set protocols igmp interface ge-1/2/18.0 version 3 

set protocols igmp interface ge-1/2/18.0 static group 232.1.1.1 group-count 2 
set protocols igmp interface ge-1/2/18.0 static group 232.1.1.1 source 192.168.219.11 
set protocols igmp interface ge-1/2/18.0 static group 232.2.2.2 source 1.2.7.7 
set protocols sap listen 232.1.1.1 

set protocols sap listen 232.2.2.2 

set protocols rsvp interface all 

set protocols mpls interface all 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 
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set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols pim mldp-inband-signalling policy mldppim-ex 

set protocols pim interface ge-1/2/23.0 

set protocols pim interface ge-1/2/18.0 

set protocols pim interface lo0.0 

set policy-options policy-statement static-route-tobgp term static from protocol static 

set policy-options policy-statement static-route-tobgp term static from protocol direct 

set policy-options policy-statement static-route-tobgp term static then accept 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 
orlonger 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 
orlonger 

set policy-options policy-statement mldppim-ex term B then p2mp-Isp-root address 1.1.1.2 

set policy-options policy-statement mldppim-ex term B then accept 

set routing-options autonomous-system 10 


Device R5 


set interfaces ge-1/2/24 unit 0 description R5-to-src2 

set interfaces ge-1/2/24 unit 0 family inet address 1.5.0.1/30 
set interfaces ge-1/2/16 unit 0 description R5-to-R2 

set interfaces ge-1/2/16 unit 0 family inet address 1.2.5.2/30 
set interfaces ge-1/2/16 unit 0 family mpls 

set interfaces ge-1/2/25 unit 0 description R5-to-R6 

set interfaces ge-1/2/25 unit 0 family inet address 1.5.6.1/30 
set interfaces ge-1/2/25 unit 0 family mpls 

set interfaces loO unit O family inet address 1.1.1.5/32 

set protocols rsvp interface all 

set protocols mpls interface all 

set protocols bgp group ibgp local-address 1.1.1.5 

set protocols bgp group ibgp export static-route-tobgp 

set protocols bgp group ibgp peer-as 10 

set protocols bgp group ibgp neighbor 1.1.1.7 

set protocols bgp group ibgp neighbor 1.1.1.3 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols Idp interface ge-1/2/16.0 

set protocols Idp interface ge-1/2/25.0 

set protocols Idp p2mp 
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set protocols pim interface lo0.0 

set protocols pim interface ge-1/2/24.0 

set policy-options policy-statement static-route-tobgp term static from protocol static 
set policy-options policy-statement static-route-tobgp term static from protocol direct 
set policy-options policy-statement static-route-tobgp term static then accept 

set routing-options autonomous-system 10 


Device R6 


set interfaces ge-1/2/13 unit 0 description R6-to-R1 

set interfaces ge-1/2/13 unit 0 family inet address 1.1.6.2/30 
set interfaces ge-1/2/13 unit 0 family mpls 

set interfaces ge-1/2/19 unit 0 description R6-to-R3 

set interfaces ge-1/2/19 unit 0 family inet address 1.3.6.1/30 
set interfaces ge-1/2/19 unit 0 family mpls 

set interfaces ge-1/2/25 unit 0 description R6-to-R5 

set interfaces ge-1/2/25 unit 0 family inet address 1.5.6.2/30 
set interfaces ge-1/2/25 unit 0 family mpls 

set interfaces ge-1/2/26 unit 0 description R6-to-R7 

set interfaces ge-1/2/26 unit 0 family inet address 1.6.7.1/30 
set interfaces ge-1/2/26 unit 0 family mpls 

set interfaces ge-1/2/20 unit 0 description R6-to-R3 

set interfaces ge-1/2/20 unit 0 family inet address 1.2.96.1/30 
set interfaces ge-1/2/20 unit 0 family mpls 

set interfaces loO unit O family inet address 1.1.1.6/30 

set protocols rsvp interface all 

set protocols mpls interface all 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols Idp interface all 

set protocols Idp p2mp 


Device R7 


set interfaces ge-1/2/17 unit 0 description R7-to-R2 
set interfaces ge-1/2/17 unit 0 family inet address 1.2.7.2/30 


set interfaces ge-1/2/17 unit 0 family mpls 

set interfaces ge-1/2/21 unit 0 description R7-to-R3 

set interfaces ge-1/2/21 unit 0 family inet address 1.3.7.2/30 

set interfaces ge-1/2/21 unit 0 family mpls 

set interfaces ge-1/2/23 unit 0 description R7-to-R4 

set interfaces ge-1/2/23 unit 0 family inet address 1.4.7.2/30 

set interfaces ge-1/2/23 unit 0 family mpls 

set interfaces ge-1/2/26 unit 0 description R7-to-R6 

set interfaces ge-1/2/26 unit 0 family inet address 1.6.7.2/30 

set interfaces ge-1/2/26 unit 0 family mpls 

set interfaces ge-1/2/27 unit 0 description R7-to-R8 

set interfaces ge-1/2/27 unit 0 family inet address 1.7.8.1/30 

set interfaces ge-1/2/27 unit 0 family mpls 

set interfaces loO unit O family inet address 1.1.1.7/32 

set protocols rsvp interface all 

set protocols mpls interface all 

set protocols bgp group ibgp local-address 1.1.1.7 

set protocols bgp group ibgp export static-route-tobgp 

set protocols bgp group ibgp peer-as 10 

set protocols bgp group ibgp neighbor 1.1.1.5 

set protocols bgp group ibgp neighbor 1.1.1.1 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols Idp interface ge-1/2/17.0 

set protocols Idp interface ge-1/2/21.0 

set protocols Idp interface ge-1/2/26.0 

set protocols Idp p2mp 

set protocols pim mldp-inband-signalling policy mldppim-ex 

set protocols pim interface lo0.0 

set protocols pim interface ge-1/2/27.0 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 
orlonger 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 
orlonger 

set policy-options policy-statement mldppim-ex term B then accept 

set policy-options policy-statement mldppim-ex term A from source-address-filter 1.1.0.1/30 orlonger 

set policy-options policy-statement mldppim-ex term A then accept 

set policy-options policy-statement static-route-tobgp term static from protocol static 

set policy-options policy-statement static-route-tobgp term static from protocol direct 

set policy-options policy-statement static-route-tobgp term static then accept 

set routing-options autonomous-system 10 
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set routing-options multicast stream-protection policy mldppim-ex 


Device R8 


set interfaces ge-1/2/22 unit 0 description R8-to-R3 

set interfaces ge-1/2/22 unit 0 family inet address 1.3.8.2/30 

set interfaces ge-1/2/22 unit 0 family mpls 

set interfaces ge-1/2/27 unit 0 description R8-to-R7 

set interfaces ge-1/2/27 unit 0 family inet address 1.7.8.2/30 

set interfaces ge-1/2/27 unit 0 family mpls 

set interfaces loO unit O family inet address 1.1.1.8/32 

set protocols igmp interface ge-1/2/22.0 version 3 

set protocols igmp interface ge-1/2/22.0 static group 232.1.1.1 group-count 2 

set protocols igmp interface ge-1/2/22.0 static group 232.1.1.1 source 192.168.219.11 

set protocols igmp interface ge-1/2/22.0 static group 232.2.2.2 source 1.2.7.7 

set protocols sap listen 232.1.1.1 

set protocols sap listen 232.2.2.2 

set protocols rsvp interface all 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols pim mldp-inband-signalling policy mldppim-ex 

set protocols pim interface ge-1/2/27.0 

set protocols pim interface ge-1/2/22.0 

set protocols pim interface lo0.0 

set policy-options policy-statement static-route-tobgp term static from protocol static 

set policy-options policy-statement static-route-tobgp term static from protocol direct 

set policy-options policy-statement static-route-tobgp term static then accept 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 
orlonger 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 
orlonger 

set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 1.1.1.2 

set policy-options policy-statement mldppim-ex term B then accept 

set routing-options autonomous-system 10 


Configuration 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 


information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device R3: 


1. Enable enhanced IP mode. 


[edit chassis] 
user@R3# set network-services enhanced-ip 


2. Configure the device interfaces. 


[edit interfaces] 

user@R3# set ge-1/2/14 unit 0 description R3-to-R2 
user@R3# set ge-1/2/14 unit 0 family inet address 1.2.3.2/30 
user@R3# set ge-1/2/14 unit 0 family mpls 

user@R3# set ge-1/2/18 unit 0 description R3-to-R4 
user@R3# set ge-1/2/18 unit 0 family inet address 1.3.4.1/30 
user@R3# set ge-1/2/18 unit 0 family mpls 

user@R3# set ge-1/2/19 unit 0 description R3-to-R6 
user@R3# set ge-1/2/19 unit O family inet address 1.3.6.2/30 
user@R3# set ge-1/2/19 unit O family mpls 

user@R3# set ge-1/2/21 unit 0 description R3-to-R7 
user@R3# set ge-1/2/21 unit 0 family inet address 1.3.7.1/30 
user@R3# set ge-1/2/21 unit 0 family mpls 

user@R3# set ge-1/2/22 unit 0 description R3-to-R8 
user@R3# set ge-1/2/22 unit 0 family inet address 1.3.8.1/30 
user@R3# set ge-1/2/22 unit 0 family mpls 

user@R3# set ge-1/2/15 unit 0 description R3-to-R2 
user@R3# set ge-1/2/15 unit 0 family inet address 1.2.94.2/30 
user@R3# set ge-1/2/15 unit 0 family mpls 

user@R3# set ge-1/2/20 unit 0 description R3-to-R6 
user@R3# set ge-1/2/20 unit O family inet address 1.2.96.2/30 
user@R3# set ge-1/2/20 unit 0 family mpls 

user@R3# set loO unit O family inet address 1.1.1.3/32 primary 


3. Configure the autonomous system (AS) number. 


user@R3# set routing-options autonomous-system 10 


4. Configure the routing policies. 
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[edit policy-options policy-statement mldppim-ex] 

user@R3# set term B from source-address-filter 192.168.0.0/24 orlonger 
user@R3# set term B from source-address-filter 192.168.219.11/32 orlonger 
user@R3# set term B then accept 

user@R3# set term A from source-address-filter 1.1.0.1/30 orlonger 
user@R3# set term A then accept 

[edit policy-options policy-statement static-route-tobgp] 

user@R3# set term static from protocol static 

user@R3# set term static from protocol direct 

user@R3# set term static then accept 


5. Configure PIM. 


[edit protocols pim] 

user@R3# set mldp-inband-signalling policy mldppim-ex 
user@R3# set interface lo0.0 

user@R3# set interface ge-1/2/18.0 

user@R3# set interface ge-1/2/22.0 


6. Configure LDP. 


[edit protocols Idp] 
user@R3# set interface all 
user@R3# set p2mp 


7. Configure an IGP or static routes. 


[edit protocols ospf] 

user@R3# set traffic-engineering 

user@R3# set area 0.0.0.0 interface all 

user@R3# set area 0.0.0.0 interface fxp0.0 disable 
user@R3# set area 0.0.0.0 interface lo0.0 passive 


8. Configure internal BGP. 


[edit protocols bgp group ibgp] 
user@R3# set local-address 1.1.1.3 
user@R3# set peer-as 10 
user@R3# set neighbor 1.1.1.1 
user@R3# set neighbor 1.1.1.5 
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9. Configure MPLS and, optionally, RSVP. 


[edit protocols mpls] 
user@R3# set interface all 
[edit protocols rsvp] 
user@R3# set interface all 


10. Enable MoFRR. 


[edit routing-options multicast] 
user@R3# set stream-protection 


Results 


From configuration mode, confirm your configuration by entering the show chassis, show interfaces, show 
protocols, show policy-options, and show routing-options commands. If the output does not display the 
intended configuration, repeat the instructions in this example to correct the configuration. 


user@R3# show chassis 
network-services enhanced-ip; 


user@R3# show interfaces 
ge-1/2/14 { 
unit O { 
description R3-to-R2; 
family inet { 
address 1.2.3.2/30; 
} 


family mpls; 


} 
ge-1/2/18 { 
unit O { 
description R3-to-R4; 
family inet { 
address 1.3.4.1/30; 
} 


family mpls; 


} 
ge-1/2/19 { 
unit O { 


description R3-to-R6; 
family inet { 

address 1.3.6.2/30; 
} 


family mpls; 


} 
ge-1/2/21 { 
unit O { 
description R3-to-R7; 
family inet { 
address 1.3.7.1/30; 
} 


family mpls; 


} 
ge-1/2/22 { 
unit O { 
description R3-to-R8; 
family inet { 
address 1.3.8.1/30; 
} 


family mpls; 


} 
ge-1/2/15 { 
unit O { 
description R3-to-R2; 
family inet { 
address 1.2.94.2/30; 
} 


family mpls; 


} 
ge-1/2/20 { 
unit O { 
description R3-to-Ré6; 
family inet { 
address 1.2.96.2/30; 
} 


family mpls; 


loO { 
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unit O { 
family inet { 
address 192.168.15.1/32; 
address 1.1.1.3/32 { 
primary; 


user@R3# show protocols 
rsvp { 
interface all; 
} 
mpls { 
interface all; 
} 
bgp { 
group ibgp { 
local-address 1.1.1.3; 
peer-as 10; 
neighbor 1.1.1.1; 
neighbor 1.1.1.5; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 
} 
interface 100.0 { 


passive; 


} 

Idp { 
interface all; 
p2mp; 

} 

pim { 
mldp-inband-signalling { 

policy mldppim-ex; 
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} 


interface 100.0; 
interface ge-1/2/18.0; 
interface ge-1/2/22.0; 


user@R3# show policy-options 
policy-statement mldppim-ex { 
term B { 
from { 
source-address-filter 192.168.0.0/24 orlonger; 
source-address-filter 192.168.219.11/32 orlonger; 
} 
then accept; 
} 
term A { 
from { 
source-address-filter 1.1.0.1/30 orlonger; 
} 


then accept; 


} 
policy-statement static-route-tobgp { 
term static { 
from protocol [ static direct ]; 
then accept; 


user@R3# show routing-options 
autonomous-system 10; 
multicast { 

stream-protection; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


@ = Checking the LDP Point-to-Multipoint Forwarding Equivalency Classes | 973 


@ Examining the Label Information | 973 
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@ = Checking the Multicast Routes | 975 
@ ~~ Checking the LDP Point-to-Multipoint Traffic Statistics | 977 


Confirm that the configuration is working properly. 


Checking the LDP Point-to-Multipoint Forwarding Equivalency Classes 


Purpose 


Make sure the MoFRR is enabled, and determine what labels are being used. 


Action 


user@R3> show Idp p2mp fec 


DP SP 2VMP SEE es. 
PAMP wooc—ecele I,il,lst, omos 23Zololo.1, sees LY2 168,219.11 
MoFRR enabled 








Fec type: Egress (Active) 

Label: 301568 

RAMP root=—acicle I,il,lot, @mos 2ZS2,1o1.2, sree 182,168 219.11 
MoFRR enabled 





Fec type: Egress (Active) 
Label: 301600 


Meaning 


The output shows that MoFRR is enabled, and it shows that the labels 301568 and 301600 are being used 
for the two multipoint LDP point-to-multipoint LSPs. 


Examining the Label Information 


Purpose 


Make sure that the egress device has two upstream interfaces for the multicast group join. 


Action 


user@R3> show route label 301568 detail 


mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 


301568 (1 entry, 
* LDP 


A) 2) 5 ALG ZL), dha 
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1 announced) 
Preference: 9 

Next hop type: Flood 
Address: 0x2735208 





Next—-hop reference count: 3 
Next hop type: Router, Next hop index: 1397 
Address: 0x2735d2c 





Next-hop reference count: 3 
Nese Ines I, 3.8.2 wia ce=—1/2/22 0 





Label operation: Pop 

Load balance label: None; 

Next hop type: Router, Next hop index: 1395 
Address: 0x2736290 





Next-hop reference count: 3 

este Incjsie U.S o4.,2 waa oe—/ 2/18. 0 

Label operation: Pop 

Load balance label: None; 

State: <Active Int AckRequest MulticastRPF> 
Local AS: 10 

Age: 54:05 Metric: 1 





Validation State: unverified 

WSIS ILD? 

Announcement bits (1): O-KRT 

AS path: I 

MACS loowincl t@ wellces PZM2 wooic—eckche Ili ,l,i, edges 222 -1l.il.l, ses 





Primary Upstream : 1.1.1.3:0--1.1.1.2:0 
RPF Nexthops : 
ge-1/2/15.0, 1.2.94.1, Label: 301568, weight: 0x1 
ge-1/2/14.0, 1.2.3.1, Label: 301568, weight: 0x1 
Backup Upstream : 1.1.1.3:0--1.1.1.6:0 
RPF Nexthops : 
ge-1/2/20.0, 1.2.96.1, Label: 301584, weight: Oxfffe 
ge-1/2/19.0, 1.3.6.1, Label: 301584, weight: Oxfffe 


user@R3> show route label 301600 detail 


mpls.0: 18 destinations, 18 routes (18 active, 0 holddown, 0 hidden) 


301600 (1 entry, 
* LDP 


1 announced) 
Preference: 9 


Next hop type: Flood 
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Address: 0x27356b4 





Next-hop reference count: 3 
Next hop type: Router, Next hop index: 1520 
Address: 0x27350£4 





Next-hop reference count: 3 

Nexic Incjoe 1.3.8.2 wie qe-l/2/22.0 

Label operation: Pop 

Load balance label: None; 

Next hop type: Router, Next hop index: 1481 
Address: 0x273645c 





Next-hop reference count: 3 

iNGsste Ingjos I,3.4.2 wie ge—1/2/i3.0 

Label operation: Pop 

Load balance label: None; 

State: <Active Int AckRequest MulticastRPF> 
Local AS: 1) 

Age: 54:25 Metric: 1 





Validation State: unverified 

TESIR ILD 

Announcement bits (1): O-KRT 

AS path: I 

IMHCS lx@uincl 6G woulicesy P2Mie wooe—eccle si sls,il, oigoe 2I2clelsa, Bees 





192, L6S 219,11 
Primary Upstream : 1.1.1.3:0--1.1.1.6:0 
RPF Nexthops :; 
ge-1/2/20.0, 1.2.96.1, Label: 301600, weight: 0x1 
ge-1/2/19.0, 1.3.6.1, Label: 301600, weight: 0x1 
Backup Upstream : 1.1.1.3:0--1.1.1.2:0 
RPF Nexthops : 
ge-1/2/15.0, 1.2.94.1, Label: 301616, weight: Oxfffe 
ge-1/2/14.0, 1.2.3.1, Label: 301616, weight: Oxfffe 


Meaning 
The output shows the primary upstream paths and the backup upstream paths. It also shows the RPF next 
hops. 


Checking the Multicast Routes 
Purpose 


Examine the IP multicast forwarding table to make sure that there is an upstream RPF interface list, with 
a primary and a backup interface. 


Action 


user@R3> show Idp p2mp path 


P2MP path type: Transit/Egress 


Output Session (lab 
Egress Nexthops: In 


Iti 





RPF Nexthops: In 
In 
In 
In 


el): 


Ene 


E jue 


Eee 


Eiene 


Eee 





Eee 





Attached FECs: P2MP root-addr 





(Active) 


P2MP path type: Transit/! 


Egress Nexthops: In 


Lia 





RPF Nexthops: In 
In 
In 
In 


Output Session (label): 


Eiene 


Ene 


Ene 


EGE 


Eee 





Eiene 








Attached FECsS: P2MP root-addr 





(Active) 


P2MP path type: Transit/! 


Egress Nexthops: In 


aleral 





RPF Nexthops: In 
Ia} 
In 
Iva} 


Output Session (label): 


Eiene 


Eee 


Ciene 


E@ne 


Eque 





Ene 








Attached FECsS: P2MP root-addr 





(Active) 


P2MP path type: Transit/! 


Egress Nexthops: In 


Jkiay 





RPF Nexthops: In 
In 
In 
Jia} 


Output Session (label): 


EGne 


Ene 


Eiene 


Eee 


Efene 





Ene 








Attached FECs: P2MP root-addr 





(Active) 


























Lel,1.230 (301568) 
face ge-1/2/18.0 
face ge-1/2/22.0 
face ge-1/2/15.0, 1.2 
face ge-1/2/20.0, 1.2 
face ge-1/2/14.0, 1.2 
TaACe Ge-l/2/19 0, 1.3 
Lets il, grea 
EQress 
Loi.,1,630 (SOLSas4) 
face ge-1/2/18 .0 
face ge-1/2/22.0 
face ge-1/2/15.0, 1.2 
face ge-1/2/20.0, 1.2 
face ge-1/2/14.0, 1.2 
Taco Ge=—1/2/19.0, 163 
lolol, Gia 
EQress 
Lol, .630 (SOL6GO0M) 
face ge-1/2/18.0 
face ge-1/2/22.0 
face ge-1/2/15.0, 1.2 
face ge-1/2/20.0, 1.2 
face ge-1/2/14.0, 1.2 
Tacs Ge-l/2/19.0, 1.3 
Leloilo.l, Gia 
EGress 
Lol, 230 (SOLGL6)) 
face ge-1/2/18.0 
face ge-1/2/22.0 
face ge-1/2/15.0, 1.2 
face ge-1/2/20.0, 1.2 
face ge-1/2/14.0, 1.2 
Tacs gGe=-l/2/19.0, ied 
Lol piel, Gio 
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(Primary) 


oMacl, SOWLSGS, i 
oMSedl, SULA, O55a4 
cdoly, SO0LS6S, I 
-6.1, 301584, 65534 
Z234olelel, seeg 192. 16s, 219), iil 


(Backup) 


oP4o, SOLSGe, Al 
sXe, SOLS, OS5s4 
odoly, SO0LS6S, I 
cGol, SOLSE4, S553 
ASGoledel, Sees T9216, 219511 


(Primary) 


oM4al, SWMSIG, Os5a4 
eVMGsl, SOL6OO, 
oxoll, SCWGIG, 9555! 
sod, SOLO, 1 
ASG oleleAg Sees U2. Uos,219, 11 


(Backup) 


ocd, SWISIG, Osaa4 
oMGcl, SOLSOO, 
cdolly SOLGLG, S534 
eO@ad, SOLO, 1 
234ol,ls2, seg 12. Ls, 219), ial 


Meaning 


The output shows primary and backup sessions, and RPF next hops. 


Checking the LDP Point-to-Multipoint Traffic Statistics 


Purpose 


Make sure that both primary and backup statistics are listed. 


Action 


user@R3> show ldp traffic-statistics p2mp 


P2MP FI 








Shared 


Loilolo lg e2gecolo ial, 19251685219. 


No 


No 


Lodo ls lg2325 15 i, ly 192. LOS. 219). 


No 


Lsiol,lg232o1 5.4, 192. 163.219) 5 


No 


Lodo Ll, lg23251,1 54,192, 168,219). 


Meaning 


ae SERIES LSS 


EE Gx(Gre@ otemci cl clashes omeltclyAchtatoy esta) 


Nexthop 


iets SOLSGS 
LoSo8e2 


Wee ee 


Label: 301584, 
LeSote2 


Le So8o2 


WSLS BOL GO) 
Le Soene 


Le Sose2 


clo cil mel ORGHEGy 
er Stae 


Lo So8o2 


Packets 


Backup route 


Backup route 


The output shows both primary and backup routes with the labels. 


0 


0 


Byes 


977 


Example: Configuring LDP Downstream on Demand 


IN THIS SECTION 


Requirements | 978 
Overview | 978 
Configuration | 978 


Verification | 983 


This example shows how to configure LDP downstream on demand. LDP is commonly configured using 
downstream unsolicited advertisement mode, meaning label advertisements for all routes are received 
from all LDP peers. As service providers integrate the access and aggregation networks into a single MPLS 
domain, LDP downstream on demand is needed to distribute the bindings between the access and 
aggregation networks and to reduce the processing requirements for the control plane. 


Downstream nodes could potentially receive tens of thousands of label bindings from upstream aggregation 
nodes. Instead of learning and storing all label bindings for all possible loopback addresses within the entire 
MPLS network, the downstream aggregation node can be configured using LDP downstream on demand 
to only request the label bindings for the FECs corresponding to the loopback addresses of those egress 
nodes on which it has services configured. 


Requirements 


This example uses the following hardware and software components: 


e M Series router 


e Junos OS 12.2 


Overview 


You can enable LDP downstream on demand label advertisement for an LDP session by including the 
downstream-on-demand statement at the [edit protocols Idp session] hierarchy level. If you have configured 
downstream on demand, the Juniper Networks router advertises the downstream on demand request to 
its peer routers. For a downstream on demand session to be established between two routers, both have 
to advertise downstream on demand mode during LDP session establishment. If one router advertises 
downstream unsolicited mode and the other advertises downstream on demand, downstream unsolicited 
mode is used. 


Configuration 


Configuring LDP Downstream on Demand 


Step-by-Step Procedure 
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To configure a LDP downstream on demand policy and then configure that policy and enable LDP 
downstream on demand on the LDP session: 


1. Configure the downstream on demand policy (DOD-Request-Loopbacks in this example). 


This policy causes the router to forward label request messages only to the FECs that are matched by 
the DOD-Request-Loopbacks policy. 


[edit policy-options] 

user@host# set prefix-list Request-Loopbacks 10.1.1.1/32 

user@host# set prefix-list Request-Loopbacks 10.1.1.2/32 

user@host# set prefix-list Request-Loopbacks 10.1.1.3/32 

user@host# set prefix-list Request-Loopbacks 10.1.1.4/32 

user@host# set policy-statement DOD-Request-Loopbacks term 1 from prefix-list Request-Loopbacks 
user@host# set policy-statement DOD-Request-Loopbacks term 1 then accept 


2. Specify the DOD-Request-Loopbacks policy using the dod-request-policy statement at the [edit 
protocols Idp] hierarchy level. 


The policy specified with the dod-request-policy statement is used to identify the prefixes to send 
label request messages. This policy is similar to an egress policy or an import policy. When processing 
routes from the inet.O routing table, the Junos OS software checks for routes matching the 
DOD-Request-Loopbacks policy (in this example). If the route matches the policy and the LDP session 
is negotiated with DOD advertisement mode, label request messages are sent to the corresponding 
downstream LDP session. 


[edit protocols Idp] 
user@host# set dod-request-policy DOD-Request-Loopbacks 


3. Include the downstream-on-demand statement in the configuration for the LDP session to enable 
downstream on demand distribution mode. 


[edit protocols Idp] 
user@host# set session 1.1.1.1 downstream-on-demand 


Distributing LDP Downstream on Demand Routes into Labeled BGP 


Step-by-Step Procedure 


To distribute LDP downstream on demand routes into labeled BGP, use a BGP export policy. 


1. Configure the LDP route policy (redistribute_Idp in this example). 


[edit policy-options] 

user@host# set policy-statement redistribute_ldp term 1 from protocol Idp 
user@host# set policy-statement redistribute_ldp term 1 from tag 1000 
user@host# set policy-statement redistribute_Ildp term 1 then accept 


2. Include the LDP route policy, redistribute_Idp in the BGP configuration (as a part of the BGP group 
configuration ebgp-to-abr in this example). 


BGP forwards the LDP routes based on the redistribute_Idp policy to the remote PE router 


[edit protocols bgp] 

user@host# set group ebgp-to-abr type external 

user@host# set group ebgp-to-abr local-address 192.168.0.1 

user@host# set group ebgp-to-abr peer-as 65319 

user@host# set group ebgp-to-abr local-as 65320 

user@host# set group ebgp-to-abr neighbor 192.168.6.1 family inet unicast 

user@host# set group ebgp-to-abr neighbor 192.168.6.1 family inet labeled-unicast rib inet.3 
user@host# set group ebgp-to-abr neighbor 192.168.6.1 export redistribute_Idp 


Step-by-Step Procedure 


To restrict label propagation to other routers configured in downstream unsolicited mode (instead of 
downstream on demand), configure the following policies: 


1. Configure the dod-routes policy to accept routes from LDP. 


user@host# set policy-options policy-statement dod-routes term 1 from protocol Idp 
user@host# set policy-options policy-statement dod-routes term 1 from tag 1145307136 
user@host# set policy-options policy-statement dod-routes term 1 then accept 


2. Configure the do-not-propagate-du-sessions policy to not forward routes to neighbors 1.1.1.1, 2.2.2.2, 
and 3.3.3.3. 


user@host# set policy-options policy-statement do-not-propagate-du-sessions term 1 to neighbor 1.1.1.1 
user@host# set policy-options policy-statement do-not-propagate-du-sessions term 1 to neighbor 2.2.2.2 
user@host# set policy-options policy-statement do-not-propagate-du-sessions term 1 to neighbor 3.3.3.3 
user@host# set policy-options policy-statement do-not-propagate-du-sessions term 1 then reject 
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3. Configure the filter-dod-on-du-sessions policy to prevent the routes examined by the dod-routes 
policy from being forwarded to the neighboring routers defined in the do-not-propagate-du-sessions 


policy. 


user@host# set policy-options policy-statement filter-dod-routes-on-du-sessions term 1 from policy 
dod-routes 

user@host# set policy-options policy-statement filter-dod-routes-on-du-sessions term 1 to policy 
do-not-propagate-du-sessions 


4. Specify the filter-dod-routes-on-du-sesssion policy as the export policy for BGP broup ebgp-to-abr. 


[edit protocols bgp] 
user@host# set group ebgp-to-abr neighbor 192.168.6.2 export filter-dod-routes-on-du-sessions 


Results 


From configuration mode, confirm your configuration by entering the show policy-options and show 
protocols Idp commands. If the output does not display the intended configuration, repeat the instructions 
in this example to correct the configuration. 


user@host# 


show policy-options 


prefix—-list Request-—Loopbacks { 
TO Ah wih LY Seka 


IOcl Lo 2 S2p 
1@.1, 13/322 
IQ 1 Ll .a/s2e 


} 
policy-statement DOD-Request-Loopbacks { 





jeeiam i 


from { 





prefix-list Request-—Loopbacks; 
} 


then accept; 


} 
policy-statement redistribute_ldp { 
term 1 { 
incon {{ 


PEOEOCOL dp); 


tag 1000; 
} 


then accept; 


user@host# 


show protocols ldp 


dod-request-—policy DOD-Request-—Loopbacks; 
sesisatom I, 51,1 4 


downst ream-—on-demand; 


user@host# 


show protocols bgp 


group ebgp-to-abr { 
type external; 
Neca acd ness aoe wlGernOlnles 
peer-as 65319; 
1ocal—es SES20" 
neighbor 192.168.6.1 { 
family inet { 
PlinaLieeisie P 
labeled-unicast { 
eal if 


Elba itenenoyy 


} 
export redistribute_ldp; 
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Verification 


Verifying Label Advertisement Mode 


Purpose 


Confirm that the configuration is working properly. 


Use the show lIdp session command to verify the status of the label advertisement mode for the LDP 
session. 


Action 


Issue the show Idp session and show Idp session detail commands: 


e The following command output for the show Idp session command indicates that the Adv. Mode (label 
advertisement mode) is DOD (meaning the LDP downstream on demand session is operational): 


user@host> show lIdp session 


Address State Connection Hold time Adv. Mode 
sale dhe 2 Operational Open Bee DOD 
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e The following command output for the show Idp session detail command indicates that the Local Label 
Advertisement mode is Downstream unsolicited, the default value (meaning downstream on demand 
is not configured on the local session). Conversely, the Remote Label Advertisement mode and the 
Negotiated Label Advertisement mode both indicate that Downstream on demand is configured on the 
remote session 


user@host> show ldp session detail 


Address: 1.1.1.2, State: Operational, Connection: Open, Hold time: 24 
Sessiom Dg Lol,t,dgs0=-1,1,1,230 

ext keepalive in 4 seconds 

Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1 

eighbor types: configured-tunneled 

Keepalive interval: 10, Connect retry interval: 1 

Local address: 1.1.1.1, Remote address: 1.1.1.2 

Uj: score Ilys aaa a2 





Capabilities advertised: non 








Capabilities received: non 


Protection: disabled 





Local - Restart: disabled, Helper mode: enabled, 





Remote — Restart: disabled, Helper mode: enabled 
Local maximum neighbor reconnect time: 120000 msec 


Local maximum neighbor recovery time: 240000 msec 





Local Label Advertisement mode: Downstream unsolicited 





Remote Label Advertisement mode: Downstream on demand 








Negotiated Label Advertisement mode: Downstream on demand 
Nonstop routing state: Not in sync 
Next—-hop addresses received: 

Al bs aly ae 


Configuring LDP Native IPv6é Support 


LDP is supported in an IPv6-only network, and in an IPvé6 or IPv4 dual-stack network as described in RFC 
7552. Configure the address family as inet for |Pv4 or inet6 for IPv6 or both, and the transport preference 
to be either IPv4 or IPv6. The dual-transport statement allows Junos OS LDP to establish the TCP 
connection over IPv4 with IPv4 neighbors, and over IPv6 with IPv6 neighbors as a single-stack LSR. The 
inet-Isr-id and inet6-lsr-id IDs are the two LSR IDs that have to be configured to establish an LDP session 
over IPv4 and IPvé TCP transport. These two IDs should be non-zero and must be configured with different 
values. 


Before you configure IPv6 as dual-stack, be sure you configure the routing and signaling protocols. 
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To configure LDP native IPv6é support, you must do the following: 


1. Enable forwarding equivalence class (FEC) deaggregation in order to use different labels for different 
address families. 


[edit protocols Idp] 
set deaggregate 


2. Configure LDP address families. 


[edit protocols Idp] 
set family inet6 
set family inet 


3. Configure the transport-preference statement to select the preferred transport for the TCP connection 
when both IPv4 and IPvé6 are enabled. By default, IPv6 is used as the TCP transport for establishing an 
LDP connection. 


[edit protocols Idp] 
set transport-preference ipv4 


4. (Optional) Configure dual-transport to allow LDP to establish a separate IPv4 session with an IPv4 
neighbor, and an IPvé6 session with an IPv6 neighbor. Configure inet-Isr-id as the LSR ID for IPv4, and 
inet6-Isr-id as the LSR ID for IPvé. 


[edit protocols Idp dual-transport] 
set inet-lsr-id inet-Isr-id 
set inet6-Isr-id inet6-Isr-id 


For example, configure inet-Isr-id as 10.255.0.1, and inet6-Isr-id as 1.1.1.1. 


[edit protocols Idp dual-transport] 
set inet-Isr-id 10.255.0.1 
set inet6-Isr-id 1.1.1.1 
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Example: Configuring LDP Native IPv6é Support 


IN THIS SECTION 


@ Requirements | 986 
@ Overview | 986 
@ = Configuration | 987 


This example shows how to allow the Junos OS Label Distribution Protocol (LDP) to establish the TCP 
connection over IPv4 with IPv4 neighbors, and over IPv6 with IPv6 neighbors as a single-stack LSR. This 
helps avoid tunneling of IPv6é over IPv4 MPLS core with IPv4-signaled MPLS label-switched paths (LSPs). 
Requirements 


This example uses the following hardware and software components: 


e Two MxX Series routers 


e Junos OS Release 16.1 or later running on all devices 
Before you configure IPv6 as dual-stack, be sure you configure the routing and signaling protocols. 


Overview 


LDP is supported in an IPv6 only network, and in an IPv6 or IPv4 dual-stack network as described in RFC 
7552. Configure the address family as inet for IPv4 or inet6 for IPv6é. By default, IPv6 is used as the TCP 
transport for the LDP session with its peers when both IPv4 and IPvé6 are enabled . The dual-transport 
statement allows Junos LDP to establish the TCP connection over IPv4 with IPv4 neighbors, and over IPv6é 
with IPv6 neighbors as a single-stack LSR. The inet-Isr-id and inet6-Isr-id are the two LSR IDs that have 
to be configured to establish an LDP session over IPv4 and IPv6 TCP transport. These two IDs should be 
non-zero and must be configured with different values. 


Topology 
Figure 82 on page 986 shows the LDP IPvé6 configured as dual-stack on Device R1 and Device R2. 


Figure 82: Example LDP Native IPv6 Support 


ge-1/0/0 ge-1/0/1 


Rl 192.168.12.1/24 192.168.12.2/24 R2 
2001:db8:0:12::/64 2001:db8:0:12::/64 
3 
lo0 10.255.0.1/32 (00 10.255.0.2/32 9 
le} 
‘00 


2001:db8::1/128 2001:db8::2/128 
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Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


R1 


set interfaces ge-1/0/0 unit 0 family inet address 192.168.12.1/24 

set interfaces ge-1/0/0 unit 0 family iso 

set interfaces ge-1/0/0 unit 0 family inet6 address 2001:db8:0:12::/64 eui-64 
set interfaces ge-1/0/0 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.0.1/32 

set interfaces loO unit O family iso address 49.0001.1720.1600.1010.00 
set interfaces loO unit O family inet6 address 2001:db8::1/128 

set protocols isis interface ge-1/0/0.0 

set protocols isis interface lo0.0 

set protocols mpls interface ge-1/0/0.0 

set protocols Idp deaggregate 

set protocols Idp interface ge-1/0/0.0 

set protocols Idp interface lo0.0 

set protocols Idp family inet6 

set protocols Idp family inet 


R2 


set interfaces ge-1/0/1 unit 0 family inet address 192.168.12.2/24 

set interfaces ge-1/0/1 unit 0 family iso 

set interfaces ge-1/0/1 unit 0 family inet6 address 2001:db8:0:12::/64 eui-64 
set interfaces ge-1/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.0.2/32 

set interfaces loO unit O family iso address 49.0001.1720.1600.2020.00 
set interfaces loO unit O family inet6 address 2001:db8::2/128 

set protocols isis interface ge-1/0/1.0 

set protocols isis interface lo0.0 

set protocols mpls interface ge-1/0/1.0 

set protocols Idp deaggregate 

set protocols Idp interface ge-1/0/1.0 

set protocols Idp interface lo0.0 


set protocols Idp family inet6 
set protocols Idp family inet 


Configuring R1 


Step-by-Step Procedure 

The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see “Using the CLI Editor in Configuration Mode” in the CLI User 
Guide. 


To configure Device R1: 


1. Configure the interfaces. 


[edit interfaces] 

set ge-1/0/0 unit O family inet address 192.168.12.1/24 

set ge-1/0/0 unit O family iso 

set ge-1/0/0 unit O family inet6 address 2001:db8:0:12::/64 eui-64 
set ge-1/0/0 unit 0 family mpls 


2. Assign a loopback address to the device. 


[edit interfaces loO unit O] 

set family inet address 10.255.0.1/32 

set family iso address 49.0001.1720.1600.1010.00 
set family inet6 address 2001:db8::1/128 


3. Configure the IS-IS interfaces. 


[edit protocols isis] 
set interface ge-1/0/0.0 
set interface lo0.0 


4. Configure MPLS to use LDP interfaces on the device. 


[edit protocols mpls] 

set protocols mpls interface ge-1/0/0.0 
set interface ge-1/0/0.0 

set interface lo0.0 
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5. Enable forwarding equivalence class (FEC) deaggregation in order to use different labels for different 


address families. 


[edit protocols Idp] 
set deaggregate 


6. Configure LDP address families. 


[edit protocols Idp] 
set family inet6 
set family inet 


Results 


From configuration mode, confirm your configuration by entering the show interfaces and show protocols 
commands. If the output does not display the intended configuration, repeat the instructions in this example 


to correct the configuration. 


user@R1# show interfaces 
ge-1/0/0 { 
unit O { 

family inet { 
address 192.168.12.1/24- 

} 

family iso; 

family ineté { 
address 2001:db8:0:12::/64 { 

eui-64; 


} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 10.255.0.1/32; 
} 
family iso { 
address 49.0001.1720.1600.1010.00 
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} 
family ineté { 


address 2001:db8::1/128; 


user@R1# show protocols 
mpls { 
interface ge-1/0/0.0; 
} 
isis { 
interface ge-1/0/0.0; 
interface 100.0; 
} 
Idp { 
deaggregate; 
interface ge-1/0/0.0; 
interface 100.0; 
family { 
inet6; 


inet; 


Verification 


IN THIS SECTION 


Verifying the Route Entries in the mpls.0 Table | 991 
Verifying the Route Entries in the inet.3 Table | 991 


Verifying the LDP Database | 992 


@ 
t 
@ Verifying the Route Entries in the inet6.3 Table | 992 
t 
@ Verifying the LDP Neighbor Information | 993 

@ 


Verifying the LDP Session Information | 994 


Confirm that the configuration is working properly. 
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Verifying the Route Entries in the mpls.0 Table 


Purpose 


Display mpls.0 route table information. 
Action 


On Device R1, from operational mode, run the show route table mpls.0 command to display mpls.O route 
table information. 


user@R1> show route table mpls.0O 


mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) 






































+ = Active Route, Last Active, * = Both 
0 *(MPLS/0] 05:19:58, metric 1 
Receive 
1 eo (MP IES Ol Oos eS > eee meieraskouml 
Receive 
2 ‘AMP GS OllmO Sele 9 5 ceemeiera keel 
Receive 
33 SMPs / Oi] OSsilVeSs, meeresle: ih 
Receive 
299824 2e | D2 / S| O4s29e85, mercieie Il 
> to fe80::21£:1200:cb6:4c8d via ge-1/0/0.0, Pop 
299824 (S=0) Pa [REDE // 9s) e045 218 214 Sy eeme ites cel 
> to fesOe:21f: L200 cho: 4c8d yaa ge-l/ 0/00), Pop 
299888 “([UDP/S] OO&S6312, mere i 
> to 192.168.1222 wia ge-1/0/0.0, Poe 
299888 (S=0) ~([mD2/9] OOSS6312, mweerie il 
> ico 192 168,122.28 wie Ge-1/O0/0.0, Pej 





Meaning 


The output shows the mpls.O route table information. 


Verifying the Route Entries in the inet.3 Table 


Purpose 


Display inet.3 route table information. 
Action 


On Device R1, from operational mode, run the show route table inet.3 command to display inet.3 route 
table information. 


user@R1> show route table inet.3 
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inet.3: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 


10 5255.0. 2/32 * EDP OOO 5893877 metro al 
> to 192,168.12,.2 wila ge-1/0/0.0 


Meaning 


The output shows the inet.3 route table information. 


Verifying the Route Entries in the inet6.3 Table 


Purpose 


Display inet6.3 route table information. 


Action 


On Device R1, from operational mode, run the show route table inet6.3 command to display inet6.3 route 
table information. 


user@R1> show route table inet6.3 


inet6.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 


+ = Active Route, Last Active, * = Both 








ZOOL seloisss 32/28} = (ID2/S] O4eSileily, wmeseieae I 
> CO HSROSE Pili slZOOscoGsdekicl wia ge—i/0/0.0 


Meaning 


The output shows the inet6.3 route table information. 


Verifying the LDP Database 


Purpose 


Display the LDP database information. 


Action 


On Device R1, from operational mode, run the show Idp database command to display LDP database 
information. 


user@R1> show lIdp database 


993 


inputs labelmdacabasc,s lO. 2550-0 = Om 55: O20) 


Labels received: 3 


Label Prefix 
299840 1052550 .1/32 
8 10,255.50 .2/ 32 
299808 AWOL glass g/L Ae 
3 POOL a clove) 3g 2/1 Axe 


OuEpUE abel database, LUMnZ oS One OS— Om > orOn a0) 


Labels advertised: 3 


Label Prefix 
3 10,255.0.1/32 
299888 10,255 ,0,2/382 
8 2001:db8::1/128 
299824 2001:db8::2/128 
Meaning 


The output shows the entries in the LDP database. 


Verifying the LDP Neighbor Information 


Purpose 


Display the LDP neighbor information. 
Action 


On Device R1, from operational mode, run the show Idp neighbor and show Idp neighbor extensive 
commands to display LDP neighbor information. 


user@R1> show lIdp neighbor 


Address Interface Label space ID Hold time 
fe80::21£:1200:cb6:4c8d ge-1/0/0.0 10,255.0,230 12 
192,168.12 .2 ge-1/0/0.0 10.255 .0.230 il 


user@R1> show lIdp neighbor extensive 


Address Interface Label space ID Hold time 
197 168,12 52 ge-1/0/0.0 10,255.50 .230 Wi 


Transport address: 10.255.0.2, Transport preference: IPv6, Configuration sequence: 
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10 

Up for 00:04:35 

Reference count: 1 

Hold time: 15, Proposed local/peer: 15/15 

Hello flags: none 

Neighbor types: discovered 
Address Interface Label space ID Hold time 
fe80::21f:1200:cb6:4c8d ge-1/0/0.0 10), 255..0,230 14 

Transport address: 2001:db8::2, Transport preference: IPv6, Configuration 
sequence: 10 

Up for 00:04:35 

Reference count: 1 

Hold time: 15, Proposed local/peer: 15/15 

Hello flags: none 


Neighbor types: discovered 


Meaning 


The output shows LDP neighbor information of both IPv4 and IPv6 addresses. 


Verifying the LDP Session Information 


Purpose 


Display the LDP session information. 
Action 


On Device R1, from operational mode, run the show Idp session and show Idp session extensive commands 
to display LDP session information. 


user@R1> show lIdp session 


session 
Address State Connection Hold time Adv. Mode 
AQOILR Close 32 Operational Open 20 DU 


user@R1> show ldp session extensive 


Address: 2001:db8::2, State: Operational, Connection: Open, Hold time: 29 
SEsSiom wos 10,255,0-.ils0--10,.255.0,230 


Next keepalive in 9 seconds 


Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 


Neighbor types: discovered 


Keepalive interval: 10, Connect retry interval: 


Local address: 2001:db8::1, Remote address: 2001:db8::2 


Us cox WOWsOSs iL 


Capabilities advertised: non 








Capabilities received: non 
Protection: disabled 


Session flags: none 





Local - Restart: disabled, Helper mode: enabled 














TU discovery: disabled 


Nonstop routing state: Not in sync 





Next-hop addresses received: 
10525500562 
192 168.1252 
AMOI gcloess 32 
£e80::21£:1200:ch6:4c8d 
Queue depth: 0 


Message type Total 

Sent Received 
Initialization 1 i 
Keepalive 34 34 
Notification 0 0 
Address 1 iL 
Address withdraw 0 0 
Label mapping 3) 3 
Label request 0 0 
Label withdraw 0 0 
Label release 0 0 
Label abort 0 0 





Meaning 


Remote — Restart: disabled, Helper mode: enabled 


Local maximum neighbor recovery time: 240000 msec 


Local maximum neighbor reconnect time: 120000 msec 


Local Label Advertisement mode: Downstream unsolicited 


Remote Label Advertisement mode: Downstream unsolicited 


al 


Negotiated Label Advertisement mode: Downstream unsolicited 


Last 5 seconds 


n 
0) 
Bi 
Gi 


ES QS oa ae o& 2 © @& & 


Received 


So oo a 2c 2 ec S&S & 


The output displays information for the LDP session using IPv6 as the TCP transport. 


Configure transport-preference to Select the Preferred Transport 


CLI Quick Configuration 
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You can configure the transport-preference statement to select the preferred transport for a TCP connection 
when both IPv4 and IPvé6 are enabled. By default, IPv6é is used as TCP transport for establishing an LDP 
connection. 


e (Optional) Configure the transport preference for an LDP connection. 


[edit protocols Idp] 
set transport-preference ipv4 


Results 


From configuration mode, confirm your configuration by entering the show protocols command. If the 
output does not display the intended configuration, repeat the instructions in this example to correct the 
configuration. 


user@R1# show protocols 
mpls { 
interface ge-1/0/0.0; 
} 
isis { 
interface ge-1/0/0.0; 
interface 100.0; 
} 
Idp { 
deaggregate; 
interface ge-1/0/0.0; 
interface 100.0; 
family { 
inet6; 
inet; 
} 


transport-preference ipv4; 


Verification 


IN THIS SECTION 


@ Verifying the LDP Neighbor Information | 997 
@ ~~ Verifying the LDP Session Information | 997 
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Confirm that the configuration is working properly. 


Verifying the LDP Neighbor Information 


Purpose 


Display the LDP neighbor information. 


Action 


On Device R1, from operational mode, run the show Idp neighbor extensive command to display LDP 
neighbor information. 


user@R1> show lIdp neighbor extensive 


Address Interface Label space ID Hold time 
19%, WOS 12 62 ge-1/0/0.0 10 6255.0 .230 14 


Transport address: 10.255.0.2, Transport preference: IPv4, Configuration sequence: 


US tor OO ZOO sg 14 
Reference count: 1 
Hold time: 15, Proposed local/peer: 15/15 


Hello flags: none 





Neighbor types: discovered 


Address Interface Label space ID Hold time 
fe80::21f:1200:cb6:4c8d ge-1/0/0.0 10, 255.0,230 14 

Transport address: 2001:db8::2, Transport preference: IPv4, Configuration 
sequence: 9 

Upm roe OOO Os 

Reference count: 1 


Hold time: 15, Proposed local/peer: 15/15 
Hello flags: none 


Neighbor types: discovered 


Meaning 


The output shows LDP neighbor information for both the IPv4 and IPvé6 addresses. 


Verifying the LDP Session Information 


Purpose 


Display the LDP session information. 


Action 


On Device R1, from operational mode, run the show Idp session extensive command to display LDP 
session information. 


user@R1> show ldp session extensive 


Address: 10.255.0.2, State: Operational, Connection: Open, Hold time: 24 
SESSHOn MED me Oni Zo Or Or ea ll Omea oon Omezes0 

Next keepalive in 4 seconds 

Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 2 

Neighbor types: discovered 

Keepalive interval: 10, Connect retry interval: 1 

Local address: 10.255.0.1, Remote address: 10.255.0.2 

Up mEOr OOM OS i216 


Capabilities advertised: non 








Capabilities received: non 





Protection: disabled 


Session flags: none 





Local - Restart: disabled, Helper mode: enabled 





Remote — Restart: disabled, Helper mode: enabled 
Local maximum neighbor reconnect time: 120000 msec 
Local maximum neighbor recovery time: 240000 msec 


Local Label Advertisement mode: Downstream unsolicited 





Remote Label Advertisement mode: Downstream unsolicited 








Negotiated Label Advertisement mode: Downstream unsolicited 
MTU discovery: disabled 


Nonstop routing state: Not in sync 





Next-hop addresses received: 
10 6255.02 
192 168, 1252 
AMOI gclogss 32 
fe80::21f£:1200:ch6:4c8d 
Queue depth: 0 





Message type Total Last 5 seconds 
Sent Received Sent Received 
Initialization 1 1 0 0 
Keepalive 33) 3s al 1 
Notification 0 0 0 0 
Address 2 2 0 0 
Address withdraw 0 0 0 0 
Label mapping 6 6 0 0 
Label request 0 0 0 0 
Label withdraw 0 0 0 0 
Label release 0 0 0 0 
Label abort 0 0 0 0 


Meaning 


The output displays information for the LDP session using IPv6 as the TCP transport. 
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Configure dual-transport to Establish Separate Sessions for IPv4 with an IPv4 Neighbor and IPv6 with an IPv6 
Neighbor 


Step-by-Step Procedure 


You can configure the dual-transport statement to allow LDP to establish a separate IPv4 session with an 
IPv4 neighbor, and an IPvé6 session with an IPv6 neighbor. This requires the configuration of inet-Isr-id as 
the LSR ID for IPv4, and inet6-Isr-id as the LSR ID for IPv6. 


e (Optional) Configure dual-transport to allow LDP to establish the TCP connection over IPv4 with IPv4 
neighbors, and over IPv6 with IPv6 neighbors as a single-stack LSR. 


[edit protocols Idp dual-transport] 
set inet-Isr-id 10.255.0.1 
set inet6-Isr-id 1.1.1.1 


Results 


From configuration mode, confirm your configuration by entering the show protocols command. If the 
output does not display the intended configuration, repeat the instructions in this example to correct the 
configuration. 


user@R1# show protocols 
mpls { 
interface ge-1/0/0.0; 
} 
isis { 
interface ge-1/0/0.0; 
interface 100.0; 
} 
Idp { 
deaggregate; 
interface ge-1/0/0.0; 
interface 100.0; 
family { 
inet6; 
inet; 
} 
dual-transport { 
inet-Isr-id 10.255.0.1; 
inet6-Isr-id 1.1.1.1; 
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Verification 


IN THIS SECTION 


@ Verifying the LDP Neighbor Information | 1000 
@ Verifying the LDP Session Information | 1001 


Confirm that the configuration is working properly. 


Verifying the LDP Neighbor Information 


Purpose 


Display the LDP neighbor information. 
Action 


On Device R1, from operational mode, run the show Idp neighbor extensive command to display LDP 
neighbor information. 


user@R1> show lIdp neighbor extensive 


Address Interface Label space ID Hold time 
192 168.1252 ge-1/0/0.0 10. 259.0.280 il 

Transport address: 10.255.0.2, Configuration sequence: 10 

Up for 00:04:35 

Reference count: 1 

Hold time: 15, Proposed local/peer: 15/15 

Hello flags: none 

Neighbor types: discovered 
Address Interface Label space ID Hold time 
fe80::21f:1200:cb6:4c8d ge-1/0/0.0 10 ,255.0.,230 14 

Transport address: 2001:db8::2, Configuration sequence: 10 

Woman OOF fO4s:8S15 

Reference count: 1 

Hold time: 15, Proposed local/peer: 15/15 

Hello flags: none 


Neighbor types: discovered 


Meaning 


The output shows LDP neighbor information for both the IPv4 and IPvé addresses. 


Verifying the LDP Session Information 


Purpose 


Display the LDP session information. 
Action 


On Device R1, from operational mode, run the show Idp session extensive command to display LDP 
neighbor information. 


user@R1> show ldp session extensive 


Address: 2001:db8::2, State: Operational, Connection: Open, Hold time: 29 
Session Wg toil s0-——1l0,255.,0.290 

Next keepalive in 9 seconds 

Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1 

Neighbor types: discovered 

Keepalive interval: 10, Connect retry interval: 1 

Local address: 2001:db8::1, Remote address: 2001:db8::2 

UpMEOrmOOM OS sa 


Capabilities advertised: non 








Capabilities received: non 





Protection: disabled 
Session flags: none 


Local - Restart: disabled, Helper mode: enabled 





Remote — Restart: disabled, Helper mode: enabled 





Local maximum neighbor reconnect time: 120000 msec 
Local maximum neighbor recovery time: 240000 msec 


Local Label Advertisement mode: Downstream unsolicited 





Remote Label Advertisement mode: Downstream unsolicited 





Negotiated Label Advertisement mode: Downstream unsolicited 





MTU discovery: disabled 


Nonstop routing state: Not in sync 





Next-hop addresses received: 
ZOOL gclos 3 32 
£e80::21f£:1200:cbh6:4c8d 

Queue depth: 0 


Message type Total Last 5 seconds 
Sent Received Sent Received 
Initialization 1 il 0 0 
Keepalive 34 34 0 0 
Notification 0 0 0 0 
Address 1 1 0 0 
Address withdraw 0 0 0 0 
Label mapping 3 S 0 0 
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Label request 
Label withdraw 


Label release 





Ss ~c Sj € 
a 2 2a © 
cS) Sy eS) © 
> 


Label abort 


Address: 10.255.0.2, State: Operational, Connection: Open, Hold time: 29 
Sessitem Dg 10,255,0.1Ls0—10.,.255.0,230 

Next keepalive in 9 seconds 

Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1 

Neighbor types: discovered 

Keepalive interval: 10, Connect retry interval: 1 

Local address: 10.255.0.1, Remote address: 10.255.0.2 

Us toe OUSOS¢ Sil 





Capabilities advertised: non 





Capabilities received: none 

Protection: disabled 

Session flags: none 

Local - Restart: disabled, Helper mode: enabled 
Remote — Restart: disabled, Helper mode: enabled 








Local maximum neighbor reconnect time: 120000 msec 
Local maximum neighbor recovery time: 240000 msec 


Local Label Advertisement mode: Downstream unsolicited 








Remote Label Advertisement mode: Downstream unsolicited 


Negotiated Label Advertisement mode: Downstream unsolicited 





TU discovery: disabled 


Nonstop routing state: Not in sync 





Next-hop addresses received: 
IO 62554052 
192 168, 1262 

Queue depth: 0 


Message type Total Last 5 seconds 
Sent Received Sent Received 
Initialization 1 1 0 0 
Keepalive 34 34 0 0 
Notification 0 0 0 0 
Address al iL 0 0 
Address withdraw 0 0 0 0 
Label mapping 3 S 0 0 
Label request 0 0 0 0 
Label withdraw 0 0 0 0 
Label release 0 0 0 0 
Label abort 0 0 0 0 
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The Multipoint Label Distribution Protocol (M-LDP) for point-to-multipoint label-switched paths (LSPs) 
with in-band signaling is useful in a deployment with an existing IP/MPLS backbone, in which you need 
to carry multicast traffic, for IPTV for example. 


For years, the most widely used solution for transporting multicast traffic has been to use native IP multicast 
in the service provider core with multipoint IP tunneling to isolate customer traffic. A multicast routing 
protocol, usually Protocol Independent Multicast (PIM), is deployed to set up the forwarding paths. IP 
multicast routing is used for forwarding, using PIM signaling in the core. For this model to work, the core 
network has to be multicast enabled. This allows for effective and stable deployments even in 
inter-autonomous system (AS) scenarios. 


However, in an existing IP/MPLS network, deploying PIM might not be the first choice. Some service 
providers are interested in replacing IP tunneling with MPLS label encapsulation. The motivations for 
moving to MPLS label switching is to leverage MPLS traffic engineering and protection features and to 
reduce the amount of control traffic overhead in the provider core. 


To do this, service providers are interested in leveraging the extension of the existing deployments to 
allow multicast traffic to pass through. The existing multicast extensions for IP/MPLS are point-to-multipoint 
extensions for RSVP-TE and point-to-multipoint and multipoint-to-multipoint extensions for LDP. These 
deployment scenarios are discussed in RFC 6826, Multipoint LDP In-Band Signaling for Point-to-Multipoint 
and Multipoint-to-Multipoint Label Switched Paths. This feature overview is limited to point-to-multipoint 
extensions for LDP. 


How M-LDP Works 


IN THIS SECTION 


@ _Label Bindings in M-LDP Signaling | 1004 
@  M-LDP in PIM-Free MPLS Core | 1005 
@ M-LDP in PIM-Enabled MPLS Core | 1007 


Label Bindings in M-LDP Signaling 


The multipoint extension to LDP uses point-to-multipoint and multipoint-to-multipoint forwarding 
equivalence class (FEC) elements (defined in RFC 5036, LDP Specification) along with capability 
advertisements, label mapping, and signaling procedures. The FEC elements include the idea of the LSP 
root, which is an IP address, and an “opaque” value, which is a selector that groups together the leaf nodes 
sharing the same opaque value. The opaque value is transparent to the intermediate nodes, but has meaning 
for the LSP root. Every LDP node advertises its local incoming label binding to the upstream LDP node on 
the shortest path to the root IP address found in the FEC. The upstream node receiving the label bindings 
creates its own local label and outgoing interfaces. This label allocation process might result in packet 
replication, if there are multiple outgoing branches. As shown in Figure 83 on page 1005, an LDP node merges 
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the label bindings for the same opaque value if it finds downstream nodes sharing the same upstream 
node. This allows for effective building of point-to-multipoint LSPs and label conservation. 


Figure 83: Label Bindings in M-LDP Signaling 




























a ee ere 
Root: 10.1.1.1 
Lo0: 10.1.1.1/32 Opaque: X 
J Label: 20 
Root: 10.1.1.1 
Opaque: X 
Label: 10 
Root: 10.1.1.1 7**> 
Opaque: X 
Label: 50 = \ efemmy, ummm “I= ree eee ee pee me 
Root: 10.1.1.1 Root: 10.1.1.1 
Opaque: X Opaque: X 
Labels Merge Here Label: 40 Label: 30 
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M-LDP in PIM-Free MPLS Core 


Figure 84 on page 1006 shows a scaled-down deployment scenario. Two separate PIM domains are 
interconnected by a PIM-free core site. The border routers in this core site support PIM on the border 
interfaces. Further, these border routers collect and distribute the routing information from the adjacent 
sites to the core network. The edge routers in Site C run BGP for root-node discovery. Interior gateway 
protocol (IGP) routes cannot be used for ingress discovery because in most cases the forwarding next hop 
provided by the IGP would not provide information about the ingress device toward the source. M-LDP 
inband signaling has a one-to-one mapping between the point-to-multipoint LSP and the (S,G) flow. With 
in-band signaling, PIM messages are directly translated into M-LDP FEC bindings. In contrast, out-of-band 
signaling is based on manual configuration. One application for M-LDP inband signaling is to carry IPTV 
multicast traffic in an MPLS backbone. 
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Figure 84: Sample M-LDP Topology in PIM-Free MPLS Core 
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Configuration 


The configuration statement mldp-inband-signalling on the label-edge router (LER) enables PIM to use 
M-LDP in-band signaling for the upstream neighbors when the LER does not detect a PIM upstream 
neighbor. Static configuration of the MPLS LSP root is included in the PIM configuration, using policy. This 
is needed when IBGP is not available in the core site or to override IBGP-based LSP root detection. 


For example: 


protocols { 
pim { 
mldp-inband-signalling { 
policy Isp-mapping-policy-example; 


policy-options { 
policy-statement Isp-mapping-policy-example { 
term channel1 { 
from { 
source-address-filter ip-prefix</prefix-length>; #policy filter for channel1 
} 
then { 


p2mp-lsp-root { 
# Statically configured ingress address of edge 
# used by channel1 
address ip-address; 


} 


accept; 


M-LDP in PIM-Enabled MPLS Core 


Starting in Junos OS Release 14.1, in order to migrate existing IPTV services from native IP multicast to 
MPLS multicast, you need to smoothly transition from PIM to M-LDP point-to-multipoint LSPs with minimal 
outage. Figure 85 on page 1007 shows a similar M-LDP topology as Figure 84 on page 1006, but with a different 
scenario. The core is enabled with PIM, with one source streaming all the IPTV channels. The TV channels 
are sent as ASM streams with each channel identified by its group address. Previously, these channels 
were streamed on the core as IP streams and signaled using PIM. 


Figure 85: Sample M-LDP Topology in PIM-Enabled MPLS Core 
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By configuring the mldp-inband-signaling in this scenario, M-LDP signaling is initiated only when there is 
no PIM neighbor towards the source. However, because there is always a PIM neighbor towards the source 
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unless PIM is deactivated on the upstream interfaces of the egress PE, PIM takes precedence over M-LDP 
and M-LDP does not take effect. 


Configuration 


To progressively migrate channel by channel to M-LDP MPLS core with few streams using M-LDP upstream 
and other streams using existing PIM upstream, include the selected-mldp-egress configuration statement 
along with group based filters in the policy filter for M-LDP inband signaling. 


NOTE: The M-LDP inband signaling policy filter can include either the source-address-filter 
statement or the route-filter statement, or a combination of both. 


For example: 


protocols { 
pim { 
mldp-inband-signalling { 
policy Isp-mapping-policy-example; 


policy-options { 
policy-statement Isp-mapping-policy-example { 
term channel1 { 

from { 
source-address-filter ip-prefix</prefix-length>; #policy filter for channel1 

} 

then { 
selected-mldp-egress; 


accept; 


} 
term channel2 { 
from { 
source-address-filter ip-prefix</prefix-length>; #policy filter for channel2 
route-filter ip-prefix</prefix-length>; #policy filter on multicast group address 
} 
then { 
selected-mldp-egress; 
p2mp-lsp-root { 
# Statically configured ingress address of edge 
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# used by channel2 
address ip-address; 
} 
accept; 
} 
} 
term channel3 { 
from { 
route-filter ip-prefix</prefix-length>; #policy filter on multicast group address 
} 
then { 
selected-mldp-egress; 
accept; 


} 


NOTE: 


Some of the limitations of the above configuration are as follows: 


e The selected-mldp-egress statement should be configured only on the LER. Configuring the 
selected-mldp-egress statement on non-egress PIM routers can cause path setup failures. 


e When policy changes are made to switch traffic from PIM upstream to M-LDP upstream and 
vice-versa, packet loss can be expected as break-and-make mechanism is performed at the 
control plane. 


Terminology 


The following terms are important for an understanding of M-LDP in-band signaling for multicast traffic. 
Point-to-point LSP—An LSP that has one ingress label-switched router (LSR) and one egress LSR. 
Multipoint LSP—Either a point-to-multipoint or a multipoint-to-multipoint LSP. 

Point-to-multipoint LSP—An LSP that has one ingress LSR and one or more egress LSRs. 
Multipoint-to-point LSP—An LSP that has one or more ingress LSRs and one unique egress LSR. 


Multipoint-to-multipoint LSP—An LSP that connects a set of nodes, such that traffic sent by any node in 
the LSP is delivered to all others. 
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Ingress LSR—An ingress LSR for a particular LSP is an LSR that can send a data packet along the LSP. 
Multipoint-to-multipoint LSPs can have multiple ingress LSRs. Point-to-multipoint LSPs have only one, 
and that node is often referred to as the root node. 


Egress LSR—An egress LSR for a particular LSP is an LSR that can remove a data packet from that LSP for 
further processing. Point-to-point and multipoint-to-point LSPs have only a single egress node. 
Point-to-multipoint and multipoint-to-multipoint LSPs can have multiple egress nodes. 


Transit LSR—An LSR that has reachability to the root of the multipoint LSP through a directly connected 
upstream LSR and one or more directly connected downstream LSRs. 


Bud LSR—An LSR that is an egress but also has one or more directly connected downstream LSRs. 


Leaf node—Either an egress or bud LSR in the context of a point-to-multipoint LSP. In the context of a 
multipoint-to-multipoint LSP, an LSR is both ingress and egress for the same multipoint-to-multipoint 
LSP and can also be a bud LSR. 


Ingress Join Translation and Pseudo Interface Handling 


At the ingress LER, LDP notifies PIM about the (S,G) messages that are received over the in-band signaling. 
PIM associates each (S,G) messagewith a pseudo interface. Subsequently, a shortest-path-tree (SPT) join 
message is initiated toward the source. PIM treats this as a new type of local receiver. When the LSP is 
torn down, PIM removes this local receiver based on notification from LDP. 

Ingress Splicing 


LDP provides PIM with a next hop to be associated with each (S,G) entry. PIM installs a PIM (S,G) multicast 
route with the LDP next hop and other PIM receivers. The next hop is a composite next hop of local 
receivers + the list of PIM downstream neighbors + a sub-level next hopfor the LDP tunnel. 


Reverse Path Forwarding 
PIM's reverse-path-forwarding (RPF) calculation is performed at the egress node. 


PIM performs M-LDP in-band signaling when all of the following conditions are true: 


e There are no PIM neighbors toward the source. 
e The M-LDP in-band signaling statement is configured. 


e The next hop is learned through BGP, or is present in the static mapping (specified in an M-LDP in-band 
signaling policy). 


Otherwise, if LSP root detection fails, PIM retains the (S,G) entry with an RPF state of unresolved. 


PIM RPF registers this source address each time unicast routing information changes. Therefore, if the 
route toward the source changes, the RPF recalculation recurs. BGP protocol next hops toward the source 
too are monitored for changes in the LSP root. Such changes might cause traffic disruption for short 
durations. 
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LSP Root Detection 


If the RPF operation detects the need for M-LDP in-band signaling upstream, the LSP root (ingress) is 
detected. This root is a parameter for LDP LSP signaling. 


The root node is detected as follows: 


1. If the existing static configuration specifies the source address, the root is taken as given in configuration. 


2. A lookup is performed in the unicast routing table. If the source address is found, the protocol next 
hop toward the source is used as the LSP root. 


Prior to Junos OS Release 16.1, M-LDP point-to-multipoint LSP is signaled from an egress to ingress 
using the root address of the ingress LSR. This root address is reachable through IGP only, thereby 
confining the M-LDP point-to-multipoint LSP to a single autonomous system. If the root address is not 
reachable through an IGP, but reachable through BGP, and if that BGP route is recursively resolved 
over an MPLS LSP, then the point-to-multipoint LSP is not signaled further from that point towards 
the ingress LSR root address. 


There is a need for these non-segmented point-to-multipoint LSPs to be signaled across multiple 
autonomous systems, which can be used for the following applications: 

e Inter-AS MVPN with non-segmented point-to-multipoint LSPs. 

e Inter-AS M-LDP inband signaling between client networks connected by an MPLS core network. 

e Inter-area MVPN or M-LDP inband signaling with non-segmented point-to-multipoint LSPs (seamless 


MPLS multicast). 


Starting from Junos OS Release 16.1, M-LDP can signal point-to-multipoint LSPs at ASBR or transit or 
egress when root address is a BGP route which is further recursively resolved over an MPLS LSP. 


Egress Join Translation and Pseudo Interface Handling 

At the egress LER, PIM notifies LDP of the (S,G) message to be signaled along with the LSP root. PIM 
creates a pseudo interface as the upstream interface for this (S,G) message. When an (S,G) prune message 
is received, this association is removed. 

Egress Splicing 


At the egress node of the core network, where the (S,G) join message from the downstream site is received, 
this join message is translated to M-LDP in-band signaling parameters and LDP is notified. Further, LSP 
teardown occurs when the (S,G) entry is lost, when the LSP root changes, or when the (S,G) entry is 
reachable over a PIM neighbor. 


Supported Functionality 
For M-LDP in-band signaling, Junos OS supports the following functionality: 
e Egress splicing of the PIM next hop with the LDP route 


e Ingress splicing of the PIM route with the LDP next hop 
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e Translation of PIM join messages to LDP point-to-multipoint LSP setup parameters 

e Translation of M-LDP in-band LSP parameters to set up PIM join messages 

e Statically configured and BGP protocol next hop-based LSP root detection 

e PIM (S,G) states in the PIM source-specific multicast (SSM) and anysource multicsast (ASM) ranges 
e Configuration statements on ingress and egress LERs to enable them to act as edge routers 

e IGMP join messages on LERs 

e Carrying IPv6é source and group address as opaque information toward an IPv4 root node 


e Static configuration to map an IPvé6 (S,G) to an IPv4 root address 


Unsupported Functionality 

For M-LDP in-band signaling, Junos OS does not support the following functionality: 
e Full support for PIM ASM 

e The mpls Isp point-to-multipoint ping command with an (S,G) option 

e Nonstop active routing (NSR) 

e Make-before-break (MBB) for PIM 

e IPvé LSP root addresses (LDP does not support IPv6 LSPs.) 

e Neighbor relationship between PIM speakers that are not directly connected 

e Graceful restart 

e PIM dense mode 


e PIM bidirectional mode 


LDP Functionality 


The PIM (S,G) information is carried as M-LDP opaque type-length-value (TLV) encodings. The 
point-to-multipoint FEC element consists of the root-node address. In the case of next-generation multicast 
VPNs (NGEN MVPNs), the point-to-multipoint LSP is identified by the root node address and the LSP ID. 


Egress LER Functionality 

On the egress LER, PIM triggers LDP with the following information to create a point-to-multipoint LSP: 
e Root node 

e (S,G) 

e Next hop 


PIM finds the root node based on the source of the multicast tree. If the root address is configured for 
this (S,G) entry, the configured address is used as the point-to-multipoint LSP root. Otherwise, the routing 
table is used to look up the route to the source. If the route to the source of the multicast tree is a 
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BGP-learned route, PIM retrieves the BGP next hop address and uses it as the root node for the 
point-to-multipoint LSP. 


LDP finds the upstream node based on the root node, allocates a label, and sends the label mapping to 
the upstream node. LDP does not use penultimate hop popping (PHP) for in-band M-LDP signaling. 


If the root addresses for the source of the multicast tree changes, PIM deletes the point-to-multipoint LSP 
and triggers LDP to create a new point-to-multipoint LSP. When this happens, the outgoing interface list 
becomes NULL, PIM triggers LDP to delete the point-to-multipoint LSP, and LDP sends a label withdraw 
message to the upstream node. 


Transit LSR Functionality 


The transit LSR advertises a label to the upstream LSR toward the source of the point-to-multipoint FEC 
and installs the necessary forwarding state to forward the packets. The transit LSR can be any M-LDP 
capable router. 


Ingress LER Functionality 
On the ingress LER, LDP provides the following information to PIM upon receiving the label mapping: 


e (S,G) 
e Flood next hop 


Then PIM installs the forwarding state. If the new branches are added or deleted, the flood next hop is 
updated accordingly. If all branches are deleted due to a label being withdrawn, LDP sends updated 
information to PIM. If there are multiple links between the upstream and downstream neighbors, the 
point-to-multipoint LSP is not load balanced. 


SEE ALSO 
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This example shows how to configure multipoint LDP (M-LDP) in-band signaling for multicast traffic, as 
an extension to the Protocol Independent Multicast (PIM) protocol or as a substitute for PIM. 


Requirements 
This example can be configured using the following hardware and software components: 
e Junos OS Release 13.2 or later 


e MX Series 5G Universal Routing Platforms or M Series Multiservice Edge Routers for the Provider Edge 
(PE) Routers 


e PTX Series Packet Transport Routers acting as transit label-switched routers 


e T Series Core Routers for the Core Routers 


NOTE: The PE routers could also be T Series Core Routers but that is not typical. Depending 
on your scaling requirements, the core routers could also be MX Series 5G Universal Routing 
Platforms or M Series Multiservice Edge Routers. The Customer Edge (CE) devices could be 
other routers or switches from Juniper Networks or another vendor. 


No special configuration beyond device initialization is required before configuring this example. 


Overview 


“CLI Quick Configuration” on page 1015 shows the configuration for all of the devices in Figure 86 on page 1015. 
The section “Step-by-Step Procedure” on page 1020 describes the steps on Device EgressPE. 
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Figure 86: M-LDP In-Band Signaling for Point-to-Multipoint LSPs Example Topology 
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CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


Device src1 


set logical-systems src1 interfaces fe-1/2/0 unit O family inet address 1.2.7.7/24 
set logical-systems src1 interfaces loO unit O family inet address 1.1.1.7/32 
set logical-systems src1 protocols ospf area 0.0.0.0 interface all 


Device IngressPE 


set interfaces so-0/1/2 unit O family inet address 192.168.93.9/28 
set interfaces fe-1/2/0 unit 0 family inet address 1.2.3.2/24 
set interfaces fe-1/2/0 unit 0 family mpls 
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set interfaces fe-1/2/1 unit 0 family inet address 1.2.5.2/24 

set interfaces fe-1/2/2 unit 0 family inet address 1.2.6.2/24 

set interfaces fe-1/2/2 unit 0 family mpls 

set interfaces fe-1/2/3 unit 0 family inet address 1.2.7.2/24 

set interfaces fe-1/3/1 unit 0 family inet address 192.168.219.9/28 

set interfaces loO unit O family inet address 1.1.1.2/32 

set protocols igmp interface fe-1/2/1.0 version 3 

set protocols igmp interface fe-1/2/1.0 static group 232.1.1.1 source 192.168.219.11 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp local-address 1.1.1.2 

set protocols bgp group ibgp family inet any 

set protocols bgp group ibgp family inet-vpn any 

set protocols bgp group ibgp neighbor 1.1.1.3 

set protocols bgp group ibgp neighbor 1.1.1.4 

set protocols bgp group ibgp neighbor 1.1.1.1 

set protocols ospf area 0.0.0.0 interface all 

set protocols Idp interface fe-1/2/0.0 

set protocols Idp interface fe-1/2/2.0 

set protocols Idp interface lo0.0 

set protocols Idp p2mp 

set protocols pim mldp-inband-signalling policy mldppim-ex 

set protocols pim rp static address 1.1.1.5 

set protocols pim interface fe-1/3/1.0 

set protocols pim interface lo0.0 

set protocols pim interface fe-1/2/0.21 

set protocols pim interface fe-1/2/3.0 

set protocols pim interface fe-1/2/1.0 

set protocols pim interface so-0/1/2.0 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 
orlonger 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 
orlonger 

set policy-options policy-statement mldppim-ex term B then accept 

set policy-options policy-statement mldppim-ex term A from source-address-filter 1.1.1.7/32 orlonger 

set policy-options policy-statement mldppim-ex term A from source-address-filter 1.2.7.0/24 orlonger 

set policy-options policy-statement mldppim-ex term A then accept 

set routing-options autonomous-system 64510 


Device EgressPE 
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set interfaces so-0/1/3 unit 0 point-to-point 

set interfaces so-0/1/3 unit O family inet address 192.168.92.9/28 

set interfaces fe-1/2/0 unit O family inet address 1.1.3.1/24 

set interfaces fe-1/2/0 unit O family mpls 

set interfaces fe-1/2/1 unit O family inet address 1.1.4.1/24 

set interfaces fe-1/2/2 unit O family inet address 1.1.6.1/24 

set interfaces fe-1/2/2 unit 0 family mpls 

set interfaces fe-1/3/0 unit O family inet address 192.168.209.9/28 

set interfaces loO unit O family inet address 1.1.1.1/32 

set routing-options autonomous-system 64510 

set protocols igmp interface fe-1/3/0.0 version 3 

set protocols igmp interface fe-1/3/0.0 static group 232.1.1.1 group-count 3 
set protocols igmp interface fe-1/3/0.0 static group 232.1.1.1 source 192.168.219.11 
set protocols igmp interface fe-1/3/0.0 static group 227.1.1.1 

set protocols igmp interface so-0/1/3.0 version 3 

set protocols igmp interface so-0/1/3.0 static group 232.1.1.1 group-count 2 
set protocols igmp interface so-0/1/3.0 static group 232.1.1.1 source 192.168.219.11 
set protocols igmp interface so-0/1/3.0 static group 232.2.2.2 source 1.2.7.7 
set protocols mpls interface fe-1/2/0.0 

set protocols mpls interface fe-1/2/2.0 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp local-address 1.1.1.1 

set protocols bgp group ibgp family inet any 

set protocols bgp group ibgp neighbor 1.1.1.2 

set protocols msdp local-address 1.1.1.1 

set protocols msdp peer 1.1.1.5 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface fe-1/2/0.0 

set protocols Idp interface fe-1/2/2.0 

set protocols Idp interface lo0.0 

set protocols Idp p2mp 

set protocols pim mldp-inband-signalling policy mldppim-ex 

set protocols pim rp local address 1.1.1.1 

set protocols pim rp local group-ranges 227.0.0.0/8 

set protocols pim rp static address 1.1.1.4 

set protocols pim rp static address 1.2.7.7 group-ranges 226.0.0.0/8 

set protocols pim interface lo0.0 

set protocols pim interface fe-1/3/0.0 

set protocols pim interface fe-1/2/0.0 

set protocols pim interface fe-1/2/1.0 

set protocols pim interface so-0/1/3.0 
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set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 
orlonger 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 
orlonger 

set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 1.1.1.2 

set policy-options policy-statement mldppim-ex term B then accept 

set policy-options policy-statement mldppim-ex term A from source-address-filter 1.2.7.0/24 orlonger 

set policy-options policy-statement mldppim-ex term A then accept 


Device p6 


set interfaces fe-1/2/0 unit O family inet address 1.1.6.6/24 
set interfaces fe-1/2/0 unit O family mpls 

set interfaces fe-1/2/1 unit O family inet address 1.2.6.6/24 
set interfaces fe-1/2/1 unit 0 family mpls 

set interfaces loO unit O family inet address 1.1.1.6/32 

set interfaces loO unit O family mpls 

set protocols ospf area 0.0.0.0 interface all 

set protocols Idp interface fe-1/2/0.0 

set protocols Idp interface fe-1/2/1.0 

set protocols Idp interface lo0.0 

set protocols Idp p2mp 


Device pr3 


set interfaces ge-0/3/1 unit 0 family inet address 192.168.215.9/28 

set interfaces fe-1/2/0 unit O family inet address 1.1.3.3/24 

set interfaces fe-1/2/0 unit O family mpls 

set interfaces fe-1/2/1 unit O family inet address 1.2.3.3/24 

set interfaces fe-1/2/1 unit 0 family mpls 

set interfaces loO unit O family inet address 1.1.1.3/32 

set protocols igmp interface ge-0/3/1.0 version 3 

set protocols igmp interface ge-0/3/1.0 static group 232.1.1.2 source 192.168.219.11 
set protocols igmp interface ge-0/3/1.0 static group 232.2.2.2 source 1.2.7.7 
set protocols bgp group ibgp local-address 1.1.1.3 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp neighbor 1.1.1.2 
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set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fe-1/2/1.0 metric 2 

set protocols Idp interface fe-1/2/0.0 

set protocols Idp interface fe-1/2/1.0 

set protocols Idp interface lo0.0 

set protocols Idp p2mp 

set protocols pim mldp-inband-signalling policy mldppim-ex 

set protocols pim interface fe-0/3/1.0 

set protocols pim interface lo0.0 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 
orlonger 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 
orlonger 

set policy-options policy-statement mldppim-ex term B then p2mp-Isp-root address 1.1.1.2 

set policy-options policy-statement mldppim-ex term B then accept 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.0.0/24 
orlonger 

set policy-options policy-statement mldppim-ex term B from source-address-filter 192.168.219.11/32 
orlonger 

set policy-options policy-statement mldppim-ex term B from source-address-filter 1.2.7.7/32 orlonger 

set policy-options policy-statement mldppim-ex term B then p2mp-lsp-root address 1.1.1.2 

set policy-options policy-statement mldppim-ex term B then accept 

set routing-options autonomous-system 64510 


Device pr4 


set interfaces ge-0/3/0 unit 0 family inet address 192.168.207.9/28 
set interfaces fe-1/2/0 unit O family inet address 1.1.4.4/24 

set interfaces fe-1/2/0 unit 0 family iso 

set interfaces loO unit O family inet address 1.1.1.4/32 

set protocols igmp interface ge-0/3/0.0 version 3 

set protocols igmp interface ge-0/3/0.0 static group 232.1.1.2 source 192.168.219.11 
set protocols igmp interface ge-0/3/0.0 static group 225.1.1.1 

set protocols bgp group ibgp local-address 1.1.1.4 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp neighbor 1.1.1.2 

set protocols msdp local-address 1.1.1.4 

set protocols msdp peer 1.1.1.5 

set protocols ospf area 0.0.0.0 interface all 

set protocols pim rp local address 1.1.1.4 


set protocols pim interface ge-0/3/0.0 

set protocols pim interface lo0.0 

set protocols pim interface fe-1/2/0.0 

set routing-options autonomous-system 64510 


Device pr5 


set interfaces fe-1/2/0 unit 0 family inet address 1.2.5.5/24 

set interfaces loO unit O family inet address 1.1.1.5/24 

set protocols igmp interface lo0.0 version 3 

set protocols igmp interface lo0.0 static group 232.1.1.1 source 192.168.219.11 
set protocols msdp local-address 1.1.1.5 

set protocols msdp peer 1.1.1.4 

set protocols msdp peer 1.1.1.1 

set protocols ospf area 0.0.0.0 interface all 

set protocols pim rp local address 1.1.1.5 

set protocols pim interface all 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device EgressPE: 


1. Configure the interfaces. 


Enable MPLS on the core-facing interfaces. On the egress next hops, you do not need to enable MPLS. 


[edit interfaces] 

user@EgressPE# set fe-1/2/0 unit 0 family inet address 1.1.3.1/24 
user@EgressPE# set fe-1/2/0 unit 0 family mpls 

user@EgressPE# set fe-1/2/2 unit 0 family inet address 1.1.6.1/24 
user@EgressPE# set fe-1/2/2 unit 0 family mpls 

user@EgressPE# set so-0/1/3 unit 0 point-to-point 

user@EgressPE# set so-0/1/3 unit 0 family inet address 192.168.92.9/28 
user@EgressPE# set fe-1/2/1 unit 0 family inet address 1.1.4.1/24 
user@EgressPE# set fe-1/3/0 unit 0 family inet address 192.168.209.9/28 
user@EgressPE# set loO unit O family inet address 1.1.1.1/32 
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2. Configure IGMP on the egress interfaces. 


For testing purposes, this example includes static group and source addresses. 


[edit protocols igmp] 

user@EgressPE# set interface fe-1/3/0.0 version 3 

user@EgressPE# set interface fe-1/3/0.0 static group 232.1.1.1 group-count 3 
user@EgressPE# set interface fe-1/3/0.0 static group 232.1.1.1 source 192.168.219.11 
user@EgressPE# set interface fe-1/3/0.0 static group 227.1.1.1 

user@EgressPE# set interface so-0/1/3.0 version 3 

user@EgressPE# set interface so-0/1/3.0 static group 232.1.1.1 group-count 2 
user@EgressPE# set interface so-0/1/3.0 static group 232.1.1.1 source 192.168.219.11 
user@EgressPE# set interface so-0/1/3.0 static group 232.2.2.2 source 1.2.7.7 


3. Configure MPLS on the core-facing interfaces. 


[edit protocols mpls] 
user@EgressPE# set interface fe-1/2/0.0 
user@EgressPE# set interface fe-1/2/2.0 


4. Configure BGP. 
BGP is a policy-driven protocol, so also configure and apply any needed routing policies. 


For example, you might want to export static routes into BGP. 


[edit protocols bgp group ibgp] 
user@EgressPE# set type internal 
user@EgressPE# set local-address 1.1.1.1 
user@EgressPE# set family inet any 
user@EgressPE# set neighbor 1.1.1.2 


5. (Optional) Configure an MSDP peer connection with Device pr5 in order to interconnect the disparate 
PIM domains, thus enabling redundant RPs. 


[edit protocols msdp] 
user@EgressPE# set local-address 1.1.1.1 
user@EgressPE# set peer 1.1.1.5 


6. Configure OSPF. 


[edit protocols ospf area 0.0.0.0] 
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user@EgressPE# set interface all 
user@EgressPE# set interface fxp0.0 disable 


7. Configure LDP on the core-facing interfaces and on the loopback interface. 


[edit protocols Idp] 

user@EgressPE# set interface fe-1/2/0.0 
user@EgressPE# set interface fe-1/2/2.0 
user@EgressPE# set interface lo0.0 


8. Enable point-to-multipoint MPLS LSPs. 


[edit protocols Idp] 
user@EgressPE# set p2mp 


9. Configure PIM on the downstream interfaces. 


[edit protocols pim] 

user@EgressPE# set interface lo0.0 
user@EgressPE# set interface fe-1/3/0.0 
user@EgressPE# set interface fe-1/2/1.0 
user@EgressPE# set interface so-0/1/3.0 


10. Configure the RP settings because this device serves as the PIM rendezvous point (RP). 


[edit protocols pim] 

user@EgressPE# set rp local address 1.1.1.1 

user@EgressPE# set rp local group-ranges 227.0.0.0/8 
user@EgressPE# set rp static address 1.1.1.4 

user@EgressPE# set rp static address 1.2.7.7 group-ranges 226.0.0.0/8 


11. Enable M-LDP in-band signaling and set the associated policy. 


[edit protocols pim] 
user@EgressPE# set mldp-inband-signalling policy mldppim-ex 


12. Configure the routing policy that specifies the root address for the point-to-multipoint LSP and the 
associated source addresses. 
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[edit policy-options policy-statement mldppim-ex] 

user@EgressPE# set term B from source-address-filter 192.168.0.0/24 orlonger 
user@EgressPE# set term B from source-address-filter 192.168.219.11/32 orlonger 
user@EgressPE# set term B then p2mp-Isp-root address 1.1.1.2 

user@EgressPE# set term B then accept 

user@EgressPE# set term A from source-address-filter 1.2.7.0/24 orlonger 
user@EgressPE# set term A then accept 


13. Configure the autonomous system (AS) ID. 


[edit routing-options] 
user@EgressPE# set autonomous-system 64510 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
show policy-options, and show routing-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


Device EgressPE 


user@EgressPE# show interfaces 
so-0/1/3 { 
unit O { 
point-to-point; 
family inet { 
address 192.168.92.9/28; 


} 
fe-1/2/0 { 
unit O { 
family inet { 
address 1.1.3.1/24; 
} 


family mpls; 


} 
fe-1/2/1 { 
unit O { 
family inet { 


address 1.1.4.1/24, 


} 
fe-1/2/2 { 
unit O { 
family inet { 
address 1.1.6.1/24; 
} 


family mpls; 


} 
fe-1/3/0 { 
unit O { 
family inet { 
address 192.168.209.9/28; 


} 
lo0 { 
unit O { 
family inet { 
address 1.1.1.1/32; 


user@EgressPE# show protocols 
igmp { 
interface fe-1/3/0.0 { 
version 3; 
static { 
group 232.1.1.1 { 
group-count 3; 
source 192.168.219.11; 
} 
group 227.1.1.1; 


} 
interface so-0/1/3.0 { 
version 3; 
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static { 
group 232.1.1.1 { 
group-count 2; 
source 192.168.219.11; 
} 
group 232.2.2.2 { 
source 1.2.7.7; 


} 
mpls { 
interface fe-1/2/0.0; 
interface fe-1/2/2.0, 
} 
bgp { 
group ibgp { 
type internal; 
local-address 1.1.1.1; 
family inet { 
any; 
} 
neighbor 1.1.1.2; 


} 
msdp { 
local-address 1.1.1.1; 
peer 1.1.1.5; 
} 
ospf { 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 


} 

Idp { 
interface fe-1/2/0.0; 
interface fe-1/2/2.0; 
interface 100.0; 
p2mp; 

} 

pim { 
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mldp-inband-signalling { 
policy mldppim-ex; 
} 
rp { 
local { 
address 1.1.1.1; 
group-ranges { 
227.0.0.0/8; 


} 
static { 
address 1.1.1.4; 
address 1.2.7.7 { 
group-ranges { 
226.0.0.0/8; 


} 

interface 100.0; 
interface fe-1/3/0.0; 
interface fe-1/2/0.0; 
interface fe-1/2/1.0; 
interface so-0/1/3.0; 


user@EgressPE# show policy-options 
policy-statement mldppim-ex { 
term B { 
from { 
source-address-filter 192.168.0.0/24 orlonger; 
source-address-filter 192.168.219.11/32 orlonger; 
} 
then { 
p2mp-lsp-root { 
address 1.1.1.2; 
} 


accept; 


} 
term A { 
from { 
source-address-filter 1.2.7.0/24 orlonger; 
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then accept; 


user@EgressPE# show routing-options 
autonomous-system 64510; 


Similarly, configure the other egress devices. 


If you are done configuring the devices, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


Checking the PIM Join States | 1027 

Checking the PIM Sources | 1032 

Checking the LDP Database | 1034 

Looking Up the Route Information for the MPLS Label | 1038 


Checking the LDP Traffic Statistics | 1039 


Confirm that the configuration is working properly. 


Checking the PIM Join States 


Purpose 


Display information about PIM join states to verify the M-LDP in-band upstream and downstream details. 
On the ingress device, the show pim join extensive command displays Pseudo-MLDP for the downstream 
interface. On the egress, the show pim join extensive command displays Pseudo-MLDP for the upstream 
interface. 


Action 


From operational mode, enter the show pim join extensive command. 





user@IngressPE> show pim join extensive 





Instance: PIM.master Family: INET 
R = Rendezvous Point Tree, S = Sparse, W = Wildcard 
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Geewiog 23261 oil ei 
Souwees 192. 168}, 219), Wi 
Flags: sparse,spt 
Upstream interface: fe-1/3/1.0 





Upstream neighbor: Direct 
Upstream state: Local Source 
Keepalive timeout: 

Ojol oa i Ko MAG O10 7) 





Downstream neighbors: 

Interface: Pseudo-MLDP 

Interface: fe-1/2/1.0 
1,2,.5,2 States Joim rilagss § LIMKSOWME 8 Iie MILE 
Usiimss iel 23°02 ima sames last worms iel 2Zas00s12 


eos 252 oi, 1.2 
Soummesas 192. WS}, 219). Wi 
Flags: sparse,spt 
Upstream interface: fe-1/3/1.0 





Upstream neighbor: Direct 
Upstream state: Local Source 
Keepalive timeout: 

Yieizaines ilel 22352) 359) 





Downstream neighbors: 


Interface: Pseudo-MLDP 


Geoujos Z2S2. i, i. 
Somwees 192 5 WSs, 29), ab 
Flags: sparse,spt 
Upstream interface: fe-1/3/1.0 





Upstream neighbor: Direct 
Upstream state: Local Source 
Keepalive timeout: 

Yereaines iel 223073 sil 





Downstream neighbors: 


Interface: Pseudo-MLDP 


Geewios ZIAcGoAck 
Souwees 1525757 
Flags: sparse,spt 
Upstream interface: fe-1/2/3.0 





Upstream neighbor: Direct 
Upstream state: Local Source 
Keepalive timeout: 

Urea? ilel 229 59)6'59) 


Downstream neighbors: 


Interface: Pseudo-MLDP 








user@EgressPE> show pim join extensive 


Instance: PIM.master Family: INET 





R = Rendezvous Point Tree, S = Sparse, W = Wildcard 





Grou: 227.1, ist 

SO UCC mes 
Nee i ips 
Flags: sparse, rptree, wildcard 
Upstream interface: Local 
Upstream neighbor: Local 
Upstream state: Local RP 
Ceres ilel Zsis ie zal 





Downstream neighbors: 

Interface: fe-1/3/0.0 
192 168.209 .9 SiaeSss wWoilin wilacgss Si WaimMSCwies Iimiewiagiciyy 
Usicaimes cl 2isilvezi Wile silines lhasic wosiag ikcl 2BOgil2s 35 


Geewjog: ZIA2o lel. i 
Souwees 192, 168}, 219), Wi 
Flags: sparse,spt 
Upstream protocol: MLDP 
Upstream interface: Pseudo MLDP 
Upstream neighbor: MLDP LSP root <1.1.1.2> 
Upstream state: Join to Source 
Keepalive timeout: 
Wireajmes ilel 23g is 27 
Downstream neighbors: 
Interface: so-0/1/3.0 
192,168 ,92.9 Sites volm Blagsse § Timeout: Infinity 
Usicimss lel 20si2esS wim saimes lhasit vormse ikel 2ZOsi2s35 
Downstream neighbors: 
Interface: fe-1/3/0.0 
192 168,209.09 States Woilm wilagss § Timeout: Infinity 
Usiimss: il 2Osi2es5 cima Games last vorme ilel 2ZOsi12935 


Exes Z2S2cl.l.2 
Soumsees W992 Ge 5 2108), ib 
Flags: sparse,spt 
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Upstream protocol: MLDP 
Upstream interface: Pseudo MLDP 
Upstream neighbor: MLDP LSP root <1.1.1.2> 
Upstream state: Join to Source 
Keepalive timeout: 
10} oy ops 11— ra Ko MAG eae ae 
Downstream neighbors: 
Interface: so-0/1/3.0 
192 ,.168.,92.,9 Sitates dolm wlaces Timeout: Infinity 
Wpistmel ss Tale ZO E25 ime ss En cem als teuOasnis mele ZO ple aSiS 
Downstream neighbors: 
Interface: fe-1/2/1.0 
1.1.4.4 State: Join Flags: S Timeout: 198 
Uptime: 1d 22:59:59 Time since last Join: 00:00:12 
Downstream neighbors: 
Interface: fe-1/3/0.0 
192,168 ,209.9 Sitace: Jolm Milage, S Timeout: Infinity 
Usicaimes iIcl 20sI2855 Wilms siines llasic wosiag ikel 2Ogl2s 35 


CroOuIOs A232. i,1.S 
Souwees 192, 168}, 219), Wb 
Flags: sparse,spt 
Upstream protocol: MLDP 
Upstream interface: Pseudo MLDP 
Upstream neighbor: MLDP LSP root <1.1.1.2> 
Upstream state: Join to Source 
Keepalive timeout: 
Uieames tel ZOSil2s 35 
Downstream neighbors: 
Interface: fe-1/3/0.0 
192,168 ,209.9 Stace: Joim milage: S Timeout: Infinity 
Ustwmes ie 2Osi2ssS wim samee last Jonums ikel Z2ZOgiazs 35 


EADS ZO2. 25 Bok 
Sourees 1s24757 
Flags: sparse,spt 
Upstream protocol: MLDP 
Upstream interface: Pseudo MLDP 
Upstream neighbor: MLDP LSP root <1.1.1.2> 
Upstream state: Join to Source 
Keepalive timeout: 
Ujsicamss iel 20siae 35 
Downstream neighbors: 


liner tace:sO— 0/0 
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192, ,.168,92.9 Siteees voli blagse § Timeout: Infinity 
Uewmes lel 2OsizssS wanes siumee llasit wening ikel 2Ogi125 35 


user@pr3> show pim join extensive 





Instance: PIM.master Family: INET 





R = Rendezvous Point Tree, S = Sparse, W = Wildcard 


Gxewiog ZI2oleleZ 
Soueeee i192), Ios 42109). ib 
Flags: sparse,spt 
Upstream protocol: MLDP 
Upstream interface: Pseudo MLDP 
Upstream neighbor: MLDP LSP root <1.1.1.2> 
Upstream state: Join to Source 
Keepalive timeout: 
Uptime: ld 20:14:40 


Downstream neighbors: 





Interface: Pseudo-—GMP 
ge-0/3/1.0 


ExCuwips Z2S2c2.262 
Sourees 1.242.767 
Flags: sparse,spt 
Upstream protocol: MLDP 
Upstream interface: Pseudo MLDP 
Upstream neighbor: MLDP LSP root <1.1.1.2> 
Upstream state: Join to Source 
Keepalive timeout: 
Uptime: ld 20:14:40 


Downstream neighbors: 





Interface: Pseudo-—GMP 
ge-0/3/1.0 


user@pr4> show pim join extensive 





Instance: PIM.master Family: INET 





R = Rendezvous Point Tree, S = Sparse, W = Wildcard 


eos 225.1, i. i 


Soumee: * 
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Ree oi, il.4 

Flags: sparse, rptree, wildcard 
Upstream interface: Local 
Upstream neighbor: Local 
Upstream state: Local RP 
Upieme we icleA Salsa 43 





Downstream neighbors: 

Interface: ge-0/3/0.0 
OOPS Z0W eo MSicate eu Onn tH lags oR Will sme OlteveseE mite embtaiey, 
Wpistmey el CIeZS SiS ime ss -EnGen als tuOusnsmee Cle Supe si 43 


Exeulog Z32cln.l.2 
Sourees 192, 168,219), Wi 
Flags: sparse,spt 
Upstream interface: fe-1/2/0.0 





Upstream neighbor: 1.1.4.1 

Upstream state: Local RP, Join to Source 
Keepalive timeout: 0 

Giereamnres ilel Zisie ise 4's) 





Downstream neighbors: 

Interface: ge-0/3/0.0 
192 168,207 .9 States voilm milage: § Timeout: Infinity 
Usicimss lel 23gilseds) aama samecs lhasic worms: ilel 2sgilss43 


user@pr5> show pim join extensive 


ge-0/3/1.0 





Instance: PIM.master Family: INET 





R = Rendezvous Point Tree, S = Sparse, W = Wildcard 


Instance: PIM.master Family: INET6 








R = Rendezvous Point Tree, S = Sparse, W = Wildcard 


Checking the PIM Sources 


Purpose 


Verify that the PIM sources have the expected M-LDP in-band upstream and downstream details. 


Action 


From operational mode, enter the show pim source command. 





user@IngressP 


E> show pim source 





Instance: PIM.master Family: INET 


Souscee iyi sil. 
Prefix 1, 
Upstream 


Upstream 


Soumee 1.267. 
Rie@izsig IL, 
Upstream 
Upstream 


Upstream 


SO URC EO ZG 
Rieeutase iL) 
Upstream 
Upstream 


Upstream 








il 
Lo hol /aZ 
interface Local 


neighbor Local 


7 

Zeya 

protocol MLDP 

interface Pseudo MLDP 

neighbor MLDP LSP root <1.1.1.2> 


a2. Li 

2 M68 219 0/23 

protocol MLDP 

interface Pseudo MLDP 

neighbor MLDP LSP root <1.1.1.2> 


user@EgressPE> show pim source 





Instance: PIM.master Family: INET 


Sours beA. 7. 


iPieeurais< IL, 


7 
2A Of BE 





Upstream 


Upstream 


Source 152457. 


iieeuras< Ik, 


interface fe-1/2/3.0 
Neighbor erie 


7 
2A Of ee 





Upstream 


Upstream 


SoOwece: 82. 16 
Prefix 19 


interface fe-1/2/3.0 


neighbor Direct 


oSlg ikl 
2 G3. 2190/23 





Upstream 


Upstream 


interface fe-1/3/1.0 
imealejaloyore IL9)2 . 1G}. ZL). 
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Soummee i1S)2. Se}, 21S), ILil 
Dissicise 192, 168,219 0/2) 
USES incariiace ta—i/3/ il. 0 


Upstream neighbor Direct 


user@pr3> show pim source 


Instance: PIM.master Family: INET 





Soucee be2.7o7 
Pincus 1.2.7 0/24 
Upstream protocol MLDP 





Upstream interface Pseudo MLDP 





Upstream neighbor MLDP LSP root <1.1.1.2> 


Srouusee) IS)2 1S ie} « 2A). IL iL 
Pieeiesds 192,168 ,219).,0/ 28 
Upstream protocol MLDP 


Upstream interface Pseudo MLDP 





Upstream neighbor MLDP LSP root <1.1.1.2> 


user@pr4> show pim source 


Instance: PIM.master Family: INET 





Source 1.1.1.4 
Pieeuewo Lil ,l.4/32 
Upstream interface Local 


Upstream neighbor Local 


Soumee W292). G8 . 2119), IL ib 
Pieeiensx 192168 .219 0/28 
Upstream interface fe-1/2/0.0 





Upstream neighbor 1.1.4.1 


Checking the LDP Database 


Purpose 
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Make sure that the show Idp database command displays the expected root-to-(S,G) bindings. 


Action 





user@IngressPE> show ldp database 


liggutc lelosil ceicaloase, 10.259 .2.22 /90——1 1.1.33 


Label Prefix 
300096 Deg ll Al hy Se 
S doled. S/3Z 
299856 Lodo. 6/32 
2297 6 LO. 255.2227 7/32 


@uiepuiewraly cumiclatealloals Sym O mee io een nO lel lie ger 0) 


Label Prefix 
300144 Lodo. 2/32 
ZO 97 6 Lele 3/32 
299856 Lodo. 6/32 
3 1.255 2.2214 32 


liggute ieloysil ceicaloase, I0.259.2.22 /90—=1 i. 14630 


Label Prefix 
ZIGISS Loko does 32 
ZoOoT 2. Lol sl. 3/32 
S Loi... 6/32 
299716 1@ 259 .2.227 4 32 


Output label database, 10.255.2.227:0--1.1.1.6:0 


Label Prefix 
300144 Lodo a/ 32 
BODY Ag Ml the, SYS 
299856 Lol. 6/32 
3 10.255 2562274 32 
300432 P2MP root-addr 1.1.1.2, grp: 232.2.2.2, sre: 1.2.7.7 
300288 P2MP root-addr 1.1.1.2, grp: 232.1.1.1, sre: 192.168.219.11 
300160 P2MP root-addr 1.1.1.2, grp: 232.1.1.2, sre: 192.168.219.11 
300480 P2MP root-addr 1.1.1.2, grp: 232.1.1.3, sre: 192.168.219.11 








user@EgressPE> show Idp database 


liste leloeil ceiceloase@, I,i1,1.,230=--1L,l,1.,33@ 
Label Prefix 
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300096 

3 
299856 
PENS) I TH) 
300144 
300128 


del yl ay s2 

dotted. S132 

doled 6/32 

10.255 45227 / 32 

P2MP root-addr 1.1.1.2, grp: 232.2.2.2, 
P2MP root-addr 1.1.1.2, grp: 232.1.1.2, 


Ourejoure lealosil ceiceloase, 1, -2ed——1,1,1. 530 


Label 
S 

2OOT TS 
299808 
2DSY 2 


Prefix 
Wet ed 2/32 
ded yl. B/S2 
dei, lk. 6/32 
10,255.25 227 32 


injure Melos ceiceloase, oil, 280=——1.t, 1,630) 


Label 
ADDING 
ADSI 2 

3 
Zou aikG) 
300128 
299984 
299952 
300176 
300192 


Prefix 

dei, kh. 2/32 

del yl. B/ 82 

dei, 6/32 

10. 25552.,227/ 32 

P2MP root-addr 1.1.1.2, grp: 232.2.2.2, 
P2MP root-addr 1.1.1.2, grp: 232.1.1.1, 
P2MP root-addr 1.1.1.2, grp: 232.1.1.2, 
P2MP root-addr 1.1.1.2, grp: 232.1.1.3, 
P2MP root-addr 1.1.1.2, grp: ff3e::1:2, 


OuEpuiabelNdatabalsic yur les dee 2210 lee en Or0) 


Label 
3 
29916 
299808 
BONNY 


Prefix 
ilpeesleets eee 
Lele S/S 
dei, lh. 6/32 
10.255..2,227/ 32 


logical-system: default 


ingest Ileloxeil cetceloase, 10.255.2 22 780——1.,1 153380 


Label 
300096 

S 
299856 
ZYOV TS 


Prefix 
del. day 32 
Lote S73 
dei tk Gf 32 
10.2552 5320 32 


OuEpuilabciNdacabasic; Om 2 Sor 22a OS eel ses) 


sre: 


sre: 


sre: 


sre: 


sre: 


sre: 


sre: 


1.2.7.7 
192.168.219.11 


1.2.7.7 
192.168.219.11 
192.168.219.11 
192.168.219.11 
abcd: :1:2:7:7 
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Label 
300144 
ZOOM T 
299856 

3 


Input label database, 


Label 
ZIGISS 
BIOONIDZ 

5 
BODY TS 


Output label database, 


Label 
300144 
2997716 
ADVE 

3 
300432 
300288 
300160 
300480 
300496 


Prefix 
dle ay Se, 
doled 3/32 
dood. 6/32 
10 0255.2 2274 32 


Prefix 
doth g hay Se 
dele 3/32 
doi, . 6/32 
10 0255.52 2274 32 


Prefix 

tote lay BZ 

Hh esl ghey SY Sie 

dol yl. 6/32 
10.255 ..2 02274 32 

P2MP root-addr 1.1.1.2, 
P2MP root-addr 1.1.1.2, 
P2MP root-addr 1.1.1.2, 
P2MP root-addr 1.1.1.2, 
P2MP root-addr 1.1.1.2, 


user@p6> show lIdp database 


Input label database, 


Label 
3 
ZONE 
299808 


Output label database, 


Label 
ZOO TS 
Zoo IZ 

S 


Prefix 
ile plac ee 
Wels o S732 
doled. 6/32 


Prefix 
doi. l. 2/32 
doled. S732 
doled 6/32 


user@pr3> show Idp database 


grp: 
grp: 
grp: 
grp: 
grp: 


Toile, Os0--Lo lida as@ 


10 4599). 2642080—-l oie oe) 


102599 52 0.4227 30-—1. lo lees 


232.2.2.2, 
232.1.1.1, 
232.1.1.2, 
232.1.1.3, 
ff£3e::1:2, 


Loiled posWo— ol. 230) 


sres 


sre: 


sres 


sre: 


sre: 


1.2.7.7 
192.168.219.11 
192.168.219.11 
192.168.219.11 
abcd: :1:2:7:7 
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1038 


inmjoue Ieloeil ceicelosse, 14,1. S30——L.l.1,480) 


Label Prefix 
3 otis dl ear 
ZOU TES Lslodko S/S2 
299808 Ll sl. 6/32 
ZOD G2 1.255 262214 32 


OuEpui abel databasic7 el ae Ss 30 = alee eZ) 


Label Prefix 
300096 Loi, l 2732 
3 Ah AL lle, SY See 
299856 Lil pl. 6/32 
BEY) TI TS) 10.2552 5227/32 
300144 P2MP root-addr 1.1.1.2, grp: 232.2.2.2, sre: 1.2.7.7 
300128 P2MP root-addr 1.1.1.2, grp: 232.1.1.2, src: 192.168.219.11 


ligsite Ieloeil cetceloase, 1, i,1,330——10,255.2.22730 


Label Prefix 
300144 Lol. 2/32 
ZXSVS) I TG) Loko dle 3/32 
299856 Lol. .6/32 
8 10 .255.2.227/ 32 


OuepuilabeclNidatabasc,y eal lens 30> Ot Zolom 2 zee) 


Label Prefix 
300096 elegl oar se 
3 tote lo Si BZ 
299856 1st. .6/32 
ZOO TS 10.255 .25227/ 32 


Looking Up the Route Information for the MPLS Label 


Purpose 


Display the point-to-multipoint FEC information. 


Action 








user@EgressPE> show route label 299808 detail 


mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden) 
299808 (1 entry, 1 announced) 


* LDP Preference: 9 
Next hop type: Flood 
Address: 0x931922c 





Next-hop reference count: 3 
Next hop type: Router, Next hop index: 1109 
Address: 0x9318b0c 





Next-hop reference count: 2 

Next hop: via so-0/1/3.0 

Label operation: Pop 

Next hop type: Router, Next hop index: 1110 
Adidise sis 0x Jeeta 





Next—-hop reference count: 2 
NESE Incjor 192,169. 209,11 wie 2S—1/3/0.0 


Label operation: Pop 





State: **Active Int AckRequest> 
Local AS: 1G) 
Age: 13:08:15 Macrae: i 





Validation State: unverified 
TES R ILD 
Announcement bits (1): O-KRT 
ASM patch iel 


FECs bound to route: P2MP root-addr 1.1.1.2, grp: 


192.168.219.11 


Checking the LDP Traffic Statistics 


Purpose 


Monitor the data traffic statistics for the point-to-multipoint LSP. 


Action 








user@EgressPE> show ldp traffic-statistics p2mp 


P2MP FEC Statistics: 








1 HOM Garelo) ommr- Lo lobar =) oMmuKey Ke hal oP ah aed) Nexthop Packets 
Shared 
Ms gd GAR OS eh ra Ih hs Ts H SO U/elysra0 0 
No 
11,1, 23232,1.,1,1, 192.168.219.111 se-0/1/3.0 0 
No 

fe-1/3/0.0 0 


232.1.1.1, 


Byes 


sre: 
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1,1 ,1,23232.,1.,1.,2, 192.168.219.111 se-0/1/3.0 0 0 
No 

fe-1/3/0.0 0 0 
No 

WiE=1/2/ 0. 14 0 0 
No 
1, sl,2s232,l,1,3,192.168,219,11 te-1/3/0.0 0 0 
No 
Ad er eee? eds flee ie fe-1/3/0.0 0 0 
No 

SEE ALSO 


Understanding Multipoint LDP Inband Signaling for Point-to-Multipoint LSPs | 1003 


LDP Mapping Server for Interoperability of Segment Routing with LDP Overview 


IN THIS SECTION 


@ Interoperability of Segment Routing with LDP Using OSPF | 1040 
@ Interoperability of Segment Routing with LDP Using ISIS | 1042 


In an LDP network with gradual deployment of segment routing, there can be islands of devices that 
support either only LDP, or only segment routing. For the devices to interwork, the LDP mapping server 
feature is required to be configured on any device in the segment routing network. 


The LDP mapping server feature is implemented using either OSPF or ISIS. 


Interoperability of Segment Routing with LDP Using OSPF 


To implement interoperability of segment routing with LDP using OSPF, an extended prefix link-state 
advertisement (LSA) with Range type, length, and value (TLV) for all the LDP prefixes is generated, and 
mapping routes corresponding to the prefix is installed in the inet.3 and mpls.O routing tables. 


Figure 87 on page 1041 is a simple LDP network topology used to illustrate the interoperability of segment 
routing devices with LDP devices using OSPF. The topology has six devices (Devices R1, R2, R3, R4, R5, 
and R6) with LDP-to-segment routing migration. 
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Figure 87: Sample LDP Topology with Interoperability of Segment Routing with LDP Using OSPF 


o_o _e_ ee 


R1 


9200431 


|—— Segment Routing — <¢———— LDP. / Segment Routing —-|-— LDP —| 


In the above topology, Devices R1, R2, and R3 are capable of only segment routing, Devices R5 and R6 
are capable of only LDP, and Device R4 supports both LDP and segment routing. Here, Device R1 cannot 
interwork with Device R6 because of interoperability issues. 


To enable interoperability between the LDP-capable devices and segment routing devices, any one interface 
of the device in the segment routing network segment is configured as the LDP mapping server. Currently, 
the mapping server configures prefixes under the [edit routing-options source-packet-routing] hierarchy 
level. With this feature, the LDP mapping server configuration if applied under the [edit protocols ospf] 
hierarchy level, where a new extended prefix LSA with range TLV for all LDP prefixes is advertised by 
OSPF. The device capable of segment routing analyze the extended prefix range TLV and mapping routes 
corresponding to the prefix are installed in the inet.3 and mpls.0O routing tables. 


For example, in Figure 87 on page 1041, if Device R2 (in the segment routing network) is the LDP mapping 
server, the following configuration is included: 


[edit routing-options] 

user@R2# set source-packet-routing mapping-server-entry mapping-server-nameprefix-segment-range prefix-range 
start-prefix loopback-address 

user@R2# set source-packet-routing mapping-server-entry mp1 prefix-segment-range rg1 start-index 5 

user@R2# set source-packet-routing mapping-server-entry mp1 prefix-segment-range rg1 size 1 


NOTE: The IP address used as the start-prefix is the loopback address of the device in the LDP 
network (Device R5, in this example). 


[edit protocols] 
user@R2# set ospf source-packet-routing mapping-server mapping-server-name 


When the LDP mapping server configuration is committed on Device R2, the extended prefix range TLV 
is flooded across the OSPF area. The devices capable of segment routing (Devices R1, R2, and R3) install 
OSPF segment routing routes for the specified loopback address with a segment ID (SID) index. The SID 
index is also updated in the mpls.0O routing table by the segment routing devices. 


Starting in Junos OS Release 19.1R1, segment routing-LDP border router can stitch segment routing traffic 
to LDP next-hop and vice versa. 
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Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using OSPF 


e Prefix conflict is only detected at the source configuration. When there is a prefix range conflict, the 
prefix SID from the lower router ID prevails. In such cases, a system log error 
message—RPD_OSPF_PFX_SID_RANGE_CONFLICT—is generated. 


e IPvé6 prefixes are not supported. 


e Flooding of the OSPF Extended Prefix Opaque LSA generated by the segment routing mapping server 
for autonomous systems (ASs) is not supported. 


e Inter-area LDP mapping server functionary is not supported. 
e ABR functionality of Extended Prefix Opaque LSA is not supported. 
e ASBR functionality of Extended Prefix Opaque LSA is not supported. 


e Segment routing mapping server Preference TLV is not supported. 


Interoperability of Segment Routing with LDP Using ISIS 


To implement interoperability of segment routing with LDP using ISIS, a server-client configuration is 
required under protocols ISIS and LDP, respectively, and routes from the inet.3 or inet.O routing tables 
are used for stitching of segment routing LSP with an LDP LSP and vice-versa. 


Figure 88 on page 1042 is a simple LDP network topology used to illustrate the interoperability of segment 
routing devices with LDP devices using an LDP mapping server-client feature. The topology has four 
provider edge (PE) devices (Devices PE1, PE2, PE3, and PE4) and four provider (P) devices (Devices P5, 
P6, P7, and P8). 


Figure 88: Sample LDP Topology with Interoperability of Segment Routing with LDP Using ISIS 
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Devices PE3, PE4, P6, P7 and P8 are the LDP capable devices. Devices PE1, PE2, P5 and Pé are capable 
of segment routing with segment routing global block (SRGB) value of 100 and 200, and node segment 
IDs (SIDs) value of 101, 102,105 and 106, respectively. 
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For a service flow to be tunneled to-and-from Device PE3 and Device PE1 using a continuous MPLS tunnel, 
the islands of devices supporting segment routing and LDP must interoperate. 


LDP Mapping Client Functionality (LDP to Segment Routing) 


The LDP client functionality is the LDP-to-segment routing mapping, that is the right-to-left traffic flow 
in Figure 88 on page 1042. On Device P6, an LDP egress policy is configured to advertise all node SIDs and 
prefix SIDs from the segment routing network on the left. As a result, on Device P6, LDP advertises Devices 
PE1, PE2 and P5 as the egress FEC label bindings to Device P7. 


Device PE3 has learned a service route with Device PE1 as the protocol next hop. Device PE3 has an LDP 
label binding from the P8 next hop for the PE1 FEC. As a result, Device PE3 sends its service packet to 
Device P8 as per classic LDP behavior. Device P8 has an LDP label binding from its P7 next hop for the 
PE1 FEC, therefore Device P8 forwards to Device P7 as per classic LDP behavior. 


Device P7 has an LDP label binding from its P6 next hop the PE1 FEC, as a result, Device P7 forwards to 
Device P6 as per classic LDP behavior. 


Device Péthat is acting as an LDP egress for the PE1 FEC, stitches and swaps the incoming egress LDP 
label for the PE1 FEC with an equivalent segment routing node SID (101 in this example) to forward the 
traffic to Device P5. 


Device P5 pops 101 SID assuming that Device PE1 advertised its node segment 101 with the 
penultimate-pop flag set, and then forwards traffic to Device PE1. Device PE1 receives the tunneled packet 
and processes the service label. 


As a result, the end-to-end MPLS tunnel is built from an LDP LSP from Device PE3 to Device P6, and the 
related node segment from Device P6 to Device PE1. 


LDP Mapping Server Functionality (Segment Routing to LDP) 


The LDP server functionality is the mapping of segment routing to LDP, that is the left-to-right traffic flow 
in Figure 88 on page 1042. On Device P6 the mapping server prefixes configuration is included under the 
[edit routing-options source-packet-routing] hierarchy level. When the configuration is applied under the 
specific IGP, the label binding type, length, and value (TLV) for all the LDP FEC-label bindings from the 
LDP network are advertised as inet.3 LDP routes. 


Here, Device P6 acts as a Segment Routing Mapping Server (SRMS) and advertises the following mappings 
- (P7, 107), (P8, 108), (PE3, 103), (PE4, 104), and (P7, 107). If segment routing was supported on Device 
PE3, the node SID 103 would have been configured on Device PE3. Because Device PE3 does not support 
segment routing, the policy is configured at the SRMS on Device P6, and Device P6 is responsible for 
advertising the mappings. 


These mapping server advertisements are only understood by the segment routing devices. The segment 
routing devices install the related node SIDs in the MPLS data plane exactly how the node segments had 
been advertised by the nodes themselves. For instance, Device PE1 installs the node SID 103 with P5 next 
hop exactly as if Device PE3 had advertised SID 103. 


Device PE1 has a service route with PES as its protocol next hop. Device PE1 has a node segment for that 
IGP route - 103 with P5 next hop. As a result, Device PE1 sends its service packet to Device P5 with two 
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labels - the bottom label, which is the service label, and the top label, which is SID 103. Device P5 swaps 
103 for 103 and forwards to Device P6. The next-hop for Device P6 is the IGP route PE3, which is not 
capable of segment routing. (Device P7 does not advertise the segment routing capability). However, 
Device P6é has an LDP label binding from that next hop for the same FEC (for example, LDP label 1037). 
As a result, on Device P6, the IGP swaps 103 for 1037 and forwards to Device P7. 


Device P7 swaps this label with the LDP-label received from Device P8, and then forwards it to Device 
P8. The LDP label is popped by Device P8 and forwarded to Device PE3. 


Device PE3 receives the tunneled packet and processes the service label. The end-to-end MPLS tunnel is 
built from a segment routing node from Devices PE1 to P6, and an LDP LSP from Devices P6 to PES. 


Segment Routing to LDP Stitching 


When the IGP segment routing LSP's IP next hop does not support segment routing, the IGP looks at the 
inet.3 routing table to see if there is an LDP LSP to the same prefix. If the LDP LSP is present, the IGP 
stitches the segment routing LSP to the LDP LSP by programming a MPLS transit route that swaps the 
segment routing label with the LDP label to switch traffic from segment routing domain to the LDP domain. 


Figure 89 on page 1044 illustrates the stitching of segment routing and LDP LSPs for enabling interoperability. 


Figure 89: Stitching Segment Routing and LDP LSPs 
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In the topology, Device PE3 is LDP-capable and does not support segment routing. The mapping server 
in the segment routing domain can advertise label binding TLV for devices P7, P8 and PE4. In sucha 
scenario, Device PE1 can have both prefix SID and remote label binding TLV and SID to reach Device PE4. 
However, Device PE1 prefers prefix SID over remote label binding TLV while programing its ingress 
segment routing route for Device PE4. As a result, Device PE1 uses the segment routing LSP end-to-end 
to send traffic to Device PE4, and uses the segment routing-to-LDP stitching while sending traffic to 
Device PES. 


Unsupported Features and Functionality for Interoperability of Segment Routing with LDP using ISIS 


e Penultimate-hop popping behaviour for label binding TLV is not supported. 


e Advertising of range of prefixes in label binding TLV is not supported. 
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e Segment Routing Conflict Resolution is not supported. 


e LDP traffic statistics does not work. 


e Nonstop active routing (NSR) and graceful Routing Engine switchover (GRES) is not supported. 


e ISIS inter-level is not supported. 


e RFC 7794, IS-IS Prefix Attributes for Extended IPv4 is not supported. 


e Redistributing LDP route as a prefix-sid at the stitching node is not supported. 


Configuring Miscellaneous LDP Properties 


IN THIS SECTION 


Configuring LDP to Use the IGP Route Metric | 1045 

Preventing Addition of Ingress Routes to the inet.0 Routing Table | 1046 
Multiple-Instance LDP and Carrier-of-Carriers VPNs | 1046 

Configuring MPLS and LDP to Pop the Label on the Ultimate-Hop Router | 1046 
Enabling LDP over RSVP-Established LSPs | 1047 

Enabling LDP over RSVP-Established LSPs in Heterogeneous Networks | 1047 
Configuring the TCP MD5 Signature for LDP Sessions | 1048 

Configuring LDP Session Protection | 1050 

Disabling SNMP Traps for LDP | 1050 

Configuring LDP Synchronization with the IGP on LDP Links | 1050 
Configuring LDP Synchronization with the IGP on the Router | 1051 
Configuring the Label Withdrawal Timer | 1051 

Ignoring the LDP Subnet Check | 1052 


The following sections describe how to configure a number of miscellaneous LDP properties: 


Configuring LDP to Use the IGP Route Metric 


Use the track-igp-metric statement if you want the interior gateway protocol (IGP) route metric to be 
used for the LDP routes instead of the default LDP route metric (the default LDP route metric is 1). 


To use the IGP route metric, include the track-igp-metric statement: 


track-igp-metric; 
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For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Preventing Addition of Ingress Routes to the inet.0 Routing Table 


By configuring the no-forwarding statement, you can prevent ingress routes from being added to the 
inet.O routing table instead of the inet.3 routing table even if you enabled the traffic-engineering bgp-igp 
statement at the [edit protocols mpls] or the [edit logical-systems logical-system-name protocols mpls] 
hierarchy level. By default, the no-forwarding statement is disabled. 


NOTE: ACX Series routers do not support [edit logical-systems] hierarchy level. 


To omit ingress routes from the inet.O routing table, include the no-forwarding statement: 


no-forwarding; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Multiple-Instance LDP and Carrier-of-Carriers VPNs 


By configuring multiple LDP routing instances, you can use LDP to advertise labels in a carrier-of-carriers 
VPN from a service provider provider edge (PE) router to a customer carrier customer edge (CE) router. 
This is especially useful when the carrier customer is a basic Internet service provider (ISP) and wants to 
restrict full Internet routes to its PE routers. By using LDP instead of BGP, the carrier customer shields its 
other internal routers from the Internet. Multiple-instance LDP is also useful when a carrier customer 
wants to provide Layer 2 or Layer 3 VPN services to its customers. 


For an example of how to configure multiple LDP routing instances for carrier-of-carriers VPNs, see the 
Multiple Instances for Label Distribution Protocol User Guide. 


Configuring MPLS and LDP to Pop the Label on the Ultimate-Hop Router 


The default advertised label is label 3 (Implicit Null label). If label 3 is advertised, the penultimate-hop 
router removes the label and sends the packet to the egress router. If ultimate-hop popping is enabled, 
label O (IPv4 Explicit Null label) is advertised. Ultimate-hop popping ensures that any packets traversing 
an MPLS network include a label. 


To configure ultimate-hop popping, include the explicit-null statement: 


explicit-null; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 
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NOTE: Juniper Networks routers queue packets based on the incoming label. Routers from 
other vendors might queue packets differently. Keep this in mind when working with networks 
containing routers from multiple vendors. 


For more information about labels, see “MPLS Label Overview” on page 422 and “MPLS Label Allocation” 


on page 422. 


Enabling LDP over RSVP-Established LSPs 


You can run LDP over LSPs established by RSVP, effectively tunneling the LDP-established LSP through 
the one established by RSVP. To do so, enable LDP on the 100.0 interface (see “Enabling and Disabling 
LDP” on page 868). You must also configure the LSPs over which you want LDP to operate by including 
the Idp-tunneling statement at the [edit protocols mpls label-switched-path Isp-name] hierarchy level: 


[edit] 
protocols { 
mopls { 
label-switched-path Isp-name { 
from source; 
to destination; 
Idp-tunneling; 
} 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 


for this statement. 


SEE ALSO 


Tunneling LDP LSPs in RSVP LSPs Overview | 862 


Enabling LDP over RSVP-Established LSPs in Heterogeneous Networks 


Some other vendors use an OSPF metric of 1 for the loopback address. Juniper Networks routers use an 
OSPF metric of 0 for the loopback address. This might require that you manually configure the RSVP metric 
when deploying LDP tunneling over RSVP LSPs in heterogeneous networks. 


When a Juniper Networks router is linked to another vendor’s router through an RSVP tunnel, and LDP 
tunneling is also enabled, by default the Juniper Networks router might not use the RSVP tunnel to route 
traffic to the LDP destinations downstream of the other vendor's egress router if the RSVP path has a 
metric of 1 larger than the physical OSPF path. 
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To ensure that LDP tunneling functions properly in heterogeneous networks, you can configure OSPF to 
ignore the RSVP LSP metric by including the ignore-Isp-metrics statement: 


ignore-Isp-metrics; 


You can configure this statement at the following hierarchy levels: 


e [edit protocols ospf traffic-engineering shortcuts] 


e [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts] 


NOTE: ACX Series routers do not support [edit logical-systems] hierarchy level. 


To enable LDP over RSVP LSPs, you also still need to complete the procedure in Section “Enabling LDP 
over RSVP-Established LSPs” on page 1047. 
Configuring the TCP MD5 Signature for LDP Sessions 


You can configure an MD5 signature for an LDP TCP connection to protect against the introduction of 
spoofed TCP segments into LDP session connection streams. 


A router using the MD5 signature option is configured with a password for each peer for which 
authentication is required. The password is stored encrypted. 


LDP hello adjacencies can still be created even when peering interfaces are configured with different 
security signatures. However, the TCP session cannot be authenticated and is never established. 


Starting in Junos OS Release 16.1R1, support for Hashed Message Authentication Code (HMAC) and MD5 
authentication for LDP sessions is extended from a per-session configuration to a subnet-match (that is, 
longest-prefix-match) configuration. 


The support for subnet-match authentication provides flexibility in configuring authentication for 
automatically targeted LDP (TLDP) sessions, making the deployment of remote loop-free alternate (LFA) 
and FEC 129 pseudowires easy. 


To configure an MD5 signature for an LDP TCP connection, include the session-group and 


authentication-key statement: 


session-group prefix-length { 
authentication-key authentication-key; 


Use the session-group statement to configure the address for the remote end of the LDP session. 


The md5-authentication-key (password) can be up to 69 characters long. Characters can include any ASCII 
strings. If you include spaces, enclose all characters in quotation marks. 
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You can also configure an authentication key update mechanism for the LDP routing protocol. This 
mechanism allows you to update authentication keys without interrupting associated routing and signaling 
protocols such as Open Shortest Path First (OSPF) and Resource Reservation Setup Protocol (RSVP). 


To configure the authentication key update mechanism, include the key-chain statement at the [edit 
security authentication-key-chains] hierarchy level, and specify the key option to create a keychain 
consisting of several authentication keys. 


[edit security authentication-key-chains] 
key-chain key-chain-name { 
key key { 
secret secret-data; 
start-time yyyy-mm-dd.hh:mmiss; 


To configure the authentication key update mechanism for the LDP routing protocol, include the 
authentication-key-chain statement at the [edit protocols Idp] hierarchy level to associate the protocol 
with the [edit security authentication-key-chains] authentication keys. You must also configure the 
authentication algorithm by including the authentication-algorithm algorithm statement the [edit protocols 
Idp] hierarchy level. 


[edit protocols Idp] 
group group-name { 
neighbor address { 
authentication-algorithm algorithm; 
authentication-key-chain key-chain-name; 


For more information about the authentication key update feature, see Configuring the Authentication Key 
Update Mechanism for BGP and LDP Routing Protocols. 
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Configuring LDP Session Protection 


An LDP session is normally created between a pair of routers that are connected by one or more links. 
The routers form one hello adjacency for every link that connects them and associate all the adjacencies 
with the corresponding LDP session. When the last hello adjacency for an LDP session goes away, the 
LDP session is terminated. You might want to modify this behavior to prevent an LDP session from being 
unnecessarily terminated and reestablished. 


You can configure the Junos OS to leave the LDP session between two routers up even if there are no 
hello adjacencies on the links connecting the two routers by configuring the session-protection statement. 
You can optionally specify a time in seconds using the timeout option. The session remains up for the 
duration specified as long as the routers maintain IP network connectivity. 


session-protection { 
timeout seconds; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section. 


Disabling SNMP Traps for LDP 
Whenever an LDP LSP makes a transition from up to down, or down to up, the router sends an SNMP 
trap. However, it is possible to disable the LDP SNMP traps on a router, logical system, or routing instance. 


For information about the LDP SNMP traps and the proprietary LDP MIB, see the SNMP MIB Explorer.. 


To disable SNMP traps for LDP, specify the trap disable option for the log-updown statement: 


log-updown { 
trap disable; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


Configuring LDP Synchronization with the IGP on LDP Links 


LDP is a protocol for distributing labels in non-traffic-engineered applications. Labels are distributed along 
the best path determined by the IGP. If synchronization between LDP and the IGP is not maintained, the 
LSP goes down. When LDP is not fully operational on a given link (a session is not established and labels 
are not exchanged), the IGP advertises the link with the maximum cost metric. The link is not preferred 
but remains in the network topology. 


LDP synchronization is supported only on active point-to-point interfaces and LAN interfaces configured 
as point-to-point under the IGP. LDP synchronization is not supported during graceful restart. 


To advertise the maximum cost metric until LDP is operational for synchronization, include the 
Idp-synchronization statement: 
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Idp-synchronization { 
disable; 


hold-time seconds; 


To disable synchronization, include the disable statement. To configure the time period to advertise the 
maximum cost metric for a link that is not fully operational, include the hold-time statement. 


For a list of hierarchy levels at which you can configure this statement, see the statement summary section 
for this statement. 


Configuring LDP Synchronization with the IGP on the Router 


You can configure the time the LDP waits before informing the IGP that the LDP neighbor and session for 
an interface are operational. For large networks with numerous FECs, you might need to configure a longer 
value to allow enough time for the LDP label databases to be exchanged. 


To configure the time the LDP waits before informing the IGP that the LDP neighbor and session are 
operational, include the igp-synchronization statement and specify a time in seconds for the 
holddown-interval option: 


igp-synchronization holddown-interval seconds; 


For a list of hierarchy levels at which you can configure this statement, see the statement summary section 
for this statement. 


Configuring the Label Withdrawal Timer 


The label withdrawal timer delays sending a label withdrawal message for a FEC to a neighbor. When an 
IGP link to a neighbor fails, the label associated with the FEC has to be withdrawn from all the upstream 
routers if the neighbor is the next hop for the FEC. After the IGP converges and a label is received from 
a new next hop, the label is readvertised to all the upstream routers. This is the typical network behavior. 
By delaying label withdrawal by a small amount of time (for example, until the IGP converges and the 
router receives a new label for the FEC from the downstream next hop), the label withdrawal and sending 
a label mapping soon could be avoided. The label-withdrawal-delay statement allows you to configure 
this delay time. By default, the delay is 60 seconds. 


If the router receives the new label before the timer runs out, the label withdrawal timer is canceled. 
However, if the timer runs out, the label for the FEC is withdrawn from all of the upstream routers. 


By default, LDP waits for 60 seconds before withdrawing labels to avoid resignaling LSPs multiple times 
while the IGP is reconverging. To configure the label withdrawal delay time in seconds, include the 
label-withdrawal-delay statement: 


label-withdrawal-delay seconds; 


1052 


For a list of hierarchy levels at which you can configure this statement, see the statement summary section 
for this statement. 


Ignoring the LDP Subnet Check 


In Junos OS Release 8.4 and later releases, an LDP source address subnet check is performed during the 
neighbor establishment procedure. The source address in the LDP link hello packet is matched against the 
interface address. This causes an interoperability issue with some other vendors’ equipment. 


To disable the subnet check, include the allow-subnet-mismatch statement: 


allow-subnet-mismatch; 


This statement can be included at the following hierarchy levels: 


e [edit protocols Idp interface interface-name] 


e [edit logical-systems logical-system-name protocols Idp interface interface-name] 


NOTE: ACX Series routers do not support [edit logical-systems] hierarchy level. 


Configuring LDP LSP Traceroute 


You can trace the route followed by an LDP-signaled LSP. LDP LSP traceroute is based on RFC 4379, 
Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures. This feature allows you to periodically 
trace all paths in a FEC. The FEC topology information is stored in a database accessible from the CLI. 


A topology change does not automatically trigger a trace of an LDP LSP. However, you can manually 
initiate a traceroute. If the traceroute request is for an FEC that is currently in the database, the contents 
of the database are updated with the results. 


The periodic traceroute feature applies to all FECs specified by the oam statement configured at the [edit 
protocols Idp] hierarchy level. To configure periodic LDP LSP traceroute, include the periodic-traceroute 
statement: 


periodic-traceroute { 
disable; 
exp exp-value; 
fanout fanout-value; 
frequency minutes; 
paths number-of-paths; 
retries retry-attempts; 
source address; 
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ttl ttl-value; 
wait seconds; 


You can configure this statement at the following hierarchy levels: 


e [edit protocols Idp oam] 


e [edit protocols Idp oam fec address] 
You can configure the periodic-traceroute statement by itself or with any of the following options: 


e exp—Specify the class of service to use when sending probes. 

e fanout—Specify the maximum number of next hops to search per node. 

e frequency—Specify the interval between traceroute attempts. 

e paths—Specify the maximum number of paths to search. 

e retries—Specify the number of attempts to send a probe to a specific node before giving up. 
e source—Specify the IPv4 source address to use when sending probes. 

e ttl—Specify the maximum time-to-live value. Nodes that are beyond this value are not traced. 


e wait—Specify the wait interval before resending a probe packet. 


Collecting LDP Statistics 


IN THIS SECTION 


@ LDP Statistics Output | 1054 
@ Disabling LDP Statistics on the Penultimate-Hop Router | 1055 
@ LDP Statistics Limitations | 1055 


LDP traffic statistics show the volume of traffic that has passed through a particular FEC on a router. 


When you configure the traffic-statistics statement at the [edit protocols Idp] hierarchy level, the LDP 
traffic statistics are gathered periodically and written to a file. You can configure how often statistics are 
collected (in seconds) by using the interval option. The default collection interval is 5 minutes. You must 
configure an LDP statistics file; otherwise, LDP traffic statistics are not gathered. If the LSP goes down, 
the LDP statistics are reset. 


To collect LDP traffic statistics, include the traffic-statistics statement: 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 


traffic-statistics { 


file filename <files number> <size size> <world-readable | no-world-readable>; 


interval interval; 


no-penultimate-hop; 


for this statement. 


This section includes the following topics: 


LDP Statistics Output 


The following sample output is from an LDP statistics file: 
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The LDP statistics file includes the following columns of data: 


e FEC—FEC for which LDP traffic statistics are collected. 


e Type—Type of traffic originating from a router, either Ingress (originating from this router) or Transit 


(forwarded through this router). 


Shared 








00:00:00 seconds 


Packets—Number of packets passed by the FEC since its LSP came up. 


Bytes—Number of bytes of data passed by the FEC since its LSP came up. 


Shared—A Yes value indicates that several prefixes are bound to the same label (for example, when 
several prefixes are advertised with an egress policy). The LDP traffic statistics for this case apply to all 


the prefixes and should be treated as such. 


read—This number (which appears next to the date and time) might differ from the actual number of 
the statistics displayed. Some of the statistics are summarized before being displayed. 
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Disabling LDP Statistics on the Penultimate-Hop Router 


Gathering LDP traffic statistics at the penultimate-hop router can consume excessive system resources, 
on next-hop routes in particular. This problem is exacerbated if you have configured the deaggregate 
statement in addition to the traffic-statistics statement. For routers reaching their limit of next-hop route 
usage, we recommend configuring the no-penultimate-hop option for the traffic-statistics statement: 


traffic-statistics { 
no-penultimate-hop; 


For a list of hierarchy levels at which you can configure the traffic-statistics statement, see the statement 
summary section for this statement. 


NOTE: When you configure the no-penultimate-hop option, no statistics are available for the 
FECs that are the penultimate hop for this router. 


Whenever you include or remove this option from the configuration, the LDP sessions are taken 
down and then restarted. 


The following sample output is from an LDP statistics file showing routers on which the no-penultimate-hop 
option is configured: 














FEC Type Packets Bytes Shared 
10.255 4245 28/32 Transit 0 0 No 
Ingress 4 246 No 
IM) 2554245 221 / 32 Transit statistics disabled 
Ingress statistics disabled 
IS oll .0/24 Transit statistics disabled 
Ingress statistics disabled 
IS hp S.0/24 Transit statistics disabled 
Ingress statistics disabled 











LDP Statistics Limitations 
The following are issues related to collecting LDP statistics by configuring the traffic-statistics statement: 
e You cannot clear the LDP statistics. 


e If you shorten the specified interval, a new LDP statistics request is issued only if the statistics timer 
expires later than the new interval. 
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e Anew LDP statistics collection operation cannot start until the previous one has finished. If the interval 
is short or if the number of LDP statistics is large, the time gap between the two statistics collections 
might be longer than the interval. 


When an LSP goes down, the LDP statistics are reset. 


Tracing LDP Protocol Traffic 


IN THIS SECTION 


@ ‘Tracing LDP Protocol Traffic at the Protocol and Routing Instance Levels | 1056 
@ Tracing LDP Protocol Traffic Within FECs | 1057 
@ Examples: Tracing LDP Protocol Traffic | 1058 


The following sections describe how to configure the trace options to examine LDP protocol traffic: 


Tracing LDP Protocol Traffic at the Protocol and Routing Instance Levels 


To trace LDP protocol traffic, you can specify options in the global traceoptions statement at the [edit 
routing-options] hierarchy level, and you can specify LDP-specific options by including the traceoptions 
statement: 


traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 


flag flag <flag-modifier> <disable>; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 


for this statement. 


Use the file statement to specify the name of the file that receives the output of the tracing operation. All 
files are placed in the directory /var/log. We recommend that you place LDP-tracing output in the file 
Idp-log. 


The following trace flags display the operations associated with the sending and receiving of various LDP 
messages. Each can carry one or more of the following modifiers: 


e address—Trace the operation of address and address withdrawal messages. 
e binding—Trace label-binding operations. 
e error—Trace error conditions. 


e event—Trace protocol events. 
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initialization—Trace the operation of initialization messages. 


label—Trace the operation of label request, label map, label withdrawal, and label release messages. 


notification—Trace the operation of notification messages. 


packets—Trace the operation of address, address withdrawal, initialization, label request, label map, label 
withdrawal, label release, notification, and periodic messages. This modifier is equivalent to setting the 
address, initialization, label, notification, and periodic modifiers. 


You can also configure the filter flag modifier with the match-on address sub-option for the packets 
flag. This allows you to trace based on the source and destination addresses of the packets. 


path—Trace label-switched path operations. 


path—Trace label-switched path operations. 


periodic—Trace the operation of hello and keepalive messages. 


e route—Trace the operation of route messages. 


e state—Trace protocol state transitions. 


Tracing LDP Protocol Traffic Within FECs 


LDP associates a forwarding equivalence class (FEC) with each LSP it creates. The FEC associated with an 
LSP specifies which packets are mapped to that LSP. LSPs are extended through a network as each router 
chooses the label advertised by the next hop for the FEC and splices it to the label it advertises to all other 
routers. 


You can trace LDP protocol traffic within a specific FEC and filter LDP trace statements based on an FEC. 
This is useful when you want to trace or troubleshoot LDP protocol traffic associated with an FEC. The 
following trace flags are available for this purpose: route, path, and binding. 


The following example illustrates how you might configure the LDP traceoptions statement to filter LDP 
trace statements based on an FEC: 


[edit protocols Idp traceoptions] 
set flag route filter match-on fec policy "filter-policy-for-ldp-fec"; 


This feature has the following limitations: 


e The filtering capability is only available for FECs composed of IP version 4 (IPv4) prefixes. 
e Layer 2 circuit FECs cannot be filtered. 


e When you configure both route tracing and filtering, MPLS routes are not displayed (they are blocked 
by the filter). 
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e Filtering is determined by the policy and the configured value for the match-on option. When configuring 
the policy, be sure that the default behavior is always reject. 


e The only match-on option is fec. Consequently, the only type of policy you should include is a route-filter 
policy. 


Examples: Tracing LDP Protocol Traffic 


Trace LDP path messages in detail: 


[edit] 
protocols { 


Idp { 
traceoptions { 
file Idp size 10m files 5; 
flag path; 


Trace all LDP outgoing messages: 


[edit] 
protocols { 
Idp { 
traceoptions { 
file Idp size 10m files 5; 
flag packets; 


Trace all LDP error conditions: 


[edit] 
protocols { 


Idp { 
traceoptions { 


file Idp size 10m files 5; 
flag error; 


Trace all LDP incoming messages and all label-binding operations: 


[edit] 
protocols { 
Idp { 
traceoptions { 
file Idp size 10m files 5 world-readable; 
flag packets receive; 
flag binding; 
} 


interface all { 


} 


Trace LDP protocol traffic for an FEC associated with the LSP: 


[edit] 
protocols { 


Idp { 
traceoptions { 
flag route filter match-on fec policy filter-policy-for-Idp-fec; 


Release History Table 


Release Description 


19.1 Starting in Junos OS Release 19.1R1, segment routing-LDP border router can stitch segment routing 


traffic to LDP next-hop and vice versa. 


16.1R1 Starting in Junos OS Release 16.1R1, support for Hashed Message Authentication Code (HMAC) 
and MD5 authentication for LDP sessions is extended from a per-session configuration to a 
subnet-match (that is, longest-prefix-match) configuration. 


or egress when root address is a BGP route which is further recursively resolved over an MPLS 


16.1 Starting from Junos OS Release 16.1, M-LDP can signal point-to-multipoint LSPs at ASBR or transit 
LSP. 
14.1 Starting in Junos OS Release 14.1, in order to migrate existing IPTV services from native IP multicast 


to MPLS multicast, you need to smoothly transition from PIM to M-LDP point-to-multipoint LSPs 


with minimal outage. 
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MPLS and Traffic Engineering 


Traffic engineering allows you to control the path that data packets follow, bypassing the standard routing 
model, which uses routing tables. Traffic engineering moves flows from congested links to alternate links 
that would not be selected by the automatically computed destination-based shortest path. With traffic 
engineering, you can: 


e Make more efficient use of expensive long-haul fibers. 
e Control how traffic is rerouted in the face of single or multiple failures. 


e Classify critical and regular traffic on a per-path basis. 


The core of the traffic engineering design is based on building label-switched paths (LSPs) among routers. 
An LSP is connection-oriented, like a virtual circuit in Frame Relay or ATM. LSPs are not reliable: Packets 
entering an LSP do not have delivery guarantees, although preferential treatment is possible. LSPs also 
are similar to unidirectional tunnels in that packets entering a path are encapsulated in an envelope and 
switched across the entire path without being touched by intermediate nodes. LSPs provide fine-grained 
control over how packets are forwarded in a network. To provide reliability, an LSP can use a set of primary 
and secondary paths. 


LSPs can be configured for BGP traffic only (traffic whose destination is outside of an autonomous system 
[AS]). In this case, traffic within the AS is not affected by the presence of LSPs. LSPs can also be configured 
for both BGP and interior gateway protocol (IGP) traffic; therefore, both intra-AS and inter-AS traffic is 
affected by the LSPs. 


MPLS Traffic Engineering and Signaling Protocols Overview 


Traffic engineering facilitates efficient and reliable network operations while simultaneously optimizing 
network resources and traffic performance. Traffic engineering provides the ability to move traffic flow 
away from the shortest path selected by the interior gateway protocol (IGP) to a potentially less congested 
physical path across a network. To support traffic engineering, besides source routing, the network must 
do the following: 


e Compute a path at the source by taking into account all the constraints, such as bandwidth and 
administrative requirements. 


e Distribute the information about network topology and link attributes throughout the network once the 
path is computed. 


e Reserve network resources and modify link attributes. 


When transit traffic is routed through an IP network, MPLS is often used to engineer its passage. Although 
the exact path through the transit network is of little importance to either the sender or the receiver of 
the traffic, network administrators often want to route traffic more efficiently between certain source and 
destination address pairs. By adding a short label with specific routing instructions to each packet, MPLS 
switches packets from router to router through the network rather than forwarding packets based on 
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next-hop lookups. The resulting routes are called label-switched paths (LSPs). LSPs control the passage of 
traffic through the network and speed traffic forwarding. 


You can create LSPs manually, or through the use of signaling protocols. Signaling protocols are used within 
an MPLS environment to establish LSPs for traffic across a transit network. Junos OS supports two signaling 
protocols—LDP and the Resource Reservation Protocol (RSVP). 


MPLS traffic engineering uses the following components: 


e MPLS LSPs for packet forwarding 
e IGP extensions for distributing information about the network topology and link attributes 
e Constrained Shortest Path First (CSPF) for path computation and path selection 


e RSVP extensions to establish the forwarding state along the path and to reserve resources along the 
path 


Junos OS also supports traffic engineering across different OSPF regions. 


Traffic Engineering Capabilities 


The task of mapping traffic flows onto an existing physical topology is called traffic engineering. Traffic 
engineering provides the ability to move traffic flow away from the shortest path selected by the interior 
gateway protocol (IGP) and onto a potentially less congested physical path across a network. 


Traffic engineering provides the capabilities to do the following: 


e Route primary paths around known bottlenecks or points of congestion in the network. 


Provide precise control over how traffic is rerouted when the primary path is faced with single or multiple 
failures. 


e Provide more efficient use of available aggregate bandwidth and long-haul fiber by ensuring that subsets 
of the network do not become overutilized while other subsets of the network along potential alternate 
paths are underutilized. 


e Maximize operational efficiency. 


Enhance the traffic-oriented performance characteristics of the network by minimizing packet loss, 
minimizing prolonged periods of congestion, and maximizing throughput. 


Enhance statistically bound performance characteristics of the network (such as loss ratio, delay variation, 


and transfer delay) required to support a multiservices Internet. 


Components of Traffic Engineering 


In the Junos® operating system (OS), traffic engineering is implemented with MPLS and RSVP. Traffic 


engineering is composed of four functional components: 


e Packet Forwarding Component on page 1071 
e Information Distribution Component 
e Path Selection Component 


e Signaling Component 


Configuring Traffic Engineering for LSPs 


IN THIS SECTION 
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Using RSVP and LDP Routes for Forwarding but Not Route Selection | 1066 


Advertising the LSP Metric in Summary LSAs | 1067 


When you configure an LSP, a host route (a 32-bit mask) is installed in the ingress router toward the egress 
router; the address of the host route is the destination address of the LSP. The bgp option for the traffic 
engineering statement at the [edit protocols mpls] hierarchy level is enabled by default (you can also 
explicitly configure the bgp option), allowing only BGP to use LSPs in its route calculations. The other 
traffic-engineering statement options allow you to alter this behavior in the master routing instance. This 
functionality is not available for specific routing instances. Also, you can enable only one of the 
traffic-engineering statement options (bgp, bgp-igp, bgp-igp-both-ribs, or mpls-forwarding) at a time. 


NOTE: Enabling or disabling any of the traffic-engineering statement options causes all the 
MPLS routes to be removed and then reinserted into the routing tables. 


You can configure OSPF and traffic engineering to advertise the LSP metric in summary link-state 
advertisements (LSAs) as described in the section “Advertising the LSP Metric in Summary LSAs” on page 1067. 


The following sections describe how to configure traffic engineering for LSPs: 


Using LSPs for Both BGP and IGP Traffic Forwarding 


You can configure BGP and the IGPs to use LSPs for forwarding traffic destined for egress routers by 
including the bgp-igp option for the traffic-engineering statement. The bgp-igp option causes all inet.3 
routes to be moved to the inet.O routing table. 


On the ingress router, include bgp-igp option for the traffic-engineering statement: 
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traffic-engineering bgp-igp; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


NOTE: The bgp-igp option for the traffic-engineering statement cannot be configured for 
VPN). VPNs require that routes be in the inet.3 routing table. 


Using LSPs for Forwarding in Virtual Private Networks 


VPNs require that routes remain in the inet.3 routing table to function properly. For VPNs, configure the 
bgp-igp-both-ribs option of the traffic-engineering statement to cause BGP and the IGPs to use LSPs for 
forwarding traffic destined for egress routers. The bgp-igp-both-ribs option installs the ingress routes in 
both the inet.O routing table (for IPv4 unicast routes) and the inet.3 routing table (for MPLS path 
information). 


On the ingress router, include the traffic-engineering bgp-igp-both-ribs statement: 


traffic-engineering bgp-igp-both-ribs; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


When you use the bgp-igp-both-ribs statement, the routes from the inet.3 table get copied into the inet.O 
table. The copied routes are LDP-signaled or RSVP-signaled, and are likely to have a lower preference 
than other routes in inet.0. Routes with a lower preference are more likely to be chosen as the active 
routes. This can be a problem because routing policies only act upon active routes. To prevent this problem, 
use the mpls-forwarding option instead. 


Using RSVP and LDP Routes for Forwarding but Not Route Selection 


If you configure the bgp-igp or bgp-igp-both-ribs options for the traffic-engineering statement, high-priority 
LSPs can supersede IGP routes in the inet.O routing table. IGP routes might no longer be redistributed 
since they are no longer the active routes. 


If you configure the mpls-forwarding option for the traffic-engineering statement, LSPs are used for 
forwarding but are excluded from route selection. These routes are added to both the inet.0 and inet.3 
routing tables. LSPs in the inet.O routing table are given a low preference when the active route is selected. 
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However, LSPs in the inet.3 routing table are given a normal preference and are therefore used for selecting 
forwarding next hops. 


When you activate the mpls-forwarding option, routes whose state is ForwardingOnly are preferred for 
forwarding even if their preference is lower than that of the currently active route. To examine the state 
of a route, execute a show route detail command. 


To use LSPs for forwarding but exclude them from route selection, include the mpls-forwarding option 
for the traffic-engineering statement: 


traffic-engineering mpls-forwarding; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


When you configure the mpls-forwarding option, IGP shortcut routes are copied to the inet.O routing 
table only. 


Unlike the bgp-igp-both-ribs option, the mpls-forwarding option allows you to use the LDP-signaled and 
RSVP-signaled routes for forwarding, and keep the BGP and IGP routes active for routing purposes so 
that routing policies can act upon them. 


For example, suppose a router is running BGP and it has a BGP route of 10.10.10.1/32 that it needs to 
send to another BGP speaker. If you use the bgp-igp-both-ribs option, and your router also has a 
label-switched-path (LSP) to 10.10.10.1, the MPLS route for 10.10.10.1 becomes active in the inet.O 
routing table. This prevents your router from advertising the 10.10.10.1 route to the other BGP router. 
On the other hand, if you use the mpls-forwarding option instead of the bgp-igp-both-ribs option, the 
10.10.10.1/32 BGP route is advertised to the other BGP speaker, and the LSP is still used to forward traffic 
to the 10.10.10.1 destination. 


Advertising the LSP Metric in Summary LSAs 


You can configure MPLS and OSPF to treat an LSP as a link. This configuration allows other routers in the 
network to use this LSP. To accomplish this goal, you need to configure MPLS and OSPF traffic engineering 
to advertise the LSP metric in summary LSAs. 


For MPLS, include the traffic-engineering bgp-igp and label-switched-path statements: 


traffic-engineering bgp-igp; 
label-switched-path Isp-name { 
to address; 


You can include these statements at the following hierarchy levels: 
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e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


For OSPF, include the Isp-metric-into-summary statement: 


Isp-metric-into-summary; 


You can include this statement at the following hierarchy levels: 


e [edit protocols ospf traffic-engineering shortcuts] 


e [edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts] 


For more information about OSPF traffic engineering, see the Junos OS Routing Protocols Library. 


Enabling Interarea Traffic Engineering 


The Junos OS can signal a contiguous traffic-engineered LSP across multiple OSPF areas. The LSP signaling 
must be done using either nesting or contiguous signaling, as described in RFC 4206, Label-Switched Paths 
(LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE). However, 
contiguous signaling support is limited to just basic signaling. Reoptimization is not supported with 
contiguous signaling. 


The following describes some of the interarea traffic engineering features: 


e Interarea traffic engineering can be enabled when the loose-hop area border routers (ABRs) are configured 
on the ingress router using CSPF for the Explicit Route Object (ERO) calculation within an OSPF area. 
ERO expansion is completed on the ABRs. 


e Interarea traffic engineering can be enabled when CSPF is enabled, but without ABRs specified in the 
LSP configuration on the ingress router (ABRs can be automatically designated). 


e Differentiated Services (DiffServ) traffic engineering is supported as long as the class type mappings are 
uniform across multiple areas. 


To enable interarea traffic engineering, include the expand-loose-hop statement in the configuration for 


each LSP transit router: 


expand-loose-hop; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 
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Enabling Inter-AS Traffic Engineering for LSPs 
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Generally, traffic engineering is possible for LSPs that meet the following conditions: 


e Both ends of the LSP are in the same OSPF area or at the same IS-IS level. 


e The two ends of the LSP are in different OSPF areas within the same autonomous system (AS). LSPs 
that end in different IS-IS levels are not supported. 


e The two ends of an explicit-path LSP are in different OSPF ASs and the autonomous system border 
routers (ASBRs) are configured statically as the loose hops supported on the explicit-path LSP. For more 
information, see “Configuring Explicit-Path LSPs” on page 564. 


Without statically defined ASBRs on LSPs, traffic engineering is not possible between one routing domain, 
or AS, and another. However, when the ASs are under the control of single service provider, it is possible 
in some cases to have traffic engineered LSPs span the ASs and dynamically discover the OSPF ASBRs 
linking them (IS-IS is not supported with this feature). 


Inter-AS traffic engineered LSPs are possible as long as certain network requirements are met, none of 
the limiting conditions apply, and OSPF passive mode is configured with EBGP. Details are provided in the 
following sections: 


Inter-AS Traffic Engineering Requirements 


The proper establishment and functioning of inter-AS traffic engineered LSPs depend on the following 
network requirements, all of which must be met: 


e All ASs are under control of a single service provider. 


e OSPF is used as the routing protocol within each AS, and EBGP is used as the routing protocol between 
the ASs. 


e ASBR information is available inside each AS. 


e EBGP routing information is distributed by OSPF, and an IBGP full mesh is in place within each AS. 
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e Transit LSPs are not configured on the inter-AS links, but are configured between entry and exit point 
ASBRs on each AS. 


e The EBGP link between ASBRs in different ASs is a direct link and must be configured as a passive traffic 
engineering link under OSPF. The remote link address itself, not the loopback or any other link address, 
is used as the remote node identifier for this passive link. For more information about OSPF passive 
traffic engineering mode configuration, see “Configuring OSPF Passive TE Mode” on page 1070. 


In addition, the address used for the remote node of the OSPF passive traffic engineering link must be the 
same as the address used for the EBGP link. For more information about OSPF and BGP in general, see 
the Junos OS Routing Protocols Library. 


Inter-AS Traffic Engineering Limitations 


Only LSP hierarchical, or nested, signaling is supported for inter-AS traffic engineered LSPs. Only 
point-to-point LSPs are supported (there is no point-to-multipoint support). 


In addition, the following limitations apply. Any one of these conditions is sufficient to render inter-AS 
traffic engineered LSPs impossible, even if the above requirements are met. 


e The use of multihop BGP is not supported. 


e The use of policers or topologies that prevent BGP routes from being known inside the AS is not 
supported. 


e Multiple ASBRs on a LAN between EBGP peers are not supported. Only one ASBR on a LAN between 
EBGP peers is supported (others ASBRs can exist on the LAN, but cannot be advertised). 


e Route reflectors or policies that hide ASBR information or prevent ASBR information from being 
distributed inside the ASs are not supported. 


e Bidirectional LSPs are not supported (LSPs are unidirectional from the traffic engineering perspective). 


e Topologies with both inter-AS and intra-AS paths to the same destination are not supported. 
In addition, several features that are routine with all LSPs are not supported with inter-AS traffic engineering: 


e Admin group link colors are not supported. 

e Secondary standby is not supported. 

e Reoptimization is not supported. 

e Crankback on transit routers is not supported. 
e Diverse path calculation is not supported. 


e Graceful restart is not supported. 


These lists of limitations or unsupported features with inter-AS traffic engineered LSPs are not exhaustive. 


Configuring OSPF Passive TE Mode 


Ordinarily, interior routing protocols such as OSPF are not run on links between ASs. However, for inter-AS 
traffic engineering to function properly, information about the inter-AS link, in particular, the address on 
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the remote interface, must be made available inside the AS. This information is not normally included either 
in EBGP reachability messages or in OSPF routing advertisements. 


To flood this link address information within the AS and make it available for traffic engineering calculations, 
you must configure OSPF passive mode for traffic engineering on each inter-AS interface. You must also 
supply the remote address for OSPF to distribute and include in the traffic engineering database. 


To configure OSPF passive mode for traffic engineering on an inter-AS interface, include the passive 
statement for the link at the [edit protocols ospf area area-id interface interface-name] hierarchy level: 


passive { 
traffic-engineering { 
remote-node-id ip-address; /* IP address at far end of inter-AS link */ 


OSPF must be properly configured on the router. The following example configures the inter-AS link 
so-1/1/0 to distribute traffic engineering information with OSPF within the AS. The remote IP address is 
192.168.207.2. 


[edit protocols ospf area 0.0.0.0] 
interface so-1/1/0 { 
unit O { 
passive { 
traffic-engineering { 
remote-node-id 192.168.207.2; 


Packet Forwarding Component 
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The packet forwarding component of the Junos traffic engineering architecture is MPLS, which is responsible 
for directing a flow of IP packets along a predetermined path across a network. This path is called a 
label-switched path (LSP). LSPs are simplex; that is, the traffic flows in one direction from the head-end 
(ingress) router to a tail-end (egress) router. Duplex traffic requires two LSPs: one LSP to carry traffic in 
each direction. An LSP is created by the concatenation of one or more label-switched hops, allowing a 
packet to be forwarded from one router to another across the MPLS domain. 


When an ingress router receives an IP packet, it adds an MPLS header to the packet and forwards it to 
the next router in the LSP. The labeled packet is forwarded along the LSP by each router until it reaches 
the tail end of the LSP, the egress router. At this point the MPLS header is removed, and the packet is 
forwarded based on Layer 3 information such as the IP destination address. The value of this scheme is 
that the physical path of the LSP is not limited to what the IGP would choose as the shortest path to reach 
the destination IP address. 


Packet Forwarding Based on Label Swapping 


The packet forwarding process at each router is based on the concept of label swapping. This concept is 
similar to what occurs at each Asynchronous Transfer Mode (ATM) switch in a permanent virtual circuit 
(PVC). Each MPLS packet carries a 4-byte encapsulation header that contains a 20-bit, fixed-length label 
field. When a packet containing a label arrives at a router, the router examines the label and copies it as 
an index to its MPLS forwarding table. Each entry in the forwarding table contains an interface-inbound 
label pair mapped to a set of forwarding information that is applied to all packets arriving on the specific 
interface with the same inbound label. 


How a Packet Traverses an MPLS Backbone 


This section describes how an IP packet is processed as it traverses an MPLS backbone network. 


At the entry edge of the MPLS backbone, the IP header is examined by the ingress router. Based on this 
analysis, the packet is classified, assigned a label, encapsulated in an MPLS header, and forwarded toward 
the next hop in the LSP. MPLS provides a high degree of flexibility in the way that an IP packet can be 
assigned to an LSP. For example, in the Junos traffic engineering implementation, all packets arriving at 
the ingress router that are destined to exit the MPLS domain at the same egress router are forwarded 
along the same LSP. 


Once the packet begins to traverse the LSP, each router uses the label to make the forwarding decision. 
The MPLS forwarding decision is made independently of the original IP header: the incoming interface 
and label are used as lookup keys into the MPLS forwarding table. The old label is replaced with a new 
label, and the packet is forwarded to the next hop along the LSP. This process is repeated at each router 
in the LSP until the packet reaches the egress router. 


When the packet arrives at the egress router, the label is removed and the packet exits the MPLS domain. 
The packet is then forwarded based on the destination IP address contained in the packet's original IP 
header according to the traditional shortest path calculated by the IP routing protocol. 


Information Distribution Component 


Traffic engineering requires detailed knowledge about the network topology as well as dynamic information 
about network loading. To implement the information distribution component, simple extensions to the 
IGPs are defined. Link attributes are included as part of each router’s link-state advertisement. 1S-IS 
extensions include the definition of new type length values (TLVs), whereas OSPF extensions are 
implemented with opaque link-state advertisements (LSAs). The standard flooding algorithm used by the 
link-state IGPs ensures that link attributes are distributed to all routers in the routing domain. Some of the 
traffic engineering extensions to be added to the IGP link-state advertisement include maximum link 
bandwidth, maximum reserved link bandwidth, current bandwidth reservation, and link coloring. 


Each router maintains network link attributes and topology information in a specialized traffic engineering 
database. The traffic engineering database is used exclusively for calculating explicit paths for the placement 
of LSPs across the physical topology. A separate database is maintained so that the subsequent traffic 
engineering computation is independent of the IGP and the IGP’s link-state database. Meanwhile, the IGP 
continues its operation without modification, performing the traditional shortest-path calculation based 
on information contained in the router’s link-state database. 


Path Selection Component 


After network link attributes and topology information are flooded by the IGP and placed in the traffic 
engineering database, each ingress router uses the traffic engineering database to calculate the paths for 
its own set of LSPs across the routing domain. The path for each LSP can be represented by either a strict 
or loose explicit route. An explicit route is a preconfigured sequence of routers that should be part of the 
physical path of the LSP. If the ingress router specifies all the routers in the LSP, the LSP is said to be 
identified by a strict explicit route. If the ingress router specifies only some of the routers in the LSP, the 
LSP is described as a loose explicit route. Support for strict and loose explicit routes allows the path 
selection process to be given broad latitude whenever possible, but to be constrained when necessary. 


The ingress router determines the physical path for each LSP by applying a Constrained Shortest Path 
First (CSPF) algorithm to the information in the traffic engineering database. CSPF is a shortest-path-first 
algorithm that has been modified to take into account specific restrictions when the shortest path across 
the network is calculated. Input into the CSPF algorithm includes: 


e Topology link-state information learned from the IGP and maintained in the traffic engineering database 


e Attributes associated with the state of network resources (such as total link bandwidth, reserved link 
bandwidth, available link bandwidth, and link color) that are carried by IGP extensions and stored in the 
traffic engineering database 


e Administrative attributes required to support traffic traversing the proposed LSP (such as bandwidth 
requirements, maximum hop count, and administrative policy requirements) that are obtained from user 
configuration 


As CSPF considers each candidate node and link for a new LSP, it either accepts or rejects a specific path 
component based on resource availability or whether selecting the component violates user policy 
constraints. The output of the CSPF calculation is an explicit route consisting of a sequence of router 
addresses that provides the shortest path through the network that meets the constraints. This explicit 
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route is then passed to the signaling component, which establishes the forwarding state in the routers 
along the LSP. 


Signaling Component 


An LSP is not known to be workable until it is actually established by the signaling component. The signaling 
component, which is responsible for establishing LSP state and distributing labels, relies on a number of 
extensions to RSVP: 


e The Explicit Route object allows an RSVP path message to traverse an explicit sequence of routers that 
is independent of conventional shortest-path IP routing. The explicit route can be either strict or loose. 


e The Label Request object permits the RSVP path message to request that intermediate routers provide 
a label binding for the LSP that it is establishing. 


e The Label object allows RSVP to support the distribution of labels without changing its existing 
mechanisms. Because the RSVP Resv message follows the reverse path of the RSVP path message, the 
Label object supports the distribution of labels from downstream nodes to upstream nodes. 


Offline Path Planning and Analysis 


Despite the reduced management effort resulting from online path calculation, an offline planning and 
analysis tool is still required to optimize traffic engineering globally. Online calculation takes resource 
constraints into account and calculates one LSP at a time. The challenge with this approach is that it is not 
deterministic. The order in which LSPs are calculated plays a critical role in determining each LSP’s physical 
path across the network. LSPs that are calculated early in the process have more resources available to 
them than LSPs calculated later in the process because previously calculated LSPs consume network 
resources. If the order in which the LSPs are calculated is changed, the resulting set of physical paths for 
the LSPs also can change. 


An offline planning and analysis tool simultaneously examines each link’s resource constraints and the 
requirements of each LSP. Although the offline approach can take several hours to complete, it performs 
global calculations, compares the results of each calculation, and then selects the best solution for the 
network as a whole. The output of the offline calculation is a set of LSPs that optimizes utilization of 
network resources. After the offline calculation is completed, the LSPs can be established in any order 
because each is installed according to the rules for the globally optimized solution. 


Flexible LSP Calculation and Configuration 


Traffic engineering involves mapping traffic flow onto a physical topology. You can determine the paths 
online using constraint-based routing. Regardless of how the physical path is calculated, the forwarding 
state is installed across the network through RSVP. 


The Junos OS supports the following ways to route and configure an LSP: 


e You can calculate the full path for the LSP offline and individually configure each router in the LSP with 
the necessary static forwarding state. This is analogous to the way some Internet service providers (ISPs) 
configure their |P-over-ATM cores. 


e You can calculate the full path for the LSP offline and statically configure the ingress router with the full 
path. The ingress router then uses RSVP as a dynamic signaling protocol to install a forwarding state in 
each router along the LSP. 


e You can rely on constraint-based routing to perform dynamic online LSP calculation. You configure the 
constraints for each LSP; then the network itself determines the path that best meets those constraints. 
Specifically, the ingress router calculates the entire LSP based on the constraints and then initiates 
signaling across the network. 


e You can calculate a partial path for an LSP offline and statically configure the ingress router with a subset 
of the routers in the path; then you can permit online calculation to determine the complete path. 


For example, consider a topology that includes two east-west paths across the United States: one in the 
north through Chicago and one in the south through Dallas. If you want to establish an LSP between a 
router in New York and one in San Francisco, you can configure the partial path for the LSP to include 
a single loose-routed hop of a router in Dallas. The result is an LSP routed along the southern path. The 
ingress router uses CSPF to compute the complete path and RSVP to install the forwarding state along 
the LSP. 


e You can configure the ingress router with no constraints whatsoever. In this case, normal IGP shortest-path 
routing is used to determine the path of the LSP. This configuration does not provide any value in terms 
of traffic engineering. However, it is easy and might be useful in situations when services such as virtual 
private networks (VPNs) are needed. 


In all these cases, you can specify any number of LSPs as backups for the primary LSP, thus allowing you 
to combine more than one configuration approach. For example, you might explicitly compute the primary 
path offline, set the secondary path to be constraint-based, and have the tertiary path be unconstrained. 
If a circuit on which the primary LSP is routed fails, the ingress router notices the outage from error 
notifications received from a downstream router or by the expiration of RSVP soft-state information. Then 
the router dynamically forwards traffic to a hot-standby LSP or calls on RSVP to create a forwarding state 
for a new backup LSP. 


Link-State Distribution Using BGP Overview 
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Role of an Interior Gateway Protocol 


An interior gateway protocol (IGP) is a type of protocol used for exchanging routing information between 


devices within an autonomous system (AS). Based on the method of computing the best path to a 


destination, the IGPs are divided into two categories: 


Link-state protocols—Advertise information about the network topology (directly connected links and 
the state of those links) to all routers using multicast addresses and triggered routing updates until all 
the routers running the link-state protocol have identical information about the internetwork. The best 
path to a destination is calculated based on constraints such as maximum delay, minimum available 
bandwidth, and resource class affinity. 


OSPF and IS-IS are examples of link-state protocols. 


Distance vector protocols—Advertise complete routing table information to directly connected neighbors 
using a broadcast address. The best path is calculated based on the number of hops to the destination 
network. 


RIP is an example of a distance vector protocol. 


As the name implies, the role of an IGP is to provide routing connectivity within or internal to a given 


routing domain. A routing domain is a set of routers under common administrative control that share a 


common routing protocol. An AS can consist of multiple routing domains, where IGP functions to advertise 


and learn network prefixes (routes) from neighboring routers to build a route table that ultimately contains 


entries for all sources advertising reachability for a given prefix. IGP executes a route selection algorithm 


to select the best path between the local router and each destination, and provides full connectivity among 


the routers making up a routing domain. 


In addition to advertising internal network reachability, IGPs are often used to advertise routing information 


that is external to that IGP's routing domain through a process known as route redistribution. Route 


redistribution is the process of exchanging routing information among distinct routing protocols to tie 


multiple routing domains together when intra-AS connectivity is desired. 


Limitations of an Interior Gateway Protocol 


While each individual IGP has its own advantages and limitations, the biggest limitations of IGP in general 
are performance and scalability. 


IGPs are designed to handle the task of acquiring and distributing network topology information for traffic 
engineering purposes. While this model has served well, IGPs have inherent scaling limitations when it 
comes to distributing large databases. IGPs can autodetect neighbors, with which they acquire intra-area 
network topology information. However, the link-state database or a traffic engineering database has the 
scope of a single area or AS, thereby limiting applications, such as end-to-end traffic engineering, the 
benefit of having external visibility to make better decisions. 


For label-switched networks, such as MPLS and Generalized MPLS (GMPLS), most existing traffic engineering 
solutions work in a single routing domain. These solutions do not work when a route from the ingress node 
to the egress node leaves the routing area or AS of the ingress node. In such cases, the path computation 
problem becomes complicated because of the unavailability of the complete routing information throughout 
the network. This is because service providers usually choose not to leak routing information beyond the 
routing area or AS for scalability constraints and confidentiality concerns. 


Need for Spanning Link-State Distribution 


One of the limitations of IGP is its inability to span link-state distribution outside a single area or AS. 
However, spanning link-state information acquired by an IGP across multiple areas or ASs has the following 
needs: 


e LSP path computation—This information is used to compute the path for MPLS LSPs across multiple 
routing domains, for example an inter-area TE LSP. 


e External path computing entities—External path computing entities, such as Application Layer Traffic 
Optimization (ALTO) and Path Computation Elements (PCE), perform path computations based on the 
network topology and current state of connections within the network, including traffic engineering 
information. This information is typically distributed by IGPs within the network. 


However, because the external path computing entities cannot extract this information from the IGPs, 


they perform network monitoring to optimize network services. 


Using BGP as a Solution 
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Overview 


To meet the needs for spanning link-state distribution across multiple domains, an exterior gateway protocol 
(EGP) is required to collect link-state and traffic engineering information from an IGP area, share it with 
external component, and use it for computing paths for interdomain MPLS LSPs. 
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BGP is a standardized EGP designed to exchange routing and reachability information between autonomous 
systems (ASs). BGP is a proven protocol that has better scaling properties because it can distribute millions 
of entries (for example, VPN prefixes) in a scalable fashion. BGP is the only routing protocol in use today 
that is suited to carry all of the routes in the Internet. This is largely because BGP runs on top of TCP and 
can make use of TCP flow control. In contrast, the internal gateway protocols (IGPs) do not have flow 
control. When IGPs have too much route information, they begin to churn. When BGP has a neighboring 
speaker that is sending information too quickly, BGP can throttle down the neighbor by delaying TCP 
acknowledgments. 


Another benefit of BGP is that it uses type, length, value (TLV) tuples and network layer reachability 
information (NLRI) that provide seemingly endless extensibility without the need for the underlying protocol 
to be altered. 


The distribution of link-state information across domains is regulated using policies to protect the interests 
of the service provider. This requires a control over the topology distribution using policies. BGP with its 
implemented policy framework serves well in the interdomain route distribution. In Junos OS, BGP is 
completely policy driven. The operator must explicitly configure neighbors to peer with and explicitly 
accept routes into BGP. Furthermore, routing policy is used to filter and modify routing information. Thus, 
routing policies provide complete administrative control over the routing tables. 


Although, within an AS, both IGP-TE and BGP-TE provide the same set of information, BGP-TE has better 
scaling characteristics that are inherited from the standard BGP protocol. This makes BGP-TE a more 
scalable choice for acquiring multi-area/multi-AS topology information. 


By using BGP as a solution, the I|GP-acquired information is used for distribution into BGP. The ISPs can 
selectively expose this information with other ISPs, service providers, and content distribution networks 
(CDNs) through normal BGP peering. This allows for aggregation of the IGP-acquired information across 
multiple areas and ASs, such that an external path computing entity can access the information by passively 
listening to a route reflector. 


Implementation 
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In Junos OS, the IGPs install topology information into a database called the traffic engineering database. 
The traffic engineering database contains the aggregated topology information. To install IGP topology 
information into traffic engineering database, use the set igp-topology configuration statement at the 
[edit protocols isis traffic-engineering] and [edit protocols ospf traffic-engineering] hierarchy levels. The 
mechanism to distribute link-state information using BGP includes the process of advertising the traffic 
engineering database into BGP-TE (import), and installing entries from BGP-TE into the traffic engineering 
database (export). 


Figure 90: Junos OS Implementation of BGP Link-State Distribution 
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Traffic Engineering Database Import 


To advertise the traffic engineering database into BGP-TE, the link and node entries in the traffic engineering 
database are converted in the form of routes. These converted routes are then installed by the traffic 
engineering database on behalf of the corresponding IGP, into a user-visible routing table called Isdist.0, 
on conditions subject to route policies. The procedure of leaking entries from the traffic engineering 
database into Isdist.0 is called traffic engineering database import as illustrated in Figure 90 on page 1079. 


There are polices to govern the traffic engineering database import process. By default, no entries are 
leaked from the traffic engineering database into the Isdist.O table. 


Starting in Junos OS Release 17.4R1, the traffic engineering database installs interior gateway protocol 
(IGP) topology information in addition to RSVP-TE topology information in the Isdist.0 routing table as 
illustrated in Figure 90 on page 1079. Prior to Junos OS Release 17.4R1, the traffic engineering database 
only exported RSVP-TE topology information. Now you can monitor both IGP and traffic engineering 
topology information. The BGP-LS reads IGP entries from Isdist.0 and advertises these entries to the BGP 
peers. To import IGP topology information into BGP-LS from Isdist.0, use the set bgp-Is configuration 
statement at the [edit protocols mpls traffic-engineering database import igp-topology] hierarchy level. 


Traffic Engineering Database Export 


BGP can be configured to export or advertise routes from the Isdist.0 table, subject to policy. This is 
common for any kind of route origination in BGP. In order to advertise BGP-TE into the traffic engineering 
database, BGP needs to be configured with the BGP-TE address family, and an export policy that selects 
routes for redistribution into BGP. 


BGP then propagates these routes like any other NLRI. BGP peers that have the BGP-TE family configured 
and negotiated receive BGP-TE NLRIs. BGP stores the received BGP-TE NLRIs in the form of routes in 
the Isdist.0 table, which is the same table that stores locally originated BGP-TE routes. The BGP-installed 
routes in Isdist.0 are then distributed to other peers like any other route. Thus, the standard route selection 
procedure applies to BGP-TE NLRIs received from multiple speakers. 


To achieve interdomain TE, the routes in Isdist.0 are leaked into the traffic engineering database through 
a policy. This process is called traffic engineering database export as illustrated in Figure 90 on page 1079. 


There are polices to govern the traffic engineering database export process. By default, no entries are 
leaked from the Isdist.O table into the traffic engineering database. 


NOTE: For SDN applications, such as PCE and ALTO, the BGP-TE advertised information cannot 
leak into the traffic engineering database of a router. In such cases, an external server that peers 
with the routers using BGP-TE is used to move topology information up into the sky/orchestration 
system that spans the network. These external servers can be deemed as BGP-TE consumers, 
where they receive BGP-TE routes, but do not advertise them. 


Assigning Credibility Values 


Once the entries are installed in the traffic engineering database, the BGP-TE learned information is made 
available for CSPF path computation. The traffic engineering database uses a protocol preference scheme 
that is based on credibility values. A protocol with a higher credibility value is preferred over a protocol 
with a lower credibility value. BGP-TE has the capability to advertise information learned from multiple 
protocols at the same time, and so in addition to the IGP-installed entries in the traffic engineering database, 
there can be BGP-TE installed entries that correspond to more than one protocol. The traffic engineering 
database export component creates a traffic engineering database protocol and credibility level for each 
protocol that BGP-TE supports. These credibility values are configurable in the CLI. 


1080 


The credibility order for the BGP-TE protocols is as follows: 


e Unknown—80 
e OSPF—81 

e ISIS Level 1—82 
e ISIS Level 2—83 
e Static—84 


e Direct—85 


Cross-Credibility Path Computation 


After you assign credibility values, each credibility level is treated as an individual plane. The Constrained 
Shorted Path First algorithm starts with the highest assigned credibility to the lowest, finding a path within 
that credibility level. 


With BGP-TE, it is essential to compute paths across credibility levels to compute inter-AS paths. For 
example, different credibility settings are seen on a device from area O that computes the path through 
area 1, because area O entries are installed by OSPF, and area 1 entries are installed by BGP-TE. 


To enable path computation across credibility levels, include the cross-credibility-cspf statement at the 
edit protocols mpls, [edit protocols mpls label-switched-path Isp-name], and [edit protocols rsvp] hierarchy 
levels. At the [edit protocols rsvp] hierarchy level, enabling cross-credibility-cspf impacts bypass LSPs and 
loose hop expansion in transit. 


Configuring cross-credibility-cspf enables path computation across credibility levels using the Constrained 
Shortest Path First algorithm, wherein the constraint is not performed on a credibility-by-credibility basis, 
but as a single constraint ignoring the assigned credibility values. 


BGP-TE NLRIs and TLVs 


Like other BGP routes, BGP-TE NLRIs can also be distributed through a route reflector that speaks BGP-TE 
NLRI. Junos OS implements the route reflection support for the BGP-TE family. 


The following is a list of supported NLRIs: 


e Link NLRI 
e Node NLRI 
e |Pv4 Prefix NLRI (receive and propagate) 


e IPv6 Prefix NLRI (receive and propagate) 


NOTE: Junos OS does not provide support for the route-distinguisher form of the above NRLIs. 
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The following is a list of supported fields in link and node NLRIs: 


Protocol-ID—NLRI originates with the following protocol values: 
e ISIS-L1 

e ISIS-L2 

e OSPF 


Identifier—This value is configurable. By default, the identifier value is set to O. 

Local/Remote node descriptor—These include: 

e Autonomous system 

e BGP-LS Identifier—This value is configurable. By default, the BGP-LS identifier value is set to 0 
e Area-ID 

e IGP router-ID 


Link descriptors (Only for link NLRI)—This includes: 
e Link Local/Remote Identifiers 

e IPv4 interface address 

e IPv4 neighbor address 


e IPv6é neighbor/interface address—The IPvé6 neighbor and interface addresses are not originated, but 
only stored and propagated when received. 


e Multi-topology ID—This value is not originated, but stored and propagated when received. 


The following is a list of supported LINK_STATE attribute TLVs: 


Link attributes: 
e Administrative group 


Max link bandwidth 


Max reservable bandwidth 


Unreserved bandwidth 


TE default metric 


e SRLG 

e The following TLVs, which are not originated, but only stored and propagated when received: 
e Opaque link attributes 
e MPLS protocol mask 


e Metric 
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e Link protection type 


e Link name attribute 


e Node attributes: 

e IPv4 Router-ID 

e Node flag bits—Only the overload bit is set. 

e The following TLVs, which are not originated, but only stored and propagated when received: 
e Multi-topology 
e OSPF-specific node properties 
e Opaque node properties 
e Node name 
e IS-IS area identifier 


e IPv6é Router-ID 


e Prefix attributes—These TLVs are stored and propagated like any other unknown TLVs. 


Supported and Unsupported Features 

Junos OS supports the following features with link-state distribution using BGP: 
e Advertisement of multiprotocol assured forwarding capability 

e Transmission and reception of node and link-state BGP and BGP-TE NLRIs 

e Nonstop active routing for BGP-TE NLRIs 


e Policies 
Junos OS does not support the following functionality for link-state distribution using BGP: 


e Aggregated topologies, links, or nodes 

e Route distinguisher support for BGP-TE NLRIs 

e Multi-topology identifiers 

e Multi-instance identifiers (excluding the default instance ID 0) 
e Advertisement of the link and node area TLV 

e Advertisement of MPLS signaling protocols 


e Importing node and link information with overlapping address 


BGP Link-State Extensions for Source Packet Routing in Networking (SPRING) 
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Starting in Junos OS Release 17.2R1, the BGP link-state address family is extended to distribute the source 
packet routing in networking (SPRING) topology information to software-defined networking (SDN) 
controllers. BGP typically learns the link-state information from IGP and distributes it to BGP peers. Besides 
BGP, the SDN controller can get link-state information directly from IGP if the controller is a part of an 
IGP domain. However, BGP link-state distribution provides a scalable mechanism to export the topology 
information. BGP link-state extensions for SPRING is supported on interdomain networks. 


Source Packet Routing in Networking (SPRING) 


SPRING is a control-plane architecture that enables an ingress router to steer a packet through a specific 
set of nodes and links in the network without relying on the intermediate nodes in the network to decide 
the actual path it must take. SPRING engages IGPs, such as IS-IS and OSPF, for advertising network 
segments. Network segments can represent any instruction, topological or service-based. Within IGP 
topologies, IGP segments are advertised by the link-state routing protocols. There are two types of IGP 
segments: 


Adjacency segment—A one-hop path over a specific adjacency between two nodes in the IGP 


Prefix segment—A multi-hop, equal-cost, multipath-aware shortest-path to a prefix, as per the state of 
the IGP topology 


When SPRING in enabled in a BGP network, BGP link-state address family learns the SPRING information 
from the IGP link-state routing protocols and advertises segments in the form of segment identifiers (SIDs). 
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BGP link-state address family has been extended to carry SIDs and other SPRING-related information to 
BGP peers. The route reflector can steer a packet through a desired set of nodes and links by prepending 
the packet with an appropriate combination of tunnels. This feature allows BGP link-state address family 
to also advertise the SPRING information to BGP peers. 

Flow of BGP Link-State SPRING Data 


Figure 91 on page 1085 depicts the data flow of BGP link-state SPRING data that IS-IS pushes to the traffic 
engineering database. 


Figure 91: BGP Link-State Source Packet Routing in Networking (SPRING) 
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e IGP pushes the SPRING attributes to the traffic engineering database. 
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e SPRING capabilities and algorithm information are carried forward as node attributes into the traffic 
engineering database. 


e Adjacent SID and LAN adjacent SID information are carried as link attributes. 
e Prefix SID or node-SID information is carried as prefix attributes. 


e Anew set ora change to existing attributes triggers IGP updates to the traffic engineering database 
with new data. 
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e RSVP is a prerequisite for link attributes. 
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CAUTION: If traffic engineering is disabled at the IGP level, none of the attributes 
A are pushed to the traffic engineering database. 


e All parameters in the BGP traffic engineering NLRI, including the link, node, and prefix descriptors are 
derived from entries in the traffic engineering database. 


e The traffic engineering database imports route entries into the Isdist.0 routing table from IGP subject 
to policy. 


e The default policy of BGP is to export routes, which are known to BGP only. You configure an export 
policy for non-BGP routes in the Isdis.0 routing table. This policy advertises an entry learned from the 
traffic engineering database. 


Supported BGP Link-State Attributes and TLVs, and Unsupported Features for BGP Link-State with SPRING 


BGP link-state with SPRING supports the following attributes and type, length, and values (TLVs) that are 
originated, received, and propagated in the network: 


Node attributes 


e Segment routing Capabilities 


e Segment routing Algorithm 
Link attributes 


e Adjacent-SID 
e LAN Adjacent-SID 


Prefix descriptors 

e IP reachability information 

Prefix attributes 

e Prefix SID 

The following list supports TLVs that are not originated, but only received and propagated in the network: 
Prefix descriptors 


e Multitopology ID 
e OSPF route type 


Prefix attributes 


e Range 


e Binding SID 
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Junos OS does not support the following features with BGP link-state with SPRING extensions: 


e IPvé6 prefix origination 


SPRING over IPv6 


Multitopology identifiers 
Traffic engineering database export for SPRING parameters 


New TLVs with tcpdump (existing TLVs are also not supported). 


Verifying NLRI Node Learned Through BGP with OSPF as IGP 
The following is a sample output to verify the NLRI node learned through BGP with OSPF as the IGP: 


Purpose 


Verify the Isdist.0 routing table entries. 


Action 


From operational mode, run the show route table Isdist.0 command. 


user@host> show route table Isdist.0 te-node-ip 7.7.7.7 extensive 


isiditsie Ore som Gestaimnce tons a lho coutes 
NOD { ASsSlOO AcSacO.@.0 1 uewis7 7.7.7 OSPirsO 1536 





WSIS 


(216 active, O holddown, 
(1 entry, 


LINK-STATE attribute handle 0x61d5da0 





j BGP 


170/=LOL 
Next hop type: Indirect, Next hop index: 0 
Address: 0x61b07cc 





Preferenc 


eoumes 2i16 





Next-hop referenc 


S@wECeSs 2o2o 252 





PAQEOCOL mere IMO Bo Aaes2 


Indirect next hop: 0x2 no-forward INH Session ID: 





State:<Active Int Ext> 
100 Peer AS: 100 
Age: 30:22 Metric2: 2 


Local AS: 





Validation State: unverified 
task? BGP 100.2.2.2.2 











Announcement bits (1): O-TED Export 


AS path: I 





Accepted 





Area border router: No 





External router: No 


0 hidden) 


1 announced) 


0x0 
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Attached: No 
Overload: No 
SPRING-Capabilities: 
-— SRGB block [Start: 900000, Range: 90000, Flags: 0x00] 
SPRING-Algorithms: 
= iNileos © 
Localpref: 100 
INOMIESI® IDS 2oBoBok 
Indirect next hops: 1 
RDROEOQOOL mex IMs 22.2.2 Weiewles 2 
Indirect next hop: 0x2 no-forward INH Session ID: 0x0 
Indirect path forwarding next hops: 1 
Next hop type: Router 
Next hope lilt ls ly 2 svelacte—0/0/ 0m mawercght Ox 
Session Id: 0x143 
BDA Of Sa Celgumaiciime RUBS sLinsic 0 
MaceILes 2 Node path count: 1 
Forwarding nexthops: 1 
Nexthop: 11.1.1.2 via et-0/0/0.1 
Session Id: 143 


Meaning 

The routes are appearing in the Isdist.0 routing table. 

Verifying the Prefix NLRI Learned Through BGP with OSPF as IGP 

The following is a sample output to verify the prefix NLRI learned through BGP with OSPF as the IGP: 


Purpose 


Verify the Isdist.0 routing table entries. 
Action 
From operational mode, run the show route table Isdist.0 command. 


user@host> show route table Isdist.0 te-ipv4-prefix-node-ip 7.7.7.7 extensive 


lsdist.0: 216 destinations, 216 routes (216 active, 0 holddown, O hidden) 
BINHeID< { Nodes { ASslOO AmeasO.0,0.1 wWew4e7o7o7od | 4 wew4e7o 7.7. 7/32 } OSPinso 
}/1536 (1 entry, O announced) 
*BGP Preference: 170/-101 
Next hop type: Indirect, Next hop index: 0 
Address: 0x61b07cc 











Next-hop reference count: 216 


SOMESS B2o2ohok 

PROEOCOL MEE MODS 2.256262 

Indirect next hop: 0x2 no-forward INH Session ID: 0x0 
State: <Active Int Ext> 

Local AS: ROO MPIC SiameAtSr 100 

Age: 30:51 Metric2: 2 





Validation State: unverified 
task? BoP 00 ee 2247.2 
AS@patcheier 
Accepted 
Prefix Flags: 0x00, Prefix SID: 1007, Flags: 0x50, Algo: 
Localpref: 100 
Rows IDS 2.26282 
Indirect next hops: 1 
RPROEOOOL mexic Ines 22.2.2 Metres 2 
Indirect next hop: 0x2 no-forward INH Session ID: 
Indirect path forwarding next hops: 1 
Next hop type: Router 
Next hops) ll 2 wala let —0)/ 0/0L I werght 
Session Id: 0x143 
BP Aobh3e SCAG maging RUS sLineic 0 
Metric: 2 Node path count: 1 
Forwarding nexthops: 1 
Nexthop: 11.1.1.2 via et-0/0/0.1 
Session Id: 143 


Meaning 


The routes are appearing in the Isdist.0 routing table. 
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This example shows how to configure BGP to carry link-state information across multiple domains, which 
is used for computing paths for MPLS LSPs spanning multiple domains, such as inter-area TE LSP, and 
providing a scalable and policy-controlled means for external path computing entities, such as ALTO and 
PCE, to acquire network topology. 


Requirements 
This example uses the following hardware and software components: 
e Four routers that can be a combination of M Series, MX Series, or T Series routers 


e Junos OS Release 14.2 or later running on all the routers 
Before you begin: 


1. Configure the device interfaces. 
2. Configure the autonomous system numbers and router IDs for the devices. 
3. Configure the following protocols: 

e RSVP 

e MPLS 

e BGP 

e IS-IS 

e OSPF 


Overview 


Starting with Junos OS Release 14.2, anew mechanism to distribute topology information across multiple 
areas and autonomous systems (ASs) is introduced by extending the BGP protocol to carry link -state 
information, which was initially acquired using IGP. The IGP protocols have scaling limitations when it 
comes to distributing large databases. BGP is not only a more scalable vehicle for carrying multi-area and 
multi-AS topology information, but also provides the policy controls that can be useful for multi-AS topology 
distribution. The BGP link-state topology information is used for computing paths for MPLS label-switched 
paths (LSPs) spanning multiple domains, such as inter-area TE LSP, and providing a scalable and 
policy-controlled means for external path computing entities, such as ALTO and PCE, to acquire network 
topology. 


Starting with Junos OS Release 17.1R1, link state distribution using BGP is supported on QFX10000 
switches. 
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Topology 


Figure 92: Link-State Distribution Using BGP 
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In Figure 92 on page 1091, Routers RO and R1 and Routers R2 and R3 belong to different autonomous 
systems. Routers RO and R1 run OSPF, and Routers R2 and R3 run IS-IS. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


RO 


set interfaces ge-0/0/0 unit 0 family inet address 8.31.1.101/24 

set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.105.137/32 

set routing-options router-id 10.255.105.137 

set routing-options autonomous-system 65533 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls traffic-engineering database export policy accept-all 
set protocols mpls cross-credibility-cspf 

set protocols mpls label-switched-path to-R3-inter-as to 10.255.105.135 
set protocols mpls label-switched-path to-R3-inter-as bandwidth 40m 
set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp local-address 10.255.105.137 


R1 


set protocols bgp group ibgp family traffic-engineering unicast 

set protocols bgp group ibgp neighbor 10.255.105.141 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set policy-options policy-statement accept-all from family traffic-engineering 
set policy-options policy-statement accept-all then accept 


set interfaces ge-0/0/0 unit 0 family inet address 8.31.1.103/24 

set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 8.42.1.102/24 

set interfaces ge-0/0/1 unit 0 family iso 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.105.141/32 

set routing-options router-id 10.255.105.141 

set routing-options autonomous-system 65533 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp local-address 10.255.105.141 

set protocols bgp group ibgp family traffic-engineering unicast 

set protocols bgp group ibgp export nlri2bgp 

set protocols bgp group ibgp neighbor 10.255.105.137 

set protocols bgp group ebgp type external 

set protocols bgp group ebgp family traffic-engineering unicast 

set protocols bgp group ebgp neighbor 8.42.1.104 local-address 8.42.1.102 

set protocols bgp group ebgp neighbor 8.42.1.104 peer-as 65534 

set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 

set protocols isis interface ge-0/0/1.0 passive remote-node-id 8.42.1.104 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 
8.42.1.104 
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R2 


set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 


10.255.105.139 
set policy-options policy-statement accept-all from family traffic-engineering 
set policy-options policy-statement accept-all then accept 
set policy-options policy-statement nlri2Zbgp term 1 from family traffic-engineering 
set policy-options policy-statement nlri2bgp term 1 then accept 


set interfaces ge-0/0/0 unit 0 family inet address 8.64.1.104/24 

set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 8.42.1.104/24 

set interfaces ge-0/0/1 unit 0 family iso 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.105.139/32 

set interfaces loO unit O family iso 

set routing-options router-id 10.255.105.139 

set routing-options autonomous-system 65534 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls traffic-engineering database import policy ted2nlri 
set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp group ebgp type external 

set protocols bgp group ebgp family traffic-engineering unicast 

set protocols bgp group ebgp export nlri2bgp 

set protocols bgp group ebgp peer-as 65533 

set protocols bgp group ebgp neighbor 8.42.1.102 

set protocols isis level 1 disable 

set protocols isis interface ge-0/0/0.0 

set protocols isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 
set protocols isis interface ge-0/0/1.0 passive remote-node-id 8.42.1.102 
set protocols isis interface lo0.0 

set protocols ospf traffic-engineering 


set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 


8.42.1.102 


set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 


10.255.105.141 
set policy-options policy-statement accept-all from family traffic-engineering 
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set policy-options policy-statement accept-all then accept 

set policy-options policy-statement nlri2Zbgp term 1 from family traffic-engineering 
set policy-options policy-statement nlri2Zbgp term 1 then accept 

set policy-options policy-statement ted2nlri term 1 from protocol isis 

set policy-options policy-statement ted2nlri term 1 from protocol ospf 

set policy-options policy-statement ted2nlri term 1 then accept 

set policy-options policy-statement ted2nlri term 2 then reject 


R3 


set interfaces ge-0/0/0 unit 0 family inet address 8.64.1.106/24 
set interfaces ge-0/0/0 unit 0 family iso 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.105.135/32 
set interfaces loO unit O family iso 

set routing-options router-id 10.255.105.135 

set routing-options autonomous-system 65534 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls traffic-engineering database export policy accept-all 
set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp group ibgp type internal 

set protocols bgp group ibgp local-address 10.255.105.135 

set protocols bgp group ibgp family traffic-engineering unicast 
set protocols bgp group ibgp neighbor 10.255.105.139 

set protocols isis interface ge-0/0/0.0 level 1 disable 

set protocols isis interface lo0.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set policy-options policy-statement accept-all from family traffic-engineering 
set policy-options policy-statement accept-all then accept 


Step-by-Step Procedure 
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The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode. 


To configure Router R1: 


1. Configure the Router R1 interfaces. 


[edit interfaces] 

user@R1# set ge-0/0/0 unit O family inet address 8.31.1.103/24 
user@R1# set ge-0/0/0 unit 0 family iso 

user@R1# set ge-0/0/0 unit 0 family mpls 

user@R1# set ge-0/0/1 unit O family inet address 8.42.1.102/24 
user@R1# set ge-0/0/1 unit 0 family iso 

user@R1# set ge-0/0/1 unit 0 family mpls 

user@R1# set loO unit O family inet address 10.255.105.141/32 


2. Configure the router ID and autonomous system of Router R1. 


[edit routing-options] 
user@R1# set router-id 10.255.105.141 
user@R1# set autonomous-system 65533 


3. Enable RSVP on all the interfaces of Router R1 (excluding the management interface). 


[edit protocols] 
user@R1# set rsvp interface all 
user@R1# set rsvp interface fxp0.0 disable 


4. Enable MPLS on all the interfaces of Router R1 (excluding the management interface). 


[edit protocols] 
user@R1# set mpls interface all 
user@R1# set mpls interface fxp0.0 disable 


5. Configure the BGP group for Router R1 to peer with Router RO, and assign the local address and 
neighbor address. 


[edit protocols] 

user@R1# set bgp group ibgp type internal 

user@R1# set bgp group ibgp local-address 10.255.105.141 
user@R1# set bgp group ibgp neighbor 10.255.105.137 
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6. Include the BGP-TE signaling network layer reachability information (NLRI) to the ibgp BGP group. 


[edit protocols] 
user@R1# set bgp group ibgp family traffic-engineering unicast 


7. Enable export of policy nlri2bgp on Router R1. 


[edit protocols] 
user@R1# set bgp group ibgp export nlri2bgp 


8. Configure the BGP group for Router R1 to peer with Router R2, and assign the local address and 
neighbor autonomous system to the ebgp BGP group. 


[edit protocols] 

user@R1# set bgp group ebgp type external 

user@R1# set bgp group ebgp neighbor 8.42.1.104 local-address 8.42.1.102 
user@R1# set bgp group ebgp neighbor 8.42.1.104 peer-as 65534 


9. Include the BGP-TE signaling NLRI to the ebgp BGP group. 


[edit protocols] 
user@R1# set bgp group ebgp family traffic-engineering unicast 


10. Enable passive traffic-engineering on the inter-AS link. 


[edit protocols] 
user@R1# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 
user@R1# set isis interface ge-0/0/1.0 passive remote-node-id 8.42.1.104 


11. Enable OSPF on the interface connecting Router R1 to Router RO and on the loopback interface of 
Router R1, and enable traffic engineering capabilities. 


[edit protocols] 

user@R1# set ospf traffic-engineering 

user@R1# set ospf area 0.0.0.0 interface lo0.0 
user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 


12. Enable passive traffic-engineering on the inter-AS link. 


1097 


[edit protocols] 

user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 8.42.1.104 

user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 
10.255.105.139 


13. Configure policies to accept traffic from BGP-TE NLRI. 


[edit policy-options] 

user@R1# set policy-statement accept-all from family traffic-engineering 
user@R1# set policy-statement accept-all then accept 

user@R1# set policy-statement nlri2bgp term 1 from family traffic-engineering 
user@R1# set policy-statement nlri2bgp term 1 then accept 


Results 

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 
show protocols, and show policy-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


user@R1# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 8.31.1.103/24; 

} 

family iso; 

family mpls; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 8.42.1.102/24- 
} 
family iso; 
family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 10.255.105.141/32; 


user@R1# show routing-options 
router-id 10.255.105.141; 
autonomous-system 65533; 


user@R1# show protocols 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 


} 
mpls { 
interface all; 
interface fxp0.0 { 
disable; 


} 
bgp { 
group ibgp { 
type internal; 
local-address 10.255.105.141; 
family traffic-engineering { 
unicast; 
} 
export nlri2bgp; 
neighbor 10.255.105.137; 
} 
group ebgp { 
type external; 
family traffic-engineering { 
unicast; 
} 
neighbor 8.42.1.104 { 
local-address 8.42.1.102; 
peer-as 65534; 


} 
isis { 
interface ge-0/0/1.0 { 
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passive { 
remote-node-iso 0102.5502.4211; 
remote-node-id 8.42.1.104; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface 100.0; 
interface ge-0/0/0.0; 
interface ge-0/0/1.0 { 
passive { 
traffic-engineering { 
remote-node-id 8.42.1.104; 


remote-node-router-id 10.255.105.139; 


user@R1# show policy-options 
policy-statement accept-all { 
from family traffic-engineering; 
then accept; 
} 
policy-statement nlri2bgp { 
term 1 { 
from family traffic-engineering; 
then { 
accept; 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode. 


To configure Router R2: 


1. Configure the Router R2 interfaces. 
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[edit interfaces] 

user@R2# set ge-0/0/0 unit O family inet address 8.64.1.104/24 
user@R2# set ge-0/0/0 unit 0 family iso 

user@R2# set ge-0/0/0 unit O family mpls 

user@R2# set ge-0/0/1 unit O family inet address 8.42.1.104/24 
user@R2# set ge-0/0/1 unit 0 family iso 

user@R2# set ge-0/0/1 unit 0 family mpls 

user@R2# set loO unit 0 family inet address 10.255.105.139/32 
user@R2# set loO unit O family iso 


. Configure the router ID and autonomous system of Router R2. 
[edit routing-options] 


user@R2# set router-id 10.255.105.139 
user@R2# set autonomous-system 65534 


. Enable RSVP on all the interfaces of Router R2 (excluding the management interface). 
[edit routing-options] 


user@R2# set rsvp interface all 
user@R2# set rsvp interface fxp0.0 disable 


. Enable MPLS on all the interfaces of Router R2 (excluding the management interface). 
[edit routing-options] 


user@R2# set mpls interface all 
user@R2# set mpls interface fxp0.0 disable 


. Enable import of traffic engineering database parameters using the ted2nlri policy. 


[edit protocols] 
user@R2# set mpls traffic-engineering database import policy ted2nlri 


. Configure the BGP group for Router R2 to peer with Router R1. 


[edit protocols] 
user@R2# set bgp group ebgp type external 
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7. Include the BGP-TE signaling NLRI to the ebgp BGP group. 


[edit protocols] 
user@R2# set bgp group ebgp family traffic-engineering unicast 


8. Assign the local address and neighbor autonomous system to the ebgp BGP group. 


[edit protocols] 
user@R2# set bgp group ebgp peer-as 65533 
user@R2# set bgp group ebgp neighbor 8.42.1.102 


9. Enable export of policy nlri2bgp on Router R2. 


[edit protocols] 
user@R2# set bgp group ebgp export nlri2bgp 


10. Enable IS-IS on the interface connecting Router R2 with Router R3 and the loopback interface of Router 
R2. 


[edit protocols] 

user@R2# set isis level 1 disable 
user@R2# set isis interface ge-0/0/0.0 
user@R2# set isis interface lo0.0 


11. Enable only IS-IS advertising on the interface connecting Router R2 with Router R1. 


[edit protocols] 
user@R2# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5501.8181 
user@R2# set isis interface ge-0/0/1.0 passive remote-node-id 8.42.1.102 


12. Configure traffic engineering capability on Router R2. 


[edit protocols] 
user@R2# set ospf traffic-engineering 


13. Enable only OSPF advertisements on the interface connecting Router R2 with Router R1. 


[edit protocols] 
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user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 8.42.1.102 
user@R2# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 
10.255.105.141 


14. Configure policies to accept traffic from the BGP-TE NLRI. 


[edit policy-options] 

user@R2# set policy-statement accept-all from family traffic-engineering 
user@R2# set policy-statement accept-all then accept 

user@R2# set policy-statement nlri2bgp term 1 from family traffic-engineering 
user@R2# set policy-statement nlri2bgp term 1 then accept 

user@R2# set policy-statement ted2nlri term 1 from protocol isis 

user@R2# set policy-statement ted2nlri term 1 from protocol ospf 

user@R2# set policy-statement ted2nlri term 1 then accept 

user@R2# set policy-statement ted2nlri term 2 then reject 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 
show protocols, and show policy-options commands. If the output does not display the intended 
configuration, repeat the instructions in this example to correct the configuration. 


user@R2# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 8.64.1.104/24- 

} 

family iso; 

family mpls; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 8.42.1.104/24; 
} 
family iso; 
family mpls; 


loO { 
unit O { 


family inet { 
address 10.255.105.139/32; 
} 


family iso; 


user@R2# show routing-options 
router-id 10.255.105.139; 
autonomous-system 65534; 


user@R2# show protocols 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 


} 
mpls { 
traffic-engineering { 
database { 
import { 
policy ted2nlri; 


} 

interface all; 

interface fxp0.0 { 
disable; 


} 
bgp { 
group ebgp { 
type external; 
family traffic-engineering { 
unicast; 
} 
export nlri2bgp; 
peer-as 65533; 
neighbor 8.42.1.102; 


isis { 
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level 1 disable; 
interface ge-0/0/0.0; 
interface ge-0/0/1.0 { 
passive { 
remote-node-iso 0102.5501.8181; 
remote-node-id 8.42.1.102; 


} 
interface 100.0; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-0/0/1.0 { 
passive { 
traffic-engineering { 
remote-node-id 8.42.1.102; 
remote-node-router-id 10.255.105.141; 


user@R2# show policy-options 
policy-statement accept-all { 
from family traffic-engineering; 
then accept; 
} 
policy-statement nlri2bgp { 
term 1 { 
from family traffic-engineering; 
then { 
accept; 


} 
policy-statement ted2nlri { 
term 1 { 
from protocol [ isis ospf ]; 
then accept; 
} 
term 2 { 
then reject; 
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Verifying the Traffic Engineering Database Entries | 1110 


Verify that the configuration is working properly. 
Verifying the BGP Summary Status 


Purpose 


Verify that BGP is up and running on Routers RO and R1. 


Action 


From operational mode, run the show bgp summary command. 


user@RO> show bgp summary 


Groups: 1 Peers: 1 Down peers: 0 





Table Tot Paths Act Paths Suppressed History Damp State Pending 
Ibselitsic ¢C 

10 10 0 0 0 0 
Peer AS iM TRIE OutPkt OutQ Flaps Last Up/Dwn 
State|#Active/Received/Accepted/Damped... 
10. 2554105. 141 65533) 20 14 0 719 9818 
Establ 





Iseisic. 03 10/0/06 


From operational mode, run the show bgp summary command. 


user@R1> show bgp summary 
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Groups: 2 Peers: 2 Down peers: 0 
Table 
isdist.0 


Tot Paths Act Paths Suppressed 
10 IL) 0 

Peer AS InPkt OutPkt 
State|#Active/Received/Accepted/Damped... 
8.42.1.104 65534 24 Ly 
Establ 

aS Cassie Olas WO//N0Y/ 1h0)/70 
10.2556 105.137 
Establ 

lsdist.0: 0/0/0/0 








S9)93)3} 15 23 





Meaning 
Router RO is peered with Router R1. 


Verifying the MPLS LSP Status 


Purpose 
Verify the status of the MPLS LSP on Router RO. 


Action 
From operational mode, run the show mpls Isp command. 


user@RO> show mpls Isp 


Ingress LSP: 1 sessions 
To From State Rt P 
10,255. 105.135 i10,.255,105.137 Woe Om 


Total 1 displayed, Up 1, Down 0 








Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 
The MPLS LSP from Router RO to Router R3 is established. 


Verifying the Isdist.0 Routing Table Entries 


Purpose 


History Damp State 


0 
OutQ 


ActivePath 
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Pending 


0 0 
Flaps Last Up/Dwn 


70 6:43 


VS Sg ile 


LSPname 


to-R3-inter-as 
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Verify the Isdist.0 routing table entries on Routers RO, R1, and R2. 
Action 
From operational mode, run the show route table Isdist.0 command. 


user@RO> show route table Isdist.0 


lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


NODEMERASHI6 oS 4 alts Or OMkO Fro SO a4 Arlen O ONES ies Ions Om e/ elelee 
“[RES/LIO] OOSLYsS2, Ihoe@zilljoreit 100, cimom 10.255 105,141 
AS path: 65534 I, validation-state: unverified 
> to 8.31.1.103 via ge—-0/0/0.0 
NODA { ASSSS5S4 USOZOLOZ S502 .4250.00 tSuS=n230 }/iils2 
[ES /iLI7O]] OOEILVS82, ikeeszilioiese 100, semen 10.255. 105.14 
AS path: 65534 I, validation-state: unverified 
> to 8.31.1.103 via ge-0/0/0.0 
NODEMEAS 3655 S4 apts OF OM O2 55 02425 ORO oias — lnons1 Ome e/elelbey 
S[XES/L7O]] OOELVs32, lhoeziljorese 100, trem 10.255. 105.14 
AS path: 65534 I, validation-state: unverified 
2 tO So. Sil 110s. wie oe-0/0/0.0 
NODE { ASSGSSS4 AeasO.0.0.0 mews 255. 105,139 OsEirs@ } fills 
“[RES/LIO] OOSLVSS2, leoczaljoreit 100, tiem 10.255 105.141 
AS path: 65534 I, validation-state: unverified 
SiO So sil l,1l0s waa ce—-0/0/0.0 
LINK { Local { AS:65534 1S0:0102.5502.4211.00 }.{ IPv4:8.42.1.104 } Remote { 
ASSG6S534 LSOsOLlOS.S501 8181.00 }.f wPweeB.42.1,102 } LSus<n2e0 }/lis2 





























wTIEP/LTO]| OOSLIs3s2, ihoceilowet LOO, trom 10.255, 105,141 
AS path: 65534 I, validation-state: unverified 
2 tO So. Sl 110s wile oe-0/0/0.0 
LINK { Local { AS:65534 1S0:0102.5502.4211.00 }.{ IPv4:8.64.1.104 } Remote { 
AS8OSa34 USORO1O2Z.S5502.4250,02 fot } wSuS—L2e0 }/iiS2 
“RE2S/L70 |) OOSO2603, ihoezuljoreie 100, crem 10.255. 105,141 
AS path: 65534 I, validation-state: unverified 
ae Om Cre en OC mavncmce— OO AOraO) 
LINK { Local { AS:65534 1S0:0102.5502.4250.00 }.{ IPv4:8.64.1.106 } Remote { 
ASSGSSI4 USORO1OZ.5502.4250,02 fof } wSuS—n2e0 } /1il52 
“[REP/LIO] OOSLI3s32, loceliswet 100, trom 10.255.105., 141 
AS path: 65534 I, validation-state: unverified 
S tO Bo Sil, 1,103 wie ce—-0/0/0.0 
LINK { Local { AS:65534 1S0:0102.5502.4250.02 }.{ } Remote { AS:65534 
USOZOLOZ 5502 4211.00 bof } BSuS=m230 }/11S2 
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“[REP/LIO] OOSLI3s32, leocelisret 100, trom 10.255,105.,141 
AS path: 65534 I, validation-state: unverified 
Pat Omori lO ma vakcmce— O01 OOO) 
LINK { Local { AS:65534 1S0:0102.5502.4250.02 }.{ } Remote { AS:65534 
USOZOLOZ S502 4250.00 afl } USuS—m220 f/1lS2 
“(EP /LIO] OOSLIs32, loceliswet 100, trom 10.255, 105,141 
AS path: 65534 I, validation-state: unverified 
> to 8.31.1.103 via ge—-0/0/0.0 
InN { iboveeul ( ASSGoas4 Aec30,.0,0.0 uPw4siO.255. 105.159 fo wewass 42 1.104 | 
Remote { AS:65534 Area:0,.0.0.0 TPw4s10.255.105.141 }.{ IPw4:8.42.1.102 } OSPF:0 
}/ 52 








LXES/L7O]] OOELVss2, ihoeziljorese 100, xem 10.255. 105. 1411 
AS path: 65534 I, validation-state: unverified 
> to 8.31.1.103 via ge-0/0/0.0 





From operational mode, run the show route table Isdist.0 command. 


user@R1> show route table Isdist.0 


lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0O hidden) 
+ = Active Route, Last Active, * = Both 











NODE EAS 65> S4 apts Or OM O2io 5 O24 se NO OME SiaS — 1n75:1 Ome e/elelbey 
*[BGP/170] 00:18:00, localpref 100 
AS path: 65534 I, validation-state: unverified 
> to 8.42.1.104 via ge-0/0/1.0 
NODA { ASSSS534 USOSOLOZ S502 4250.00 LSuS=u2e0 }/lils2 
*(BGP/170] 00:18:00, localpref 100 
AS path: 65534 I, validation-state: unverified 
> to 8.42.1.104 via ge-0/0/1.0 
NODA { ASSSS5Ss4 USOSOLOZ. S502 4250.02 LSuS=n28@ }/ilils2 
(SGP / ls Ol OOshs 010 pa lkocaore tsk0)0 
AS path: 65534 I, validation-state: unverified 
Pt Omcn 2 el OAM nomciS— ON Oyler) 
NODEMEAS 6 5DS4wAtecalOnO OO met DNAse On > Se O Sele OOS EH Omer eleles 2 
*[BGP/170] 00:18:00, localpref 100 
AS path: 65534 I, validation-state: unverified 
> to 8.42.1.104 via ge-0/0/1.0 
LINK { Local { AS:65534 1S0:0102.5502.4211.00 }.{ IPv4:8.42.1.104 } Remote { 
ASeGS594 USO¢OLOZ.S50i1,Sl31,00 fof uewass 42 1.102 }) 1SiS-me90 f/lils2 























*[BGP/170] 00:18:00, localpref 100 
AS path: 65534 I, validation-state: unverified 
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SiO So.42.1,104 waa ce-0/0/i1.0 
NK ehOCalen( NS t65 5 S45 SOnOlOZ S502. 4 7ulen OO (eiP 4 Orel lkO AS eRemotcu 
ASPOSSI4 LHOSOLOZ.5502.4250.,02 fof } USusS=n280 }/iils2 
*(BGP/170] 00:02:19, localpref 100 
AS path: 65534 I, validation-state: unverified 
SiO Bo42.1,104 waa ce—-0/0/1.0 
LINK { Local { AS:65534 1S0:0102.5502.4250.00 }.{ IPv4:8.64.1.106 } Remote { 
ASPOSSI4 USOSOLO2Z, S502 4250.02 fof } uSuS=n280 }/ils2 
*[BGP/170] 00:18:00, localpref 100 
AS path: 65534 I, validation-state: unverified 
SiO Bo.42,1,104 waa ce—-0/0/1.0 
LINK { Local { AS:65534 1S80:0102.5502.4250.02 }.{ } Remote { AS:65534 
USOsZOLOZ S502 4211.00 bat } USuS=n230 }/1iS2 
*[BGP/170] 00:18:00, localpref 100 
AS path: 65534 I, validation-state: unverified 
Pa Omcn opine OA mvaitcmciS— ON. 0)/ale 0) 
LINK { Local { AS:65534 1S0:0102.5502.4250.02 }.{ } Remote { AS:65534 
USOSOLOZ S502 4250 00 fof } USuS=—m230 }/11S2 
*[BGP/170] 00:18:00, localpref 100 
AS path: 65534 I, validation-state: unverified 
> to 8.42.1.104 via ge-0/0/1.0 
MN { local ( ASSGO5534 AmeasO.0,.0.0 tew4slO.255. 105.139 }. wewass.42,1.104 } 
Remobce { AS¢65534 Area:0.0.0.0 EPy4: 10.255. 005.041 2.f fPw4ase.42.1.002 } OSPr:0 
VILL S52 














*[BGP/170] 00:18:00, localpref 100 
AS path: 65534 I, validation-state: unverified 
> to 8.42.1.104 via ge-0/0/1.0 





From operational mode, run the show route table Isdist.0 command. 


user@R2> show route table Isdist.0 


lsdist.0: 10 destinations, 10 routes (10 active, 0 holddown, 0O hidden) 
+ = Active Route, Last Active, * = Both 








NODEMGRAS 6 55 S4 alts Or 0 WhO Fro 5 0a 4 Arlen OO MES es io as1 Om yy eleleey 
“(IS=1S/ U8] lel OC e2as 38) 
aLGIE sie LOUIS} 
NODA { ASSSS5534 USOSOLOZ. S502 4250.00 uSuS=u2e0 }/lils2 
(US 10S/1s]| OOSZOgas 








Hac aiteous 
NOD { ASsos534 tSOsOl02. 5502,4250.,02 mSiSs=m2380 }/1l152 
*[TS-18/13] OWs20cas 
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Fictitious 
NODEMEAS 36S SA aeAte carn Om On Ome Dyan On See OO relS OOS EH Omer elles 2 
*[OSPF/10] 1d 00:24:39 
Fictitious 
LINK { Local { AS:65534 1S0:0102.5502.4211.00 }.{ IPv4:8.42.1.104 } Remote { 
ASSG6S534 LSOsOLlO2. S501 8181.00 fof weweleB.d2.1.,102 } LSus<n2e0 }/lis2 





*[IS=1S/ isi OOs203 58 
Fictitious 
LINK { Local { AS:65534 180:0102.5502.4211.00 }.{ IPv4:8.64.1.104 } Remote { 
ASS6S5S4 USO,OlO2. 5502425002 fat } wSuS=n20 }/1152 
“TIS=-1S/18]) OOs@2. 54 
Fictitious 
LINK { Local { AS:65534 1S80:0102.5502.4250.00 }.{ IPv4:8.64.1.106 } Remote { 
ASPGISI4 ULSOSOLOZ,S502.4250.02 fol } uSuS=n280 }/ils2 
Pa |BeS Sle Sy/ Si OO AO 7415 
IaLGle alte aLoybls} 
LINK { Local { AS:65534 1S80:0102.5502.4250.02 }.{ } Remote { AS:65534 
USOZOLOZ 5502 4211.00 haf } BSuS=m230 }/1ls2 
“US =1S/ 10s ]| OOsZ20 34s 
Fictitious 
LINK { Local { AS:65534 1S80:0102.5502.4250.02 }.{ } Remote { AS:65534 
USOSOLOZ S502 4250.00 fat } USUS=m230 }/11S2 
=(IS=-1S/13]] OOs2Z0c45 
Fictitious 
InN f Ieeell {| ASSGHSS4 AMeSes0 .O.0.0 UP W4AslO 259 105.139 fof wPwess.42.1.104 f 
Remote { AS?¢65534 Area:0,.0.0.0 TPw4sl0.255.105.141 }.4 TPw4:6.42.1.102 } OSPF:0 
Dp/eles 2: 
(OSE HARON OOk AOR Sy, 


Fictitious 


Meaning 


The routes are appearing in the Isdist.O routing table. 


Verifying the Traffic Engineering Database Entries 


Purpose 


Verify the traffic engineering database entries on Router RO. 
Action 
From operational mode, run the show ted database command. 


user@RO> show ted database 

















TED da 
ID 
O1LOZ 5 
LOS 
ID 
OO 5 
OAOZES 
ID 
Leys 
ID 
OLOZ 5 
Hon 
AUD) 
OLOZ . 5 
To? 
1% 
AUD) 
hs Shil g Ab 
10° 
1O° 
ID 
10) 255 
1% 
Lo? 
Meaning 


Oo: 


















































The routes are appearing in the traffic engineering database. 
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tabase: 5 ISIS nodes 5 INET nodes 
Type Age(s) LnkIn LnkOut Protocol 
SOL SLl68 00 (10,.255,105,137) mei 1046 1 EO SEs (Om OR Ors 0)) 
S.o1.,1.101-1, Local: 38.31.1101, Remotes 070.070 
Local interface index: 0, Remote interface index: 0 
Type Age(s) LInkIn LnkOut Protocol 
501.8181.00 osm 1033 il 0 
5024211 OO (10,255, 105,139) tei 3512) 2 3 Exported ISIS-—L2 (1) 
0102.5502.4250.02, Local: 8.64.1.104, Remote: 0.0.0.0 
Local interface index: 0, Remote interface index: 0 
OUOZ. So01 {881 OO; Local: 874251 N04), Remote: 84251 102 
Local interface index: 0, Remote interface index: 0 
Type Age(s) LnkIn LnkOut Protocol 
Exported OSPF (2) 
IO 255,105 141, mocals 8.42. 1.104, Remores 8.42, 1,102 
Local interface index: 0, Remote interface index: 0 
Type Age(s) LnkIn LnkOut Protocol 
502 4250 00 (10.255, 105,135) ime OSS il i Begoorcecl USS (i) 
0102.5502.4250.02, Local: 8.64.1.106, Remote: 0.0.0.0 
Local interface index: 0, Remote interface index: 0 
Type Age(s) LnkIn LnkOut Protocol 
5024250 .02 Net 1033 2 2 Exported ISIS-L2 (1) 
OL02 S502. 4211 OO (10.255. 105,159), toeals 0.0.0.0, Rawores 0.0.0.0 
Local interface index: 0, Remote interface index: 0 
V1L02 . S502 ..4250 00 (10,.255.105,135), toeails 0.0.0.0, Rawores 0.0.0.0 
Local interface index: 0, Remote interface index: 0 
Type Age(s) LnkIn LnkOut Protocol 
5 LOU i Net 1046 2 2ROSPE(OROR ORO) 
0102 , S501. 8168.00 (10.255. 105.137), heeails 0.0.0.0, Rawores 0.0.0.0 
Local interface index: 0, Remote interface index: 0 
10.255 ,10S 1a, moecils O,.0.0.0, Remones O.0.0.0 
Local interface index: 0, Remote interface index: 0 
Type Age(s) LnkIn LnkOut Protocol 
a ALS . EI. Bue Ie 1045 2 2ROSPEN (ORO ORO) 
Q102 S502 4211 OO (10,255. 105,139), woeails 8.421.102, memes: 8.42. 1.104 
Local interface index: 0, Remote interface index: 0 
@.51.,L.10f-1, Locals 8.33 .1,103, Remote: 0.0.0.0 
Local interface index: 0, Remote interface index: 0 


Configuring Link State Distribution Using BGP 


You can enable distribution of topology information across multiple areas and autonomous systems (ASs) 
by extending the BGP protocol to carry link-state information, which was initially acquired using IGP. The 
IGP protocols have scaling limitations when it comes to distributing large databases. BGP is not only a 
more scalable vehicle for carrying multi-area and multi-AS topology information, but also provides the 
policy controls that can be useful for multi-AS topology distribution. The BGP link-state topology information 
is used for computing paths for MPLS LSPs spanning multiple domains, such as inter-area TE LSP, and 
providing a scalable and policy-controlled means for external path computing entities, such as ALTO and 
PCE, to acquire network topology. 


Before you begin: 


1. Configure the device interfaces. 
2. Configure the router ID and autonomous system number for the device. 
3. Configure the following protocols: 

e RSVP 

e MPLS 

e IS-IS 

e OSPF 


To enable link-state distribution using BGP: 


1. Configure an internal BGP group, and assign the local address and neighbor address for the group. 


[edit protocols] 

user@R1# set bgp group internal-group-name type internal 

user@R1# set bgp group internal-group-name local-address ip-address 
user@R1# set bgp group internal-group-name neighbor ip-address 


2. Include the BGP-TE signaling network layer reachability information (NLRI) to the internal BGP group. 


[edit protocols] 
user@R1# set bgp group internal-group-name family traffic-engineering unicast 


3. Enable export of policy on the device. 


[edit protocols] 
user@R1# set bgp group internal-group-name export second-policy-name 
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4. Configure an external BGP group, and assign the local address and neighbor autonomous system to 


the group. 


[edit protocols] 

user@R1# set bgp group external-group-name type external 

user@R1# set bgp group external-group-name neighbor ip-address local-address ip-address 
user@R1# set bgp group external-group-name neighbor ip-address peer-as as-number 


5. Include the BGP-TE signaling NLRI to the external BGP group. 


[edit protocols] 
user@R1# set bgp group external-group-name family traffic-engineering unicast 


6. In configuration mode, go to the following hierarchy level: 


[edit] 
user@R1# edit policy-options 


7. Configure policies to accept traffic from the BGP-TE NLRI. 


[edit policy-options] 

user@R1# set policy-statement policy-name from family traffic-engineering 

user@R1# set policy-statement policy-name then accept 

user@R1# set policy-statement bgp-import-policy term 1 from family traffic-engineering 
user@R1# set policy-statement bgp-import-policy term 1 then next-hop self 

user@R1# set policy-statement bgp-import-policy term 1 then accept 


8. On the remote connecting device, configure policy to accept the OSPF and IS-IS traffic. 


[edit policy-options] 

user@R2# set policy-statement bgp-export-policy term 1 from protocol isis 
user@R2# set policy-statement bgp-export-policy term 1 from protocol ospf 
user@R2# set policy-statement bgp-export-policy term 1 then accept 
user@R2# set policy-statement bgp-export-policy term 2 then reject 


9. Verify and commit the configuration. 


For example: 


R1 


R2 


[edit protocols] 

user@R1# set rsvp interface all 

user@R1# set rsvp interface fxp0.0 disable 

user@R1# set mpls interface all 

user@R1# set mpls interface fxp0.0 disable 

user@R1# set bgp group ibgp type internal 

user@R1# set bgp group ibgp local-address 10.255.105.141 

user@R1# set bgp group ibgp family traffic-engineering unicast 

user@R1# set bgp group ibgp export nlri2bgp 

user@R1# set bgp group ibgp neighbor 10.255.105.137 

user@R1# set bgp group ebgp type external 

user@R1# set bgp group ebgp family traffic-engineering unicast 

user@R1# set bgp group ebgp neighbor 8.42.1.104 local-address 8.42.1.102 

user@R1# set bgp group ebgp neighbor 8.42.1.104 peer-as 65534 

user@R1# set isis interface ge-0/0/1.0 passive remote-node-iso 0102.5502.4211 

user@R1# set isis interface ge-0/0/1.0 passive remote-node-id 8.42.1.104 

user@R1# set ospf traffic-engineering 

user@R1# set ospf area 0.0.0.0 interface 100.0 

user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 

user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-id 8.42.1.104 

user@R1# set ospf area 0.0.0.0 interface ge-0/0/1.0 passive traffic-engineering remote-node-router-id 
10.255.105.139 


[edit policy-options] 

user@R1# set policy-statement accept-all from family traffic-engineering 
user@R1# set policy-statement accept-all then accept 

user@R1# set policy-statement nlri2bgp term 1 from family traffic-engineering 
user@R1# set policy-statement nlri2bgp term 1 then next-hop self 

user@R1# set policy-statement nlri2bgp term 1 then accept 


[edit] 
user@R1# commit 
commit complete 


[edit policy-options] 

user@R2# set policy-statement accept-all from family traffic-engineering 
user@R2# set policy-statement accept-all then accept 

user@R2# set policy-statement nlri2bgp term 1 from family traffic-engineering 
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user@R2# set policy-statement nlri2bgp term 1 then next-hop self 
user@R2# set policy-statement nlri2bgp term 1 then accept 
user@R2# set policy-statement ted2nlri term 1 from protocol isis 
user@R2# set policy-statement ted2nlri term 1 from protocol ospf 
user@R2# set policy-statement ted2nlri term 1 then accept 
user@R2# set policy-statement ted2nlri term 2 then reject 


[edit] 
user@R2# commit 
commit complete 


Improving Traffic Engineering Database Accuracy with RSVP PathErr Messages 


IN THIS SECTION 


@ ~=PathErr Messages | 1116 
@ = Identifying the Problem Link | 1116 


@ Configuring the Router to Improve Traffic Engineering Database Accuracy | 1117 


An essential element of RSVP-based traffic engineering is the traffic engineering database. The traffic 
engineering database contains a complete list of all network nodes and links participating in traffic 
engineering, and a set of attributes each of those links can hold. (For more information about the traffic 
engineering database, see “Constrained-Path LSP Computation” on page 479.) One of the most important 
link attributes is bandwidth. 


Bandwidth availability on links changes quickly as RSVP LSPs are established and terminated. It is likely 
that the traffic engineering database will develop inconsistencies relative to the real network. These 
inconsistencies cannot be fixed by increasing the rate of IGP updates. 


Link availability can share the same inconsistency problem. A link that becomes unavailable can break all 
existing RSVP LSPs. However, its unavailability might not readily be known by the network. 


When you configure the rsvp-error-hold-time statement, a source node (ingress of an RSVP LSP) learns 
from the failures of its LSP by monitoring PathErr messages transmitted from downstream nodes. 
Information from the PathErr messages is incorporated into subsequent LSP computations, which can 
improve the accuracy and speed of LSP setup. Some PathErr messages are also used to update traffic 
engineering database bandwidth information, reducing inconsistencies between the traffic engineering 
database and the network. 


You can control the frequency of IGP updates by using the update-threshold statement. See “Configuring 
the RSVP Update Threshold on an Interface” on page 791. 


This section discusses the following topics: 


PathErr Messages 


PathErr messages report a wide variety of problems by means of different code and subcode numbers. 
You can find a complete list of these PathErr messages in RFC 2205, Resource Reservation Protocol (RSVP), 
Version 1, Functional Specification and RFC 3209, RSVP-TE: Extensions to RSVP for LSP Tunnels. 


When you configure the rsvp-error-hold-time statement, two categories of PathErr messages, which 
specifically represent link failures, are examined: 


e Link bandwidth is low for this LSP: Requested bandwidth unavailable—code 1, subcode 2 


This type of PathErr message represents a global problem that affects all LSPs transiting the link. They 
indicate that the actual link bandwidth is lower than that required by the LSP, and that it is likely that 
the bandwidth information in the traffic engineering database is an overestimate. 


When this type of error is received, the available link bandwidth is reduced in the local traffic engineering 
database, affecting all future LSP computations. 


Link unavailable for this LSP: 


e Admission Control failure—code 1, any subcode except 2 
e Policy Control failures—code 2 
e Service Preempted—code 12 


e Routing problem—no route available toward destination—code 24, subcode 5 


These types of PathErr messages are generally pertinent to the specified LSP. The failure of this LSP 
does not necessarily imply that other LSPs could also fail. These errors can indicate maximum transfer 
unit (MTU) problems, service preemption (either manually initiated by the operator or by another LSP 
with a higher priority), that a next-hop link is down, that a next-hop neighbor is down, or service rejection 
because of policy considerations. It is best to route this particular LSP away from the link. 


Identifying the Problem Link 


Each PathErr message includes the sender’s IP address. This information is propagated unchanged toward 
the ingress router. A lookup in the traffic engineering database can identify the node that originated the 
PathErr message. 


Each PathErr message carries enough information to identify the RSVP session that triggered the message. 
If this is a transit router, it simply forwards the message. If this router is the ingress router (for this RSVP 
session), it has the complete list of all nodes and links the session should traverse. Coupled with the 
originating node information, the link can be uniquely identified. 
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Configuring the Router to Improve Traffic Engineering Database Accuracy 


To improve the accuracy of the traffic engineering database, configure the rsvp-error-hold-time statement. 
When this statement is configured, a source node (ingress of an RSVP LSP) learns from the failures of its 
LSP by monitoring PathErr messages transmitted from downstream nodes. Information from the PathErr 
messages is incorporated into subsequent LSP computations, which can improve the accuracy and speed 
of LSP setup. Some PathErr messages also are used to update traffic engineering database bandwidth 
information, reducing inconsistencies between the traffic engineering database and the network. 


To configure how long MPLS should remember RSVP PathErr messages and consider them in CSPF 


computation, include the rsvp-error-hold-time statement: 


rsvp-error-hold-time seconds; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


The time can be a value from 1 to 240 seconds. The default is 25 seconds. Configuring a value of O disables 
the monitoring of PathErr messages. 


Release History Table 
Release Description 
17.4R1 Starting in Junos OS Release 17.4R1, the traffic engineering database installs interior gateway 


protocol (IGP) topology information in addition to RSVP-TE topology information in the Isdist.O 
routing table 


17.2R1 Starting in Junos OS Release 17.2R1, the BGP link-state address family is extended to distribute 
the source packet routing in networking (SPRING) topology information to software-defined 
networking (SDN) controllers. 


17.1R1 Starting with Junos OS Release 17.1R1, link state distribution using BGP is supported on 
QFX10000 switches. 


RELATED DOCUMENTATION 
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Configuring LSPs for DiffServ-Aware Traffic Engineering | 1126 


DiffServ-Aware Traffic Engineering Introduction 


Differentiated Services (DiffServ)-aware traffic engineering provides a way to guarantee a specified level 
of service over an MPLS network. The routers providing DiffServ-aware traffic engineering are part of a 
differentiated services network domain. All routers participating in a differentiated services domain must 
have DiffServ-aware traffic engineering enabled. 


To help ensure that the specified service level is provided, it is necessary to ensure that no more than the 
amount of traffic specified is sent over the differentiated services domain. You can accomplish this goal 
by configuring a policer to police or rate-limit the volume of traffic transiting the differentiated service 
domain. For more information about how to configure policers for label-switched paths (LSPs), see 
“Configuring Policers for LSPs” on page 149. 


This feature can help to improve the quality of Internet services such as voice over IP (VoIP). It also makes 
it possible to better emulate an Asynchronous Transfer Mode (ATM) circuit over an MPLS network. 


DiffServ-Aware Traffic Engineering Terminology 


Bandwidth model The bandwidth model determines the values of the available bandwidth advertised by the interior gateway 


protocols (IGPs). 


CAC Call admission control (CAC) checks to ensure there is adequate bandwidth on the path before the LSP 


is established. If the bandwidth is insufficient, the LSP is not established and an error is reported. 


Class type 


D 


Differentiated Services 


Differentiated Services 


domain 


DiffServ-aware traffic 


engineering 

M 
MAM 
Multiclass LSP 

R 
RDM 

T 


Traffic engineering class 


Traffic engineering class 


map 
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A collection of traffic flows that is treated equivalently in a differentiated services domain. A class type 
maps to a queue and is much like a class-of-service (CoS) forwarding class in concept. It is also known 


as a traffic class. 


Differentiated Services make it possible to give different treatment to traffic based on the EXP bits in 


the MPLS header. Traffic must be marked appropriately and CoS must be configured. 


The routers in a network that have Differentiated Services enabled. 


A type of constraint-based routing. It can enforce different bandwidth constraints for different classes 


of traffic. It can also do CAC on each traffic engineering class when an LSP is established. 


The maximum allocation bandwidth constraint model divides the available bandwidth between the 


different classes. Sharing of bandwidth between the class types is not allowed. 


A multiclass LSP functions like a standard LSP, but it also allows you to reserve bandwidth from multiple 


class types. The EXP bits of the MPLS header are used to distinguish between class types. 


The Russian dolls bandwidth constraint model makes efficient use of bandwidth by allowing the class 


types to share bandwidth. 


A paired class type and priority. 


A map between the class types, priorities, and traffic engineering classes. The traffic engineering class 


mapping must be consistent across the Differentiated Services domain. 


DiffServ-Aware Traffic Engineering Features 


DiffServ-aware traffic engineering provides the following features: 


e Traffic engineering at a per-class level rather than at an aggregate level 


e Different bandwidth constraints for different class types (traffic classes) 


e Different queuing behaviors per class, allowing the router to forward traffic based on the class type 


In comparison, standard traffic engineering does not consider CoS, and it completes its work on an aggregate 


basis across all Differentiated Service classes. 


DiffServ-aware traffic engineering provides the following advantages: 
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e Traffic engineering can be performed on a specific class type instead of at the aggregate level. 
e Bandwidth constraints can be enforced on each specific class type. 


e It forwards traffic based on the EXP bits. 


This makes it possible to guarantee service and bandwidth across an MPLS network. With DiffServ-aware 
traffic engineering, among other services, you can provide ATM circuit emulation, VoIP, and a guaranteed 
bandwidth service. 


The following describes how the IGP, Constrained Shortest Path First (CSPF), and RSVP participate in 
DiffServ-aware traffic engineering: 


e The IGP can advertise the unreserved bandwidth for each traffic engineering class to the other members 
of the differentiated services domain. The traffic engineering database stores this information. 


e ACSPF calculation is performed considering the bandwidth constraints for each class type. If all the 
constraints are met, the CSPF calculation is considered successful. 


e When RSVP signals an LSP, it requests bandwidth for specified class types. 


Configuring Link Down Notification for Optics Options Alarm or Warning 


To configure this option, include the alarm or warning statement at the [edit interfaces ge- fpc/pic/port 
optics-options] hierarchy level: 


[edit interfaces] 
ge-fpc/pic/port { 
optics-options { 
alarm alarm-name { 
(syslog | link-down); 
} 
warning warning-name { 
(syslog | link-down); 
} 


DiffServ-Aware Traffic Engineered LSPs Overview 


A DiffServ-aware traffic engineered LSP is an LSP configured with a bandwidth reservation for a specific 
class type. This LSP can carry traffic for a single class type. On the packets, the class type is specified by 
the EXP bits (also known as the class-of-service bits) and the per-hop behavior (PHB) associated with the 
EXP bits. The mapping between the EXP bits and the PHB is static, rather than being signaled in RSVP. 
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The class type must be configured consistently across the Differentiated Services domain, meaning the 
class type configuration must be consistent from router to router in the network. You can unambiguously 
map a class type to a queue. On each node router, the class-of-service queue configuration for an interface 
translates to the available bandwidth for a particular class type on that link. 


For more information about topics related to LSPs and DiffServ-aware traffic engineering, see the following: 


e For forwarding classes and class of service, see the Class of Service User Guide (Routers and EX9200 
Switches). 


e For EXP bits, see “MPLS Label Allocation” on page 422. 


e For differentiated services, see RFC 3270, Multi-Protocol Label Switching (MPLS) Support of Differentiated 
Services. 


e For information about how the IGPs and RSVP have been modified to support Differentiated 
Services-aware MPLS traffic engineering, see RFC 4124, Protocol Extensions for Support of 
Differentiated-Service-Aware MPLS Traffic Engineering. 


DiffServ-Aware Traffic Engineered LSPs Operation 


When configuring a DiffServ-aware traffic engineered LSP, you specify the class type and the bandwidth 
associated with it. The following occurs when an LSP is established with bandwidth reservation from a 
specific class type: 


1. The IGPs advertise how much unreserved bandwidth is available for the traffic engineering classes. 


2. When calculating the path for an LSP, CSPF is used to ensure that the bandwidth constraints are met 
for the class type carried by the LSP at the specified priority level. 


CSPF also checks to ensure that the bandwidth model is configured consistently on each router 
participating in the LSP. If the bandwidth model is inconsistent, CSPF does not compute the path (except 
for LSPs from class type ctO). 


3. Once a path is found, RSVP signals the LSP using the Classtype object in the path message. At each 
node in the path, the available bandwidth for the class types is adjusted as the path is set up. 


An LSP that requires bandwidth from a particular class (except class type ctO) cannot be established through 
routers that do not understand the Classtype object. Preventing the use of routers that do not understand 
the Classtype object helps to ensure consistency throughout the Differentiated Services domain by 
preventing the LSP from using a router that cannot support Differentiated Services. 


By default, LSPs are signaled with setup priority 7 and holding priority 0. An LSP configured with these 
values cannot preempt another LSP at setup time and cannot be preempted. 


It is possible to have both LSPs configured for DiffServ-aware traffic engineering and regular LSPs configured 
at the same time on the same physical interfaces. For this type of heterogeneous environment, regular 
LSPs carry best-effort traffic by default. Traffic carried in the regular LSPs must have the correct EXP 
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settings (either by remarking the EXP settings or by assuming that the traffic arrived with the correct EXP 
settings from the upstream router). 


Configuring Routers for DiffServ-Aware Traffic Engineering 


IN THIS SECTION 


@ = Configuring the Bandwidth Model | 1123 
@ Configuring Traffic Engineering Classes | 1124 
® Configuring Class of Service for DiffServ-Aware Traffic Engineering | 1126 


To configure DiffServ-aware traffic engineering, include the diffserv-te statement: 


diffserv-te { 
bandwidth-model { 
extended-mam; 
mam; 
rdm; 
} 
te-class-matrix { 
traffic-class { 
tenumber { 
priority priority; 
traffic-class ctnumber priority priority; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 


e [edit logical-systems logical-system-name protocols mpls] 


You must include the diffserv-te statement in the configuration on all routers participating in the 
Differentiated Services domain. However, you are not required to configure the traffic engineering class 
matrix (by including the te-class-matrix statement at the [edit protocols mpls diffserv-te] or [edit 
logical-systems logical-system-name protocols mpls diffserv-te] hierarchy level). 
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NOTE: To prevent the possibility of an incorrect configuration when migrating to Diffserv-aware 
traffic engineering, a policy control failure error might be triggered if there is conflict between 
the old LSPs and the newly configured TE-class matrix. 


An old node might request an LSP with setup and hold priorities in such a way that the 
combination of the ctO class and the priority does not match with the configured TE-class matrix. 
All LSPs on the router that are configured prior to configuring diffserv-aware traffic engineering 
are designated as being from class ctO. 


The error appears in the RSVP tracing logs as a Session preempted error. For the router where 
the error originates, the error could appear as follows: 
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For the router receiving the error, the error can appear as follows: 
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To configure DiffServ-aware traffic engineering, complete the procedures in the following sections: 


Configuring the Bandwidth Model 


You must configure a bandwidth model on all routers participating in the Differentiated Services domain. 
The bandwidth models available are MAM, extended MAM, and RDM: 


e Maximum allocation bandwidth constraints model (MAM)—Defined in RFC 4125, Maximum Allocation 


Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering. 


e Extended MAM-—A proprietary bandwidth model that behaves much like standard MAM. If you configure 


multiclass LSPs, you must configure the extended MAM bandwidth model. 


e Russian-dolls bandwidth allocation model (RDM)—Makes efficient use of bandwidth by allowing the 
class types to share bandwidth. RDM is defined in RFC 4127, Russian Dolls Bandwidth Constraints Model 
for Diffserv-aware MPLS Traffic Engineering. 


To configure a bandwidth model, include the bandwidth-model statement and specify one of the bandwidth 
model options: 


bandwidth-model { 
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extended-mam; 
mam; 


rdm; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls diffserv-te] 


e [edit logical-systems logical-system-name protocols mpls diffserv-te] 


NOTE: If you change the bandwidth model on an ingress router, all the LSPs enabled on the 
router are taken down and resignaled. 


Configuring Traffic Engineering Classes 


Configuring traffic engineering classes is optional. Table 25 on page 1124 shows the default values for 
everything in the traffic engineering class matrix. The default mapping is expressed in terms of the default 
forwarding classes defined in the CoS configuration. 


Table 25: Default Values for the Traffic Engineering Class Matrix 


Traffic Engineering Class Class Type Queue Priority 
ted ctO 0) 7 
te1 ct1 1 7 
te2 ct2 2 7 
te3 ct3 3 7 
te4 ctO 6) 0) 
te5 ct1 1 0 
te6 ct2 2 0 
te7 ct3 3 0 


If you want to override the default mappings, you can configure traffic engineering classes O through 7. 
For each traffic engineering class, you configure a class type (or queue) from O through 3. For each class 
type, you configure a priority from O through 7. 
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To configure traffic engineering classes explicitly, include the te-class-matrix statement: 


te-class-matrix { 
tenumber { 
priority priority; 
traffic-class { 
ctnumber priority priority; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls diffserv-te] 


e [edit logical-systems logical-system-name protocols mpls diffserv-te] 


The following example shows how to configure traffic engineering class teO with class type ct1 and a 
priority of 4: 


[edit protocols mpls diffserv-te] 
te-class-matrix { 
teO traffic-class ct1 priority 4; 


NOTE: If you explicitly configure a value for one of the traffic engineering classes, all the default 
values in the traffic engineering class matrix are dropped. 


When you explicitly configure traffic engineering classes, you must also configure a bandwidth 
model; otherwise, the configuration commit operation fails. 


Requirements and Limitations for the Traffic Engineering Class Matrix 


When you configure a traffic engineering class matrix, be aware of the following requirements and 
limitations: 


e Amapping configuration is local and affects only the router on which it is configured. It does not affect 
other systems participating in the differentiated services domain. However, for a Differentiated Services 
domain to function properly, you need to configure the same traffic engineering class matrix on all the 
routers participating in the same domain. 


e When explicitly configuring traffic engineering classes, you must configure the classes in sequence (teO, 
te1, te2, te3, and so on); otherwise, the configuration commit operation fails. 
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The first traffic engineering class you configure must be teO; otherwise, the configuration commit operation 
fails. 


Configuring Class of Service for DiffServ-Aware Traffic Engineering 


To configure DiffServ-aware traffic engineering, you must also configure class of service. The following 
example illustrates a class-of-service configuration that would allocate 25 percent of the link bandwidth 
to each class: 


class-of-service { 
interfaces { 
all { 
scheduler-map simple-map; 


} 
scheduler-maps { 
simple-map { 
forwarding-class assured-forwarding scheduler simple_sched; 
forwarding-class best-effort scheduler simple_sched; 
forwarding-class network-control scheduler simple_sched; 
forwarding-class expedited-forwarding scheduler simple_sched; 


} 
schedulers { 
simple_sched { 
transmit-rate percent 25; 
buffer-size percent 25; 


Configuring LSPs for DiffServ-Aware Traffic Engineering 


IN THIS SECTION 


Configuring Class of Service for the Interfaces | 1127 
Configuring IGP | 1127 


9 
® 
@ = Configuring Traffic-Engineered LSPs | 1128 
@ Configuring Policing for LSPs | 1128 

e 


Configuring Fast Reroute for Traffic-Engineered LSPs | 1129 
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You must configure the Differentiated Services domain (see “Configuring Routers for DiffServ-Aware 
Traffic Engineering” on page 1122) before you can enable DiffServ-aware traffic engineering for LSPs. The 
Differentiated Services domain provides the underlying class types and corresponding traffic engineering 
classes that you reference in the LSP configuration. The traffic engineering classes must be configured 
consistently on each router participating in the Differentiated Services domain for the LSP to function 
properly. 


NOTE: You must configure either MAM or RDM as the bandwidth model when you configure 
DiffServ-aware traffic engineering for LSPs. See “Configuring the Bandwidth Model” on page 1123. 


The actual data transmitted over this Differentiated Services domain is carried by an LSP. Each LSP relies 
on the EXP bits of the MPLS packets to enable DiffServ-aware traffic engineering. Each LSP can carry 
traffic for a single class type. 


All the routers participating in the LSP must be Juniper Networks routers running Junos OS Release 6.3 
or later. The network can include routers from other vendors and Juniper Networks routers running earlier 
versions of the Junos OS. However, the DiffServ-aware traffic engineering LSP cannot traverse these 
routers. 


NOTE: You cannot simultaneously configure multiclass LSPs and DiffServ-aware traffic 
engineering LSPs on the same router. 


To enable DiffServ-aware traffic engineering for LSPs, you need to configure the following: 


Configuring Class of Service for the Interfaces 


The existing class-of-service (CoS) infrastructure ensures that traffic that is consistently marked receives 
the scheduling guarantees for its class. The classification, marking, and scheduling necessary to accomplish 
this are configured using the existing Junos OS CoS features. 


NOTE: The Junos OS does not support CoS on ATM interfaces. 


For information about how to configure CoS, see the Class of Service User Guide (Routers and EX9200 
Switches). 


Configuring IGP 


You can configure either IS-IS or OSPF as the IGP. The IS-IS and OSPF configurations for routers supporting 
LSPs are standard. For information about how to configure these protocols, see the Junos OS Routing 
Protocols Library. 
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Configuring Traffic-Engineered LSPs 


You configure an LSP by using the standard LSP configuration statements and procedures. To configure 
DiffServ-aware traffic engineering for the LSP, specify a class type bandwidth constraint by including the 
bandwidth statement: 


label-switched-path Isp-name { 
bandwidth { 
ctnumber bps; 


For a list of hierarchy levels at which you can include the bandwidth statement, see the statement summary 
sections for this statement. 


If you do not specify a bandwidth for a class type, ctO is automatically specified as the queue for the LSP. 
You can configure only one class type for each LSP, unlike multiclass LSPs. 


The class type statements specify bandwidth (in bits per second) for the following classes: 


e ctO—Bandwidth reserved for class O 
e ct1—Bandwidth reserved for class 1 
e ct2—Bandwidth reserved for class 2 


e ct3—Bandwidth reserved for class 3 
You can configure setup and holding priorities for an LSP, but the following restrictions apply: 


e The combination of class and priority must be one of the configured traffic engineering classes. The 
default setup priority is 7 and the default holding priority is O. 


e Configuring an invalid combination of class type and priority causes the commit operation to fail. 


e Automatic bandwidth allocation is not supported. If you configure automatic bandwidth allocation, the 
commit operation fails. 


e LSPs configured with the bandwidth statement but without specifying a class type use the default class 
type ctO. 


e For migration issues, see Internet draft draft-ietf-tewg-diff-te-proto-07.txt. 


Configuring Policing for LSPs 


Policing allows you to control the amount of traffic forwarded through a particular LSP. Policing helps to 
ensure that the amount of traffic forwarded through an LSP never exceeds the requested bandwidth 
allocation. You can configure multiple policers for each LSP. 


For information about how to configure a policer for an LSP, see “Configuring Policers for LSPs” on page 149. 


Configuring Fast Reroute for Traffic-Engineered LSPs 


You can configure fast reroute for traffic engineered LSPs (LSPs carrying a single class of traffic). It is also 
possible to reserve bandwidth on the detour path for the class of traffic when fast reroute is enabled. The 
same class type number is used for both the traffic engineered LSP and its detour. 


If you configure the router to reserve bandwidth for the detour path, a check is made to ensure that the 
link is capable of handling DiffServ-aware traffic engineering and for CoS capability before accepting it as 
a potential detour path. Unsupported links are not used. 


You can configure the amount of bandwidth to reserve for detours using either the bandwidth statement 
or the bandwidth-percent statement. You can only configure one these statements at a time. If you do 
not configure either the bandwidth statement or the bandwidth-percent statement, the default setting is 
to not reserve bandwidth for the detour path (the bandwidth guarantee will be lost if traffic is switched 
to the detour). 


When you configure the bandwidth statement, you can specify the specific amount of bandwidth (in bits 
per second [bps]) you want to reserve for the detour path. For information, see “Configuring Fast Reroute” 
on page 474. 


The bandwidth-percent statement allows you to specify the bandwidth of the detour path as a percentage 
of the bandwidth configured for the protected path. For example, if you configure 100 millions bps of 
bandwidth for the protected path and configure 20 for the bandwidth-percent statement, the detour path 
will have 20 million bps of bandwidth reserved for its use. 


To configure the percent of bandwidth used by the detour path based on the bandwidth of the protected 


path, include the bandwidth-percent statement: 


bandwidth-percent percentage; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name fast-reroute] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name fast-reroute] 
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CHAPTER 13 


Operation, Administration, and Maintenance (OAM) 
for MPLS 


IN THIS CHAPTER 


@ MPLS OAM Configuration | 1131 


| MPLS OAM Configuration 
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Configuring the MPLS Transport Profile for OAM 


IN THIS SECTION 


@  MPLSTransport Profile Overview | 1131 
@ ~~ Example: Configuring the MPLS Transport Profile for OAM | 1132 


MPLS Transport Profile Overview 


RFC 5654, Requirements of an MPLS Transport Profile, describes the requirements for the MPLS Transport 
Profile (MPLS-TP) that extends capabilities for Operation, Administration, and Maintenance (OAM) when 
MPLS is used for transport services and transport network operations. These capabilities help in 
troubleshooting and maintenance of a pseudowire or label-switched path (LSP). 
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MPLS-TP mechanisms for OAM contain two main components: 


e Generic Associated Channel Label (GAL)—A special label that enables an exception mechanism that 
informs the egress label-switching router (LSR) that a packet it receives on an LSP belongs to an associated 
control channel or the control plane. 


e Generic Associated Channel Header (G-Ach)—A special header field that identifies the type of payload 
contained in the MPLS label-switched paths (LSPs). G-Ach has the same format as a pseudowire associated 
control channel header. 


For more information about MPLS-TP, see RFC 5654, Requirements of an MPLS Transport Profile. For specific 
information about GAL and G-Ach, see RFC 5586, MPLS Generic Associated Channel. 


The following capabilities are supported in the Junos OS implementation of MPLS-TP: 


e MPLS-TP OAM can send and receive packets with GAL and G-Ach, without IP encapsulation. 


e Two unidirectional RSVP LSPs between a pair of routers can be associated with each other to create an 
associated bidrectional LSP for binding a path for the GAL and G-Ach OAM messages. A single 
Bidirectional Forwarding Detection (BFD) session is established for the associated bidirectional LSP. 


Example: Configuring the MPLS Transport Profile for OAM 


IN THIS SECTION 


Requirements | 1132 
Overview | 1132 
Configuration | 1135 


Verification | 1146 


This example shows how to configure the MPLS Transport Profile (MPLS-TP) for sending and receiving 
of OAM GAL and G-Ach messages across a label-switched path (LSP). 


Requirements 
This example uses the following hardware and software components: 
e Six devices that can be a combination of M Series, MX Series, and T Series routers 


e Junos OS Release 12.1 or later running on the devices 


Overview 


Junos OS Release 12.1 and later support MPLS Transport Profile (MPLS-TP) Operation, Administration, 
and Maintenance (OAM) capabilities. MPLS-TP introduces new capabilities for OAM when MPLS is used 
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for transport services and transport network operations. This includes configuring Generic Associated 
Channel Label (GAL) and Generic Associated Channel Header (G-Ach) for OAM messages. 


This example shows how to configure MPLS-TP OAM capability to send and receive GAL and G-Ach OAM 
messages without IP encapsulation. In addition, it also shows how to associate two unidirectional RSVP 
label-switched paths (LSPs) between a pair of routers to create an associated bidirectional LSP for binding 
a path for the GAL and G-Ach OAM messages. 


Junos OS Release 12.1 and later support the following MPLS-TP capabilities: 


e MPLS-TP OAM capability and the infrastructure required for MPLS applications to send and receive 
packets with GAL and G-Ach, without IP encapsulation. 


e LSP-ping and Bidirectional Forwarding Detection (BFD) applications to send and receive packets using 
GAL and G-Ach, without IP encapsulation on transport LSPs. 


e The association of two unidirectional RSVP LSPs, between a pair of routers, with each other to create 
an associated bidirectional LSP for binding a path for the GAL and G-Ach OAM messages. The associated 
bidirectional LSP model is supported only for associating the primary paths. A single BFD session is 
established for the associated bidirectional LSP. 


Junos OS Release 12.1 and later does not support the following MPLS-TP capabilities: 


e Point-to-multipoint RSVP LSPs and BGP LSPs 


e Loss Measurement and Delay Measurement 
You can enable GAL and G-Ach OAM operation using the following configuration statements: 


e mpls-tp-mode—Include this statement at the [edit protocols mpls oam] hierarchy level to enable GAL 
and G-Ach OAM operation, without IP encapsulation, on all LSPs in the MPLS network. 


[edit protocols mpls oam] 
mpls-tp-mode; 


Include this statement at the [edit protocols mpls label-switched-path Isp-name oam] hierarchy level to 
enable GAL and G-Ach OAM operation without IP encapsulation on a specific LSP in the network. 


[edit protocols mpls label-switched-path Isp-name oam] 
mpls-tp-mode; 
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NOTE: Starting with Junos OS Release 16.1, MPLS-TP supports two additional channel types 
for the default LSPING (Ox0008) channel type under the mpls-tp-mode statement. These 
additional channel types provide on-demand connectivity verification (CV) with and without 
IP/UDP encapsulation. 


e On-demand CV (0x0025)—This channel type is a new pseudowire channel type and is used 
for on-demand CV without IP/UDP encapsulation, where IP addressing is not available or 
non-IP encapsulation is preferred. 


e IPv4 (0x0021)—This channel type uses the IP/UDP encapsulation and provides interoperability 
support with other vendor devices using IP addressing. 


The GACH-TLV is used along with the default LSPING channel type. As per RFC 7026, 
GACH-TLV is deprecated for Ox0021 and Ox0025 channel types. 


To configure a channel type for MPLS-TP, include the Isping-channel-type channel-type 
statement at the [edit protocols mpls label-switched-path Isp-name oam mpls-tp-mode] and 
[edit protocols mpls oam mpls-tp-mode] hierarchy levels. 


e associate-Isp Isp-name from from-ip-address—|nclude this statement at the [edit protocols mpls 
label-switched-path Isp-name] hierarchy level to configure associated bidirectional LSPs on the two ends 
of the LSP. 


[edit protocols mpls label-switched-path Isp-name ] 
associate-Isp Isp-name { 
from from-ip-address; 


The from from-ip-address configuration for the LSP is optional. If omitted, it is derived from the to address 
of the ingress LSP configuration. 


e transit-Isp-association—Include this statement at the [edit protocols mpls] 
hierarchy level to associate two LSPs at a transit router. 


[edit protocols mpls] 
transit-Isp-association transit-association-Isp-group-name { 
Isp-name-1 name-of-associated-Isp-1; 
from-1 address-of-associated-Isp-1; 
Isp-name-2 name-of-associated-Isp-2; 
from-2 address-of-associated-Isp-2; 
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The association of the LSPs in the transit nodes is useful for the return LSP path for TTL-expired LSP 


ping packets or traceroute. 


In this example, RO is the ingress router and R4 is the egress router. R1, R2, R3, and R5 are transit routers. 
The associated bidirectional LSP is established between the transit routers for sending and receiving the 
GAL and G-Ach OAM messages. 


Figure 93 on page 1135 shows the topology used in this example. 


Figure 93: MPLS-TP OAM Associated Bidirectional LSPs 
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Configuration 


CLI Quick Configuration 


NOTE: This example shows the configuration on all devices and shows step-by-step procedures 
for configuring the ingress router, RO, and transit router R1. Repeat the step-by-step procedure 
described for the ingress router, RO, on the egress router, R4. Repeat the step-by-step procedure 
for the transit router, R1, on the other transit routers, R2, R3, and R5. Be sure to modify the 
appropriate interface names, addresses, and other parameters appropriately. 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


1136 


Router RO 


set interfaces ge-4/1/1 unit 0 family inet address 10.10.11.1/30 
set interfaces ge-4/1/1 unit 0 family iso 

set interfaces ge-4/1/1 unit 0 family inet6 

set interfaces ge-4/1/1 unit 0 family mpls 

set interfaces ge-5/0/0 unit 0 family inet address 10.10.10.1/30 
set interfaces ge-5/0/0 unit 0 family iso 

set interfaces ge-5/0/0 unit 0 family inet6 

set interfaces ge-5/0/0 unit 0 family mpls 

set protocols rsvp interface ge-5/0/0.0 

set protocols rsvp interface ge-4/1/1.0 

set protocols mpls label-switched-path r0-to-r4 to 10.255.8.86 

set protocols mpls label-switched-path r0-to-r4 oam mpls-tp-mode 
set protocols mpls label-switched-path r0-to-r4 associate-Isp r4-to-rO from 10.255.8.86 
set protocols mpls interface ge-5/0/0.0 

set protocols mpls interface ge-4/1/1.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-5/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-4/1/1.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 


Router R1 


set interfaces ge-0/0/5 unit 0 family inet address 10.10.10.2/30 
set interfaces ge-0/0/5 unit 0 family iso 

set interfaces ge-0/0/5 unit 0 family inet6 

set interfaces ge-0/0/5 unit 0 family mpls 

set interfaces ge-0/2/2 unit 0 family inet address 10.10.12.2/30 
set interfaces ge-0/2/2 unit 0 family iso 

set interfaces ge-0/2/2 unit 0 family inet6 

set interfaces ge-0/2/2 unit 0 family mpls 

set interfaces ge-1/0/2 unit 0 family inet address 10.10.13.2/30 
set interfaces ge-1/0/2 unit 0 family iso 

set interfaces ge-1/0/2 unit 0 family inet6 

set interfaces ge-1/0/2 unit 0 family mpls 

set interfaces ge-2/0/2 unit 0 family inet address 10.10.11.2/30 
set interfaces ge-2/0/2 unit 0 family iso 

set interfaces ge-2/0/2 unit 0 family inet6 

set interfaces ge-2/0/2 unit 0 family mpls 
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set protocols rsvp interface ge-0/2/2.0 

set protocols rsvp interface ge-0/0/5.0 

set protocols rsvp interface ge-1/0/2.0 

set protocols rsvp interface ge-2/0/2.0 

set protocols mpls transit-Ilsp-association trace1 Isp-name-1 r0-to-r4 
set protocols mpls transit-Ilsp-association trace1 from-1 10.255.8.207 
set protocols mpls transit-Ilsp-association trace1 Isp-name-2 r4-to-rO 
set protocols mpls transit-Isp-association trace1 from-2 10.255.8.86 
set protocols mpls interface ge-0/0/5.0 

set protocols mpls interface ge-2/0/2.0 

set protocols mpls interface ge-1/0/2.0 

set protocols mpls interface ge-0/2/2.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 

set protocols ospf area 0.0.0.0 interface ge-0/2/2.0 metric 100 

set protocols ospf area 0.0.0.0 interface ge-1/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-2/0/2.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 


Router R2 


set interfaces ge-0/2/3 unit 0 family inet address 10.10.13.1/30 

set interfaces ge-0/2/3 unit 0 family iso 

set interfaces ge-0/2/3 unit 0 family inet6 

set interfaces ge-0/2/3 unit 0 family mpls 

set interfaces ge-1/3/2 unit 0 family inet address 10.10.14.1/30 

set interfaces ge-1/3/2 unit 0 family iso 

set interfaces ge-1/3/2 unit 0 family inet6 

set interfaces ge-1/3/2 unit 0 family mpls 

set interfaces ge-1/3/4 unit 0 family inet address 10.10.15.1/30 

set interfaces ge-1/3/4 unit 0 family iso 

set interfaces ge-1/3/4 unit 0 family inet6 

set interfaces ge-1/3/4 unit 0 family mpls 

set protocols rsvp interface ge-0/2/3.0 

set protocols rsvp interface ge-1/3/2.0 

set protocols rsvp interface ge-1/3/4.0 

set protocols mpls transit-Isp-association trace1 Isp-name-1 r0-to-r4 
set protocols mpls transit-Ilsp-association trace1 from-1 10.255.8.207 
set protocols mpls transit-Isp-association trace1 Isp-name-2 r4-to-rO 
set protocols mpls transit-Isp-association trace1 from-2 10.255.8.86 
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set protocols mpls interface ge-0/2/3.0 

set protocols mpls interface ge-1/3/2.0 

set protocols mpls interface ge-1/3/4.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/2/3.0 

set protocols ospf area 0.0.0.0 interface ge-1/3/2.0 

set protocols ospf area 0.0.0.0 interface ge-1/3/4.0 metric 100 
set protocols ospf area 0.0.0.0 interface lo0.0 passive 


Router R3 


set interfaces ge-1/2/1 unit 0 family inet address 10.10.16.2/30 

set interfaces ge-1/2/1 unit 0 family iso 

set interfaces ge-1/2/1 unit 0 family inet6 

set interfaces ge-1/2/1 unit 0 family mpls 

set interfaces ge-2/0/7 unit 0 family inet address 10.10.17.2/30 

set interfaces ge-2/0/7 unit 0 family iso 

set interfaces ge-2/0/7 unit 0 family inet6 

set interfaces ge-2/0/7 unit 0 family mpls 

set interfaces ge-2/2/0 unit 0 family inet address 10.10.14.2/30 

set interfaces ge-2/2/0 unit 0 family iso 

set interfaces ge-2/2/0 unit 0 family inet6 

set interfaces ge-2/2/0 unit 0 family mpls 

set protocols rsvp interface ge-2/2/0.0 

set protocols rsvp interface ge-1/2/1.0 

set protocols rsvp interface ge-2/0/7.0 

set protocols mpls transit-Ilsp-association trace1 Isp-name-1 r0-to-r4 
set protocols mpls transit-Ilsp-association trace1 from-1 10.255.8.207 
set protocols mpls transit-Isp-association trace1 Isp-name-2 r4-to-rO 
set protocols mpls transit-Ilsp-association trace1 from-2 10.255.8.86 
set protocols mpls interface ge-2/2/0.0 

set protocols mpls interface ge-1/2/1.0 

set protocols mpls interface ge-2/0/7.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-2/2/0.0 

set protocols ospf area 0.0.0.0 interface ge-1/2/1.0 

set protocols ospf area 0.0.0.0 interface ge-2/0/7.0 metric 100 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 


Router R4 
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set interfaces ge-0/0/3 unit 0 family inet address 10.10.16.1/30 
set interfaces ge-0/0/3 unit 0 family iso 

set interfaces ge-0/0/3 unit 0 family inet6 

set interfaces ge-0/0/3 unit 0 family mpls 

set protocols rsvp interface ge-0/0/3.0 

set protocols mpls label-switched-path r4-to-r0 to 10.255.8.207 
set protocols mpls label-switched-path r4-to-rO oam mpls-tp-mode 
set protocols mpls label-switched-path r4-to-rO associate-Isp rO-to-r4 from 10.255.8.207 
set protocols mpls interface ge-0/0/3.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 


Router R5 


set interfaces ge-1/2/0 unit 0 family inet address 10.10.15.2/30 

set interfaces ge-1/2/0 unit 0 family iso 

set interfaces ge-1/2/0 unit 0 family inet6 

set interfaces ge-1/2/0 unit 0 family mpls 

set interfaces ge-2/0/0 unit 0 family inet address 10.10.12.1/30 

set interfaces ge-2/0/0 unit 0 family iso 

set interfaces ge-2/0/0 unit 0 family inet6 

set interfaces ge-2/0/0 unit 0 family mpls 

set interfaces ge-4/0/7 unit 0 family inet address 10.10.17.1/30 

set interfaces ge-4/0/7 unit 0 family iso 

set interfaces ge-4/0/7 unit 0 family inet6 

set interfaces ge-4/0/7 unit 0 family mpls 

set protocols rsvp interface ge-2/0/0.0 

set protocols rsvp interface ge-1/2/0.0 

set protocols rsvp interface ge-4/0/7.0 

set protocols mpls transit-Isp-association trace1 Isp-name-1 r0-to-r4 
set protocols mpls transit-Ilsp-association trace1 from-1 10.255.8.207 
set protocols mpls transit-Ilsp-association trace1 Isp-name-2 r4-to-rO 
set protocols mpls transit-Ilsp-association trace1 from-2 10.255.8.86 
set protocols mpls interface ge-2/0/0.0 

set protocols mpls interface ge-1/2/0.0 

set protocols mpls interface ge-4/0/7.0 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-2/0/0.0 metric 100 

set protocols ospf area 0.0.0.0 interface ge-1/2/0.0 metric 100 


set protocols ospf area 0.0.0.0 interface ge-4/0/7.0 metric 100 
set protocols ospf area 0.0.0.0 interface lo0.0 passive 


Configuring Device RO 


Step-by-Step Procedure 


To configure the ingress router, RO: 


1. Configure the interfaces. 


[edit interfaces] 

user@RO# set ge-4/1/1 unit O family inet address 10.10.11.1/30 
user@RO# set ge-4/1/1 unit 0 family iso 

user@RO# set ge-4/1/1 unit 0 family inet6 

user@RO# set ge-4/1/1 unit 0 family mpls 

user@RO# set ge-5/0/0 unit O family inet address 10.10.10.1/30 
user@RO# set ge-5/0/0 unit 0 family iso 

user@RO# set ge-5/0/0 unit 0 family inet6 

user@RO# set ge-5/0/0 unit O family mpls 


2. Configure MPLS on the interfaces. 


[edit protocols mpls] 
user@RO# set interface ge-5/0/0.0 
user@RO# set interface ge-4/1/1.0 


3. Configure an interior gateway protocol, such as OSPF. 


[edit protocols ospf] 

user@RO# set traffic-engineering 

user@RO# set area 0.0.0.0 interface ge-5/0/0.0 
user@RO# set area 0.0.0.0 interface ge-4/1/1.0 
user@RO# set area 0.0.0.0 interface lo0.0 passive 


4. Configure a signaling protocol, such as RSVP. 


[edit protocols rsvp] 
user@RO# set interface ge-5/0/0.0 
user@RO# set interface ge-4/1/1.0 
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5. Configure the LSP. 


[edit protocols mpls] 
user@RO# set label-switched-path r0-to-r4 to 10.255.8.86 


6. Enable GAL and G-Ach OAM operation without IP encapsulation on the LSPs. 


[edit protocols mpls] 
user@RO# set label-switched-path r0-to-r4 oam mpls-tp-mode 


7. Configure associated bidirectional LSPs on the two ends of the LSP. 


[edit protocols mpls] 
user@RO# set label-switched-path r0-to-r4 associate-Isp to-rO from 10.255.8.86 


8. After you are done configuring the device, commit the configuration. 


[edit] 
user@RO# commit 


Results 


Confirm your configuration by issuing the show interfaces and show protocols commands. 


user@RO# show interfaces 
ge-4/1/1 { 
unit O { 
family inet { 
address 10.10.11.1/30; 

} 

family iso; 

family ineté; 

family mpls; 


} 
ge-5/0/0 { 
unit O { 
family inet { 
address 10.10.10.1/30; 
} 


family iso; 


family ineté6; 
family mpls; 


user@RO# show protocols 
rsvp { 
interface ge-5/0/0.0; 
interface ge-4/1/1.0; 
} 
mpls { 
label-switched-path rO-to-r4 { 
to 10.255.8.86; 
oam mpls-tp-mode; 
associate-Isp r4-to-rO { 
from 10.255.8.86; 


} 
interface ge-4/1/1.0; 
interface ge-5/0/0.0; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-5/0/0.0; 
interface ge-4/1/1.0; 
interface 100.0 { 


passive; 


Configuring Device R1 


Step-by-Step Procedure 


To configure the transit router, R1: 


1. Configure the interfaces. 


[edit interfaces] 

user@R1# set ge-0/0/5 unit O family inet address 10.10.10.2/30 
user@R1# set ge-0/0/5 unit 0 family iso 

user@R1# set ge-0/0/5 unit 0 family inet6 

user@R1# set ge-0/0/5 unit 0 family mpls 
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user@R1# set ge-0/2/2 unit O family inet address 10.10.12.2/30 
user@R1# set ge-0/2/2 unit 0 family iso 

user@R1# set ge-0/2/2 unit 0 family inet6 

user@R1# set ge-0/2/2 unit 0 family mpls 

user@R1# set ge-2/0/2 unit O family inet address 10.10.11.2/30 
user@R1# set ge-2/0/2 unit 0 family iso 

user@R1# set ge-2/0/2 unit 0 family inet6 

user@R1# set ge-2/0/2 unit 0 family mpls 

user@R1# set ge-1/0/2 unit 0 family inet address 10.10.13.2/30 
user@R1# set ge-1/0/2 unit 0 family iso 

user@R1# set ge-1/0/2 unit 0 family inet6 

user@R1# set ge-1/0/2 unit 0 family mpls 


2. Configure MPLS on the interfaces. 


[edit protocols mpls] 

user@R1# set interface ge-0/0/5.0 
user@R1# set interface ge-2/0/2.0 
user@R1# set interface ge-1/0/2.0 
user@R1# set interface ge-0/2/2.0 


3. Configure an interior gateway protocol, such as OSPF. 


[edit protocols ospf] 

user@R1# set traffic-engineering 

user@R1# set area 0.0.0.0 interface ge-0/0/5.0 

user@R1# set area 0.0.0.0 interface ge-2/0/2.0 

user@R1# set area 0.0.0.0 interface ge-1/0/2.0 

user@R1# set area 0.0.0.0 interface ge-0/2/2.0 metric 100 
user@R1# set area 0.0.0.0 interface lo0.0 passive 


4. Configure a signaling protocol, such as RSVP. 


[edit protocols rsvp] 

user@R1# set interface ge-0/0/5.0 
user@R1# set interface ge-2/0/2.0 
user@R1# set interface ge-1/0/2.0 
user@R1# set interface ge-0/2/2.0 


5. Configure the association of the two LSPs on the transit router. 


[edit protocols mpls] 

user@R1# set transit-Ilsp-association trace1 Isp-name-1 r0-to-r4 
user@R1# set transit-Ilsp-association trace1 from-1 10.255.8.207 
user@R1# set transit-Ilsp-association trace1 Isp-name-2 r4-to-rO 
user@R1# set transit-Isp-association trace1 from-2 10.255.8.86 


6. If you are done configuring the device, commit the configuration. 
[edit] 


user@R1# commit 


Results 


Confirm your configuration by issuing the show interfaces and show protocols commands. 


user@R1# show interfaces 
ge-0/0/5 { 
unit O { 
family inet { 
address 10.10.10.2/30; 

} 

family iso; 

family inet6; 

family mpls; 


} 
ge-0/2/2 { 
unit O { 
family inet { 
address 10.10.12.2/30; 
} 
family iso; 
family ineté6; 
family mpls; 


} 
ge-2/0/2 { 
unit O { 
family inet { 
address 10.10.11.2/30; 
} 
family iso; 
family ineté; 
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family mpls; 


} 
ge-1/0/2 { 
unit O { 
family inet { 
address 10.10.13.2/30; 
} 
family iso; 
family ineté; 
family mpls; 


user@R1# show protocols 
rsvp { 
interface ge-0/0/5.0; 
interface ge-2/0/2.0; 
interface ge-1/0/2.0; 
interface ge-0/2/2.0; 
} 
mpls { 
transit-Isp-association trace1 { 
Isp-name-1 r0-to-r4; 
from-1 10.255.8.207; 
Isp-name-2 r4-to-r0; 
from-2 10.255.8.86; 
} 
interface ge-0/0/5.0; 
interface ge-2/0/2.0; 
interface ge-1/0/2.0; 
interface ge-0/2/2.0; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-0/0/5.0; 
interface ge-1/0/2.0; 
interface ge-2/0/2.0; 
interface ge-0/2/2.0 { 
metric 100; 
} 
interface 100.0 { 


passive; 


Verification 


Confirm that the configuration is working properly. 


Verifying Associated Bidirectional LSPs 


Purpose 


Verify that the associated bidirectional LSP configuration is working properly. 
Action 


user@host> show mpls Isp 


Ingress LSP: 1 sessions 


To From Stake Rte P ActivePath LSPname 
1O,LO Ltt I10.255.8.86 Up @ r0-to-r4 Assoc-Bidir 
Total 1 displayed, Up 1, Down 0 








Egress LSP: 1 sessions 
To From State Rt Style Labelin Labelout LSPname 
IO .1O 16. IO,ASS<8.207 we @Q a me 3 CAFO) AS See EsueliLie 





Total 2 displayed, Up 2, Down 0 


Transit LSP: 1 sessions 
To From State Rt Style Labelin Labelout LSPname 
IQ LO 10.2 10.255. 8.168 we 1 1 FF 301264 3 “wO-tO-24 Assoe—isichir 





Total 3 displayed, Up 3, Down 0 


user@host> show mpls Isp detail 


Ingress LSP: 1 sessions 


19,20 ,12,i 
From: 10.255.8.86, State: Up, ActiveRoute: 0, LSPname: r0Q-to-r4 
Associated Bidirectional 
Associated LSP: r0-to-r4, 10.255.8.86 
ActivePath: (primary) 
LSPtype: Static Configured 





LoadBalance: Random 
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Encoding type: Packet, Switching type: PSC-1, GPID: 


+ 





Primary State: Up 





Egress LSP: 1 sessions 


10.255 .102 249 
From: 110.255.102.172, LSPstate: Up, ActiveRoute: 0 
LSPname: r4-to-r0, LSPpath: Primary 
Associated Bidirectional 


ASSocuiacecd SPs IO 10,16 1, tore 


Unknown 





Suggested label received: -, Suggested label sent: 








Recovery label received: -, Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Waim@e iheiricg dl4. Samees wien dwn 7 BZilsdileOs 2O ili 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 6 receiver 14468 protocol 0 
PACE Gia rome One ls Oil slaun (Cie 27/10)/ Ol 0) eee Aano ktas 
Adspec: received MTU 1500 








PATH sentto: localclient 





RESV revfrom: localclient 
RECoOrd somes me OnnOR) UAr 2 OR MOres las<selkie> 





Transit LSP: 1 sessions 


10.255. 102, 30) 
weems IO.255 102172, WSPSEEEaS Wo, AGE WelouIre™ Ail 
LSPname: to_airstream, LSPpath: Primary 
Associated Bidirectional 
Associated LSP: r0-to-r4, 10.255.8.168 
Suggested label received: -, Suggested label 











Recovery label received: -, Recovery label sent: 3 
Resv style: 1 FF, Label in: 301264, Label out: 3 
aime Ieirices i132, Samees mwiel Twn 7 2ilsd@dese 20 ii 





Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 28 receiver 14465 protocol 0 
Pus teowAreoms LO,O IS. (cGe—2/0/0.0) BA jokes 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.10.10.1 (ge-3/0/0.0) 84 pkts 

RE SVieGe we com Om Onn Om em (ce>Sy/0//00) ms 4apkas 
lipgolkeic wemicees AL), 10) 5 Ale). iL 














user@host> show mpls Isp bidirectional 


Lecorel rouwieSes 10.0, 16. 10,10.1S.2 10,10,13,1 <selir> 10.,10,10,i 
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Ingress LSP: 1 session 
To Prom State Rt P ActivePath LSPname 
10) 5255618) 536 10) 255685207) Up Ons 20 =co—ied! 


Assoc-Bidir 





Total 1 displayed, Up 1, Down 0 
Aug 28 06:56:26 [TRACE] [RO coleman re0] 








Egress LSP: 1 session 

To From State Rt Style Labelin Labelout LSPname 
10) 2555.20 7) 10 255 58) 536 Up @ i ine 5 = cee) 
Assoc-Bidir 

Total 1 displayed, Up 1, Down 0 

Aug 28 06:56:26 [TRACE] [RO coleman re0] 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 


The output of the show mpls Isp, show mpls detail, and show mpls bidirectional commands displays the 
details of the associated bidirectional LSPs and the LSP association information. 


Release History Table 


Release Description 


16.1 Starting with Junos OS Release 16.1, MPLS-TP supports two additional channel types for 
the default LSPING (Ox0008) channel type under the mpls-tp-mode statement. 


Configuring OAM Ingress Policies for LDP 


Using the ingress-policy statement, you can configure an Operation, Administration, and Management 
(OAM) policy to choose which forwarding equivalence classes (FECs) need to have OAM enabled. If the 
FEC passes through the policy or if the FEC is explicitly configured, OAM is enabled for a FEC. For FECs 
chosen using a policy, the BFD parameters configured under [edit protocols Idp oam bfd-liveness-detection] 
are applied. 


You configure the OAM ingress policy at the [edit policy-options] hierarchy level. To configure an OAM 
ingress policy, include the ingress-policy statement: 


ingress-policy ingress-policy-name; 


You can configure this statement at the following hierarchy levels: 


e [edit protocols Idp oam] 
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e [edit logical-systems logical-system-name protocols Idp oam] 


NOTE: ACX Series routers do not support [edit logical-systems] hierarchy level. 


Tracing MPLS and LSP Packets and Operations 


To trace MPLS and LSP packets and operations, include the traceoptions statement: 


traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag; 


For a list of hierarchy levels at which you can include this statement, see the statement summary section 
for this statement. 


You can specify the following MPLS-specific flags in the MPLS traceoptions statement: 


e all—Trace all operations. 


e connection—Trace all circuit cross-connect (CCC) activity. 


connection-detail—Trace detailed CCC activity. 


e cspf—Trace CSPF computations. 


cspf-link—Trace links visited during CSPF computations. 


cspf-node—Trace nodes visited during CSPF computations. 


e error—Trace MPLS error conditions. 


graceful-restart—Trace MPLS graceful restart events. 


e Isping—Trace LSP ping packets and return codes. 


nsr-synchronization—Trace nonstop routing (NSR) synchronization events. 


nsr-synchronization-detail—Trace NSR synchronization events in detail. 


e state—Trace all LSP state transitions. 


e static—Trace static label-switched path. 


When you configure trace options to track an MPLS LSP using the cspf option, the CSPF log displays 
information about the MPLS LSP using the term “generalized MPLS” (GMPLS). For example, a message in 
the CSPF log might state that the “link passes GMPLS constraints”. Generalized MPLS (GMPLS) is a superset 
of MPLS, so this message is normal and does not affect proper MPLS LSP operation. 
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Release History Table 


Release Description 


16.1 Starting with Junos OS Release 16.1, MPLS-TP supports two additional channel types for 
the default LSPING (OxO0008) channel type under the mpls-tp-mode statement. 


RELATED DOCUMENTATION 


Basic MPLS Configuration | 37 
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CHAPTER 14 


MPLS Pseudowires 


IN THIS CHAPTER 


@ MPLS Pseudowires Configuration | 1151 


| MPLS Pseudowires Configuration 


IN THIS SECTION 


Ethernet Pseudowire Overview | 1151 

Example: Ethernet Pseudowire Base Configuration | 1152 
Pseudowire Overview for ACX Series Universal Metro Routers | 1156 
Understanding Multisegment Pseudowire for FEC 129 | 1157 
Example: Configuring a Multisegment Pseudowire | 1162 

MPLS Stitching For Virtual Machine Connection | 1208 

TDM Pseudowires Overview | 1210 

Example: TDM Pseudowire Base Configuration | 1211 

Configuring Load Balancing for Ethernet Pseudowires | 1215 


Configuring Load Balancing Based on MAC Addresses | 1217 


Ethernet Pseudowire Overview 


Starting in Junos OS Release 14.1X53 and Junos OS Release 16.1, an Ethernet pseudowire is used to carry 
Ethernet or 802.3 Protocol Data Units (PDUs) over an MPLS network enabling service providers to offer 
emulated Ethernet services over existing MPLS networks. Ethernet or 802.3 PDUs are encapsulated within 
the pseudowire to provide a point-to-point Ethernet service. For the point-to-point Ethernet service, the 
following fault management features are supported: 


The IEEE 802.3ah standard for Operation, Administration, and Management (OAM). You can configure 
IEEE 802.3ah OAM link-fault management on Ethernet point-to-point direct links or links across Ethernet 
repeaters. 


Ethernet OAM link-fault management can be used for physical link-level fault detection and management. 
It uses a new, optional sublayer in the data link layer of the OSI model. Ethernet OAM can be implemented 
on any full-duplex point-to-point or emulated point-to-point Ethernet link. A system-wide implementation 
is not required; OAM can be deployed on particular interfaces of a router. Transmitted Ethernet OAM 
messages or OAM PDUs are of standard length, untagged Ethernet frames within the normal frame 
length limits in the range 64-1518 bytes. 


Ethernet connectivity fault management (CFM) to monitor the physical link between two routers. 


e Connection protection using the continuity check protocol for fault monitoring . The continuity check 
protocol is a neighbor discovery and health check protocol that discovers and maintains adjacencies 
at the VLAN or link level. 


e Path protection using the linktrace protocol for path discovery and fault verification . Similar to IP 
traceroute, the linktrace protocol maps the path taken to a destination MAC address through one or 
more bridged networks between the source and destination. 


Example: Ethernet Pseudowire Base Configuration 


IN THIS SECTION 


@ Requirements | 1152 
@ = Overview of an Ethernet Pseudowire Base Configuration | 1152 


@® Configuring an Ethernet Pseudowire | 1153 


Requirements 


The following is a list of the hardware and software requirements for this configuration. 


One ACX Series router 


Junos OS Release 12.2 or later 


Overview of an Ethernet Pseudowire Base Configuration 


The configuration shown here is the base configuration of an Ethernet pseudowire with Ethernet 


cross-connect for physical interface encapsulation on an ACX Series router. This configuration is for one 


provider edge router. To complete the configuration of an Ethernet pseudowire, you need to repeat this 


configuration on an other provider edge router in the Multiprotocol Label Switched (MPLS) network. 
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Configuring an Ethernet Pseudowire 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them in a text file, remove any 


line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level: 





0/1/1 encapsulation ethernet-ccc 
O/i/il wiki © 








O72 Oetinea Ome family enicimacelecsismc On larniun2y 24 





set interfaces g 
set interfaces g 
set interfaces g 
set interfaces g 


set interfaces 


0/2/0 unit O family mpls 
Iho Winstic O) staimbilyy atinetc eiclleess Oo. 1/ 32 


set protocols rsvp interface ge-0/2/0.0 


See PO BObOCe. 
See PEOEOCOL 
ISIE. [OEE @Iew dE 
See PLOEOCOL 
De EO LOLOCen 
SCE VP EOLOCe. 
SCE MP LROLOCOL 


See PBOLOCe. 











See PLOUEOCOL 


Ss 


Ss 


s 


MP ESeeMO = Cs p= 


mpls label-switched-path PE1-to-PE2 to 40.1.1.1 














mpls interface ge-0/2/0.0 

ospf traffic-engineering 

ospf area 0.0.0.0 interface ge-0/2/0.0 
ospf area 0.0.0.0 interface 100.0 passive 
ldp interface ge-0/2/0.0 

ldp interface 100.0 


l12circuit neighbor 40.1.1.1 interface ge-0/1/1.0 virtual-circuit—id 


NOTE: To configure an Ethernet pseudowire with 802.1Q tagging for cross-connect logical 


interface encapsulation, include the vlan-ccc statement at the [edit interfaces ge-0/1/1 unit O 


encapsulation] hierarchy level instead of the ethernet-ccc statement shown in this example. 


Step-by-Step Procedure 


1. Create two Gigabit Ethernet interfaces, set the encapsulation mode on one interface and MPLS on the 


other interface. Create the loopback (loO) interface: 


[edit] 


user@host# edit interfaces 


[edit interfaces] 


user@host# set ge-0/1/1 encapsulation ethernet-ccc 
user@host# set ge-0/1/1 unit 0 

user@host# set ge-0/2/0 unit 0 family inet address 20.1.1.2/24 
user@host# set ge-0/2/0 unit O family mpls 

user@host# set loO unit 0 family inet address 70.1.1.1/32 
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2. Enable the MPLS and RSVP protocols on the interface configured with MPLS—ge-0/2/0.0: 


[edit] 

user@host# edit protocols 

[edit protocols] 

user@host# set rsvp interface ge-0/2/0.0 
user@host# set mpls interface ge-0/2/0.0 


3. Configure LDP. If you configure RSVP for a pseudowire, you must also configure LDP: 


[edit protocols] 
user@host# set protocols Idp interface ge-0/2/0.0 
user@host# set protocols Idp interface lo0.0 


4. Configure a point-to-point label-switched path (LSP) and disable constrained-path LSP computation: 


[edit protocols] 
user@host# set mpls label-switched-path PE1-to-PE2 to 40.1.1.1 
user@host# set mpls no-cspf 


5. Configure OSPF and enable traffic engineering on the MPLS interface—ge-0/2/0.0, and on the loopback 
(loO) interface: 


[edit protocols] 

user@host# set ospf traffic-engineering 

user@host# set ospf area 0.0.0.0 interface ge-0/2/0.0 
user@host# set ospf area 0.0.0.0 interface lo0.0 passive 


6. Uniquely identify a Layer 2 circuit for the Ethernet pseudowire: 


[edit protocols] 
user@host# set I2circuit neighbor 40.1.1.1 interface ge-0/1/1.0 virtual-circuit-id 1 


Results 


[edit] 
user@host# show 


interfaces { 
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ge-0/1/1 { 
encapsulation ethernet-—ccc; 
winasie Wp 
} 
ge-0/2/0 { 
wiawic © 4 
family inet { 
address 20.1.1.2/24; 
} 
family mpls; 


} 
leo) 4 
pine OW ff 
family inet { 
address WO. do. il/3z2e 


} 
BORO ColSma 
Eso 4 
interface ge-0/2/0.0; 
} 
mpls { 


MOme So 





label-switched-path PE1-to-PE2 { 
cO “O0,1,1, 1° 











} 
interface ge-0/2/0.0; 
} 
oy-johmun| 
traffic-—engineering; 
area O.0 ,0.0 4 
interface ge-0/2/0.0; 
interface 100.0 { 


passive; 


ldp { 
interface ge-0/2/0.0; 


interface 100.0; 


I2eaLmewiic 4 
neighbor 40.1.1.1 { 
interface ge-0/1/1.0 { 


WALiccwal—cawemlie—iacl ils 


Pseudowire Overview for ACX Series Universal Metro Routers 


A pseudowire is a Layer 2 circuit or service, which emulates the essential attributes of a telecommunications 
service— such as a 11 line, over an MPLS packet-switched network. The pseudowire is intended to provide 
only the minimum necessary functionality to emulate the wire with the required degree of faithfulness for 
the given service definition. On the ACX Series routers, Ethernet, Asynchronous Transfer Mode (ATM), 
and time-division multiplexing (TDM) pseudowires are supported. The following pseudowire features are 
supported: 


e Pseudowire transport service carrying Layer 1 and Layer 2 information over an IP and MPLS network 
infrastructure. Only similar end points are supported on the ACX Series—for example, T1 to T1, ATM 
to ATM, and Ethernet to Ethernet. 


e Redundant pseudowires backup connections between PE routers and CE devices, maintaining Layer 2 
circuits and services after certain types of failures. Pseudowire redundancy improves the reliability of 
certain types of networks (metro for example) where a single point of failure could interrupt service for 
multiple customers. The following pseudowire redundancy features are supported: 


e Maintenance of Layer 2 circuit services after certain types of failures with a standby pseudowire, 
which backs up the connection between PE routers and CE devices. 


e Incase of failure, a protect interface, which backs up the primary interface. Network traffic uses the 
primary interface only so long as the primary interface functions. If the primary interface fails, traffic 
is switched to the protect interface. 


e Hot and cold standby enabling swift cut over to the backup or standby pseudowire. 


Ethernet connectivity fault management (CFM), which can be used to monitor the physical link between 


two routers. The following major features of CFM for Ethernet pseudowires only are supported: 


e Connection protection using the continuity check protocol for fault monitoring. The continuity check 
protocol is a neighbor discovery and health check protocol that discovers and maintains adjacencies 
at the VLAN or link level. 
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e Path protection using the linktrace protocol for path discovery and fault verification. Similar to IP 
traceroute, the linktrace protocol maps the path taken to a destination MAC address through one or 
more bridged networks between the source and destination. 


Understanding Multisegment Pseudowire for FEC 129 
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Understanding Multisegment Pseudowire 


A pseudowire is a Layer 2 circuit or service that emulates the essential attributes of a telecommunications 
service, such as a T1 line, over an MPLS packet-switched network (PSN). The pseudowire is intended to 
provide only the minimum necessary functionality to emulate the wire with the required resiliency 
requirements for the given service definition. 


When a pseudowire originates and terminates on the edge of the same PSN, the pseudowire label is 
unchanged between the originating and terminating provider edge (T-PE) devices. This is called a 
single-segment pseudowire (SS-PW). Figure 94 on page 1158 illustrates an SS-PW established between two 
PE routers. The pseudowires between the PE1 and PE2 routers are located within the same autonomous 
system (AS). 


Figure 94: LZ2VPN Pseudowire 
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In cases where it is impossible to establish a single pseudowire from a local to a remote PE, either because 
it is unfeasible or undesirable to establish a single control plane between the two PEs, a multisegment 
pseudowire (MS-PW) is used. 


An MS-PW is a set of two or more contiguous SS-PWs that are made to function as a single point-to-point 
pseudowire. It is also known as switched pseudowire. MS-PWs can go across different regions or network 
domains. A region can be considered as an interior gateway protocol (IGP) area or a BGP autonomous 
system that belongs to the same or different administrative domain. An MS-PW spans multiple cores or 
ASs of the same or different carrier networks. A Layer 2 VPN MS-PW can include up to 254 pseudowire 
segments. 


Figure 95 on page 1159 illustrates a set of two or more pseudowire segments that function as a single 
pseudowire. The end routers are called terminating PE (T-PE) routers, and the switching routers are called 
switching PE (S-PE) routers. The S-PE router terminates the tunnels of the preceding and succeeding 
pseudowire segments in an MS-PW. The S-PE router can switch the control and data planes of the preceding 
and succeeding pseudowire segments of the MS-PW. An MS-PW is declared to be up when all the 
single-segment pseudowires are up. 
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Figure 95: Multisegment Pseudowire 


Pseudowire Pseudowire Pseudowire 
segment segment segment 


CEl 


CEI 
a S-PEI S-PE2 ree) ge 


CE2 CE2 


g041634 


Using FEC 129 for Multisegment Pseudowire 

Currently, there are two types of attachment circuit identifiers (Alls) defined under FEC 129: 
e Type 1 All 

e Type 2 All 


The support of an MS-PW for FEC 129 uses type 2 All. A type 2 All is globally unique by definition of RFC 
5003. 


Single-segment pseudowires (SS-PWs) using FEC 129 on an MPLS PSN can use both type 1 and type 2 
All. For an MS-PW using FEC 129, a pseudowire itself is identified as a pair of endpoints. This requires 
that the pseudowire endpoints be uniquely identified. 


In the case of a dynamically placed MS-PW, there is a requirement for the identifiers of attachment circuits 
to be globally unique, for the purposes of reachability and manageability of the pseudowire. Thus, individual 
globally unique addresses are allocated to all the attachment circuits and S-PEs that make up an MS-PW. 


Type 2 All is composed of three fields: 


e Global_ID—Global identification, which is usually the AS number. 
e Prefix—IPv4 address, which is usually the router ID. 


e AC_ID—Local attachment circuit, which is a user-configurable value. 


Since type 2 All already contains the T-PE's IP address and it is globally unique, from the FEC 129 
pseudowire signaling point of view, the combination (AGI, SAII, TAII) uniquely identifies an MS-PW across 
all interconnected pseudowire domains. 


Establishing a Multisegment Pseudowire Overview 


An MS-PW is established by dynamically and automatically selecting the predefined S-PEs and placing the 
MS-PW between two T-PE devices. 


When S-PEs are dynamically selected, each S-PE is automatically discovered and selected using the BGP 
autodiscovery feature, without the requirement of provisioning the FEC 129 pseudowire-related information 
on all the S-PEs. BGP is used to propagate pseudowire address information throughout the PSN. 


Since there is no manual provisioning of FEC 129 pseudowire information on the S-PEs, the Attachment 
Group Identifier (AGI) and Attachment Individual Identifier (All) are reused automatically, and choosing 
the same set of S-PEs for the pseudowire in both the forwarding and reverse direction is achieved through 
the active and passive role of each T-PE device. 


e Active—The T-PE initiates an LDP label mapping message. 


e Passive—The T-PE does not initiate an LDP label mapping message until it receives a label mapping 
message initiated by the active T-PE. The passive T-PE sends its label mapping message to the same 
S-PE from where it received the label mapping message originated from its active T-PE. This ensures 
that the same set of S-PEs are used in the reverse direction. 


Pseudowire Status Support for Multisegment Pseudowire 
Pseudowire Status Behavior on T-PE 


The following pseudowire status messages are relevant on the T-PE: 


e 0x00000010—Local PSN-facing pseudowire (egress) transmit fault. 


e 0x00000001—Generic nonforwarding fault code. This is set as the local fault code. The local fault code 
is set at the local T-PE, and LDP sends a pseudowire status TLV message with the same fault code to 
the remote T-PE. 


e Fault codes are bit-wise OR’ed and stored as remote pseudowire status codes. 


Pseudowire Status Behavior on S-PE 
The S-PE initiates the pseudowire status messages that indicate the pseudowire faults. The SP-PE in the 


pseudowire notification message hints where the fault was originated. 


e When a local fault is detected by the S-PE, a pseudowire status message is sent in both directions along 
the pseudowire. Since there are no attachment circuits on an S-PE, only the following status messages 
are relevant: 


e 0x00000008—Local PSN-facing pseudowire (ingress) receive fault. 


e 0x00000010—Local PSN-facing pseudowire (egress) transmit fault. 


To indicate which SS-PW is at fault, an LDP SP-PE TLV is attached with the pseudowire status code in 
the LDP notification message. The pseudowire status is passed along from one pseudowire to another 


unchanged by the control plane switching function. 


e If an S-PE initiates a pseudowire status notification message with one particular pseudowire status bit, 
then for the pseudowire status code an S-PE receives, the same bit is processed locally and not forwarded 
until the S-PE's original status error is cleared. 
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e An S-PE keeps only two pseudowire status codes for each SS-PW it is involved in - local pseudowire 
status code and remote pseudowire status code. The value of the remote pseudowire status code is the 
result of logic or operation of the pseudowire status codes in the chain of SS-PWs preceding this segment. 
This status code is incrementally updated by each S-PE upon receipt and communicated to the next 
S-PE. The local pseudowire status is generated locally based on its local pseudowire status. 


e Only transmit fault is detected at the SP-PE. When there is no MPLS LSP to reach the next segment, a 
local transmit fault is detected. The transmit fault is sent to the next downstream segment, and the 
receive fault is sent to the upstream segment. 


Remote failures received on an S-PE are just passed along the MS-PW unchanged. Local failures are 
sent to both segments of the pseudowire that the S-PE is involved in. 


Pseudowire TLV Support for MS-PW 
MS-PW provides the following support for the LDP SP-PE TLV [RFC 6073]: 
e The LDP SP-PE TLVs for an MS-PW include: 

e Local IP address 


e Remote IP address 


e An SP-PE adds the LDP SP-PE TLV to the label mapping message. Each SP-PE appends the local LDP 
SP-PE TLV to the SP-PE list it received from the other segment. 


e The pseudowire status notification message includes the LDP SP-PE TLV when the notification is 


generated at the SP-PE. 


Supported and Unsupported Features 

Junos OS supports the following features with MS-PW: 

e MPLS PSN for each SS-PW that builds up the MS-PW. 

e The same pseudowire encapsulation for each SS-PW in an MS-PW - Ethernet or VLAN-CCC. 


e The generalized PWid FEC with T-LDP as an end-to-end pseudowire signaling protocol to set up each 
SS-PW. 


e MP-BGP to autodiscover the two endpoint PEs for each SS-PW associated with the MS-PW. 
e Standard MPLS operation to stitch two side-by-side SS-PWs to form an MS-PW. 

e Automatic discovery of S-PE so that the MS-PW can be dynamically placed. 

e Minimum provisioning of S-PE. 


e Operation, administration, and maintenance (OAM) mechanisms, including end-to-end MPLS ping or 
end-to-any-S-PE MPLS ping, MPLS path trace, end-to-end VCCV, and Bidirectional Forwarding Detection 
(BFD). 


e Pseudowire swithing point (SP) PE TLV for the MS-PW. 


e Composite next hop on MS-PW. 
e Pseudowire status TLV for MS-PW. 


Junos OS does not support the following MS-PW functionality: 


e Mix of LDP FEC 128 and LDP FEC 129. 

e Static pseudowire where each label is provisioned staticially. 
e Graceful Routing Engine switchover. 

e Nonstop active routing. 

e Multihoming. 


e Partial connectivity verification (originating from an S-PE) in OAM. 


Example: Configuring a Multisegment Pseudowire 


IN THIS SECTION 


Requirements | 1162 
Overview | 1163 
Configuration | 1169 
Verification | 1195 


Troubleshooting | 1206 


This example shows how to configure a dynamic multisegment pseudowire (MS-PW), where the stitching 
provider edge (S-PE) devices are automatically and dynamically discovered by BGP, and pseudowires are 
signaled by LDP using FEC 129. This arrangement requires minimum provisioning on the S-PEs, thereby 
reducing the configuration burden that is associated with statically configured Layer 2 circuits while still 
using LDP as the underlying signaling protocol. 


Requirements 


This example uses the following hardware and software components: 


e Six routers that can be a combination of M Series Multiservice Edge Routers, MX Series 5G Universal 
Routing Platforms, T Series Core Routers, or PTX Series Packet Transport Routers. 


e Two remote PE devices configured as terminating PEs (T-PEs). 
e Two S-PEs configured as: 


e Route reflectors, in the case of interarea configuration. 
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e AS boundary routers or route reflectors, in the case of inter-AS configuration. 


e Junos OS Release 13.3 or later running on all the devices. 
Before you begin: 


1. Configure the device interfaces. 
. Configure OSPF or any other IGP protocol. 
. Configure BGP. 


2 
3 
4. Configure LDP. 
5 


. Configure MPLS. 


Overview 


Starting with Junos OS Release 13.3, you can configure an MS-PW using FEC 129 with LDP signaling and 
BGP autodiscovery in an MPLS packet-switched network (PSN). The MS-PW feature also provides operation, 
administration, and management (OAM) capabilities, such as ping, traceroute, and BFD, from the T-PE 
devices. 


To enable autodiscovery of S-PEs in an MS-PW, include the auto-discovery-mspw statement at the [edit 
protocols bgp group group-name family I2vpn] hierarchy level. 


family I2vpn { 
auto-discovery-mspw; 


} 


The automatic selection of S-PE and dynamic setting up of an MS-PW rely heavily on BGP. BGP network 
layer reachability information (NLRI) constructed for the FEC 129 pseudowire to autodiscover the S-PE 
is called an MS-PW NLRI [draft-ietf-pwe3-dynamic-ms-pw-15.txt]. The MS-PW NLRI is essentially a prefix 
consisting of a route distinguisher (RD) and FEC 129 source attachment identifier (SAII). It is referred to 
as a BGP autodiscovery (BGP-AD) route and is encoded as RD:SAII. 


Only T-PEs that are provisioned with type 2 Alls initiate their own MS-PW NLRI respectively. Since a type 
2 Allis globally unique, an MS-PW NLRI is used to identify a PE device to which the type 2 All is provisioned. 
The difference between a type 1 All and a type 2 All requires that a new address family indicator (AFI) 
and subsequent address family identifier (SAFI) be defined in BGP to support an MS-PW. The proposed 
AFI and SAFI value pair used to identify the MS-PW NLRI is 25 and 6, respectively (pending IANA allocation). 


The AFI and SAFI values support autodiscovery of S-PEs and should be configured on both T-PEs that 
originate the routes, and the S-PEs that participate in the signaling. 


Figure 96 on page 1164 illustrates an inter-area MS-PW setup between two remote PE routers—T-PE1 and 
T-PE2. The Provider (P) routers are P1 and P2, and the S-PE routers are S-PE1 and S-PE2. The MS-PW is 
established between T-PE1 and T-PE2, and all the devices belong to the same AS—AS 100. Since S-PE1 
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and S-PE2 belong to the same AS, they act as route reflectors and are also known as RR 1 and RR 2, 


respectively. 


Figure 97 on page 1164 illustrates an inter-AS MS-PW setup. The MS-PW is established between T-PE1 and 
T-PE2, where T-PE1, P1, and S-PE1 belong to AS 1, and S-PE2, P2, and T-PE2 belong to AS 2. Since S-PE1 
and S-PE2 belong to different ASs, they are configured as ASBR routers and are also known as ASBR 1 


and ASBR 2, respectively. 


Figure 96: Interarea Multisegment Pseudowire 
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Figure 97: Inter-AS Multisegment Pseudowire 
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The following sections provide information about how an MS-PW is established in an interarea and inter-AS 
scenario. 


Minimum Configuration Requirements on S-PE 


In order to dynamically discover both ends of an SS-PW and set up a T-LDP session dynamically, the 
following is required: 


For interarea MS-PW, each S-PE plays both an ABR and BGP route reflector role. 


In the interarea case, as seen in Figure 96 on page 1164, the S-PE plays a BGP route reflector role and 
reflects the BGP-AD route to its client. A BGP-AD route advertised by one T-PE eventually reaches its 
remote T-PE. Because of the next-hop-self set by each S-PE, the S-PE or T-PE that receives a BGP-AD 
route can always discover the S-PE that advertises the BGP-AD in its local AS or local area through the 
BGP next hop. 


For inter-AS MS-PW, each S-PE plays either an ASBR or a BGP route reflector role. 


In an MS-PW, the two T-PEs initiate a BGP-AD route respectively. When the S-PE receives the BGP-AD 
route through either the IBGP session with the T-PE or through a regular BGP-RR, it sets the next-hop-self 
before re-advertising the BGP-AD route to one or more of its EBGP peers in the inter-AS case, as seen 
in Figure 97 on page 1164. 


e Each S-PE must set next-hop-self when re-advertising or reflecting a BGP-AD route for the MS-PW. 


Active and Passive Role of T-PE 


To ensure that the same set of S-PEs are being used for a MS-PW in both directions, the two T-PEs play 
different roles in terms of FEC 129 signaling. This is to avoid different paths being chosen by T-PE1 and 
T-PE2 when each S-PE is dynamically selected for an MS-PW. 


When an MS-PW is signaled using FEC 129, each T-PE might independently start signaling the MS-PW. 
The signaling procedure can result in an attempt to set up each direction of the MS-PW through different 
S-PEs. 


To avoid this situation, one of the T-PEs must start the pseudowire signaling (active role), while the other 
waits to receive the LDP label mapping before sending the respective pseudowire LDP label mapping 
message (passive role). When the MS-PW path is dynamically placed, the active T-PE (the Source T-PE) 
and the passive T-PE (the Target T-PE) must be identified before signaling is initiated for a given MS-PW. 
The determination of which T-PE assumes the active role is done based on the SAIl value, where the T-PE 
that has a larger SAII value plays the active role. 


In this example, the SAII values of T-PE1 and T-PE 2 are 800:800:800 and 700:700:700, respectively. 
Since T-PE1 has a higher SAII value, it assumes the active role and T-PE2 assumes the passive role. 


Directions for Establishing an MS-PW 
The directions used by the S-PE for setting up the MS-PW are: 


e Forwarding direction—From an active T-PE to a passive T-PE. 


In this direction, the S-PEs perform a BGP-AD route lookup to determine the next-hop S-PE to send the 
label mapping message. 


e Reverse direction—From a passive T-PE to an active T-PE. 


In this direction, the S-PEs do not perform a BGP-AD route lookup, because the label mapping messages 
are received from the T-PEs, and the stitching routes are installed in the S-PEs. 


In this example, the MS-PW is established in the forwarding direction from T-PE1 to T-PE2. When the 
MS-PW is placed from T-PE2 to T-PE1, the MS-PW is established in the reverse direction. 


Autodiscovery and Dynamic Selection of S-PE 


A new AFI and SAFI value is defined in BGP to support the MS-PWs based on type 2 All. This new address 
family supports autodiscovery of S-PEs. This address family must be configured on both the TPEs and 
SPEs. 


It is the responsibility of the Layer 2 VPN component to dynamically select the next S-PE to use along the 
MS-PW in the forwarding direction. 


e In the forwarding direction, the selection of the next S-PE is based on the BGP-AD route advertised by 
the BGP and pseudowire FEC information sent by the LDP. The BGP-AD route is initiated by the passive 
T-PE (T-PE2) in the reverse direction while the pseudowire FEC information is sent by LDP from the 
active T-PE (T-PE1) in the forwarding direction. 


e Inthe reverse direction, the next S-PE (S-PE2) or the active T-PE (T-PE1) is obtained by looking up the 
S-PE (S-PE1) that it used to set up the pseudowire in the forwarding direction. 


Provisioning a T-PE 


To support FEC 129 type 2 All, the T-PE needs to configure its remote T-PE's IP address, a global ID, and 
an attachment circuit ID. Explicit paths where a set of S-PEs to use is explicitly specified on a T-PE is not 
supported. This eliminates the need to provision each S-PE with a type 2 All. 


Stitching an MS-PW 


An S-PE performs the following MPLS label operations before forwarding the received label mapping 
message to the next S-PE: 


1. Pops the MPLS tunnel label. 


2. Pops the VC label. 


3. Pushes a new VC label. 


4. Pushes an MPLS tunnel label used for the next segment. 


Establishing an MS-PW 
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After completing the necessary configuration, an MS-PW is established in the following manner: 


1. 


The SAII values are exchanged between T-PE1 and T-PE2 using BGP. 


T-PE1 assumes the active T-PE role, because it is configured with a higher SAII value. T-PE2 becomes 
the passive T-PE. 


. T-PE1 receives the BGP-AD route originated by T-PE2. It compares the All values obtained from T-PE2 


in the received BGP-AD route against the All values provisioned locally. 


. If the All values match, T-PE1 performs a BGP-AD route lookup to elect the first S-PE (S-PE1). 


. T-PE1 sends an LDP label mapping message to S-PE1. 


. Using the BGP-AD route originated from T-PE2, and the LDP label mapping message received from 


T-PE1, S-PE1 selects the next S-PE (S-PE2) in the forwarding direction. 


To do this, S-PE1 compares SAII obtained from the BGP-AD route against the TAI from the LDP label 
mapping message. 


. If the All values match, S-PE1 finds S-PE2 through the BGP next hop associated with the BGP-AD 


route. 


. The process of selecting S-PE goes on until the last S-PE establishes a T-LDP session with T-PE2. When 


T-PE2 receives the LDP label mapping message from the last S-PE (S-PE2), it initiates its own label 
mapping message and sends it back to S-PE2. 


. When all the label mapping messages are received on S-PE1 and S-PE2, the S-PEs install the stitching 


routes. Thus, when the MS-PW is established in the reverse direction, the S-PEs need not perform 
BGP-AD route lookup to determine its next hop as it did in the forwarding direction. 


OAM Support for an MS-PW 


After the MS-PW is established, the following OAM capabilities can be executed from the T-PE devices: 


e Ping 


e End-to-End Connectivity Verification Between T-PEs 


If T-PE1, S-PEs, and T-PE2 support Control Word (CW), the pseudowire control plane automatically 
negotiates the use of the CW. Virtual Circuit Connectivity Verification (VCCV) Control Channel (CC) 
Type 3 will function correctly whether or not the CW is enabled on the pseudowire. However, VCCV 
Type 1, which is used for end-to-end verification only, is only supported if the CW is enabled. 


The following is a sample: 


user@T- 
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PE1> ping mplsI2vpn fec129 instance instance-name local-id SAII of T-PE1 remote-pe-address 





address of T-PE2 remote-id TAII of T-PE2 


or 





user@T-PE1> ping mpls I2vpn fec129 interface CE1-facing interface 


Partial Connectivity Verification from T-PE to Any S-PE 


To trace part of an MS-PW, the TTL of the pseudowire label can be used to force the VCCV message 


to pop out at an intermediate node. When the TTL expires, the S-PE can determine that the packet is 
a VCCV packet either by checking the CW or by checking for a valid IP header with UDP destination 
port 3502 (if the CW is not in use). The packet should then be diverted to VCCV processing. 


If T-PE1 sends a VCCV message with the TTL of the pseudowire label equal to 1, the TTL expires at 


the S-PE. 


T-PE1 can thus verify the first segment of the pseudowire. 


The VCCV packet is built according to RFC 4379. All the information necessary to build the VCCV 


LSP ping 


packet is collected by inspecting the S-PE TLVs. This use of the TTL is subject to the caution 


expressed in RFC 5085. If a penultimate LSR between S-PEs or between an S-PE and a T-PE manipulates 
the pseudowire label TTL, the VCCV message might not emerge from the MS-PW at the correct S-PE. 


The following is a sample: 


user@T-PE1> ping mpls I2vpn fec129 interface CE1-facing interface bottom-label-ttl segment 
The bottom-label-ttl value is 1 for S-PE1 and 2 for S-PE2. 





The bottom-label-ttl statement sets the correct VC label TTL, so the packets are popped to the correct 
SS-PW for VCCV processing. 


NOT 
Type 


e Traceroute 


Traceroute 


E: Junos OS supports VCCV Type 1 and Type 3 for the MS-PW OAM capability. VCCV 
2 is not supported. 


tests each S-PE along the path of the MS-PW ina single operation similar to LSP trace. This 


operation is able to determine the actual data path of the MS-PW, and is used for dynamically signaled 


MS-PWs. 


user@T-P 





E1> traceroute mpls I2vpn fec129 interface CE1-facing interface 


e Bidirectional Forwarding Detection 


Bidirectional Forwarding Detection (BFD) is a detection protocol designed to provide fast forwarding 


path failure detection times for all media types, encapsulations, topologies, and routing protocols. In 


addition to 


fast forwarding path failure detection, BFD provides a consistent failure detection method 


for network administrators. The router or switch can be configured to log a system log (syslog) message 
when BFD goes down. 


user@T-PE1> show bfd session extensive 
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Configuring an Interarea MS-PW 


CLI Quick Configuration 

To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


T-PE1 


set interfaces ge-3/1/0 unit 0 family inet address 192.0.2.1/24 
set interfaces ge-3/1/0 unit 0 family mpls 

set interfaces ge-3/1/2 encapsulation ethernet-ccc 

set interfaces ge-3/1/2 unit 0 

set interfaces loO unit O family inet address 10.255.10.1/32 primary 
set routing-options autonomous-system 100 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp family I2vpn auto-discovery-mspw 

set protocols bgp group mspw type internal 

set protocols bgp group mspw local-address 10.255.10.1 

set protocols bgp group mspw neighbor 10.255.2.1 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set protocols Idp interface lo0.0 
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set routing-instances ms-pw instance-type I2vpn 

set routing-instances ms-pw interface ge-3/1/2.0 

set routing-instances ms-pw route-distinguisher 10.10.10.10:15 

set routing-instances ms-pw I2vpn-id I2vpn-id:100:15 

set routing-instances ms-pw vrf-target target:100:115 

set routing-instances ms-pw protocols I2vpn site CE1 source-attachment-identifier 800:800:800 

set routing-instances ms-pw protocols I2vpn site CE1 interface ge-3/1/2.0 target-attachment-identifier 
700:700:700 

set routing-instances ms-pw protocols I2vpn pseudowire-status-tlv 

set routing-instances ms-pw protocols I2vpn oam bfd-liveness-detection minimum-interval 300 


P1 


set interfaces ge-2/0/0 unit 0 family inet address 192.0.2.2/24 
set interfaces ge-2/0/0 unit 0 family mpls 

set interfaces ge-2/0/2 unit 0 family inet address 192.0.2.13/24 
set interfaces ge-2/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.13.1/32 primary 
set routing-options autonomous-system 100 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set protocols Idp interface lo0.0 


S-PE1 (RR 1) 


set interfaces ge-1/3/1 unit 0 family inet address 192.0.2.9/24 
set interfaces ge-1/3/1 unit 0 family mpls 

set interfaces ge-1/3/2 unit 0 family inet address 192.0.2.22/24 
set interfaces ge-1/3/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.2.1/32 primary 
set routing-options autonomous-system 100 

set protocols mpls interface all 
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set protocols mpls interface fxp0.0 disable 

set protocols bgp family I2vpn auto-discovery-mspw 

set protocols bgp group mspw type internal 

set protocols bgp group mspw local-address 10.255.2.1 

set protocols bgp group mspw export next-hop-self 

set protocols bgp group mspw cluster 203.0.113.0 

set protocols bgp group mspw neighbor 10.255.10.1 

set protocols bgp group mspw neighbor 10.255.3.1 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set protocols Idp interface lo0.0 

set policy-options policy-statement next-hop-self then next-hop self 
set policy-options policy-statement send-inetO from protocol bgp 
set policy-options policy-statement send-inetO then accept 


S-PE2 (RR 2) 


set interfaces ge-0/3/1 unit 0 family inet address 192.0.2.10/24 
set interfaces ge-0/3/1 unit 0 family mpls 

set interfaces ge-0/3/2 unit 0 family inet address 192.0.2.14/24 
set interfaces ge-0/3/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.3.1/32 primary 
set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp family I2vpn auto-discovery-mspw 

set protocols bgp group mspw type internal 

set protocols bgp group mspw local-address 10.255.3.1 

set protocols bgp group mspw export next-hop-self 

set protocols bgp group mspw cluster 198.51.100.0 

set protocols bgp group mspw neighbor 10.255.2.1 

set protocols bgp group mspw neighbor 10.255.14.1 

set protocols bgp group int type internal 

set protocols bgp group int local-address 10.255.3.1 

set protocols bgp group int neighbor 10.255.2.1 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


P2 


T-PE2 


set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set protocols Idp interface lo0.0 

set policy-options policy-statement next-hop-self then next-hop self 
set policy-options policy-statement send-inetO from protocol bgp 
set policy-options policy-statement send-inetO then accept 


set interfaces ge-1/3/1 unit 0 family inet address 192.0.2.5/24 
set interfaces ge-1/3/1 unit 0 family mpls 

set interfaces ge-1/3/2 unit 0 family inet address 192.0.2.4/24 
set interfaces ge-1/3/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.4.1/32 primary 
set routing-options autonomous-system 100 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set protocols Idp interface lo0.0 


set interfaces ge-2/0/0 encapsulation ethernet-ccc 

set interfaces ge-2/0/0 unit 0 

set interfaces ge-2/0/2 unit 0 family inet address 192.0.2.15/24 
set interfaces ge-2/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.14.1/32 primary 
set routing-options autonomous-system 100 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp family I2vpn auto-discovery-mspw 

set protocols bgp group mspw type internal 

set protocols bgp group mspw local-address 10.255.14.1 
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set protocols bgp group mspw neighbor 10.255.3.1 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set protocols Idp interface lo0.0 

set routing-instances ms-pw instance-type I2vpn 

set routing-instances ms-pw interface ge-2/0/0.0 

set routing-instances ms-pw route-distinguisher 10.10.10.10:15 

set routing-instances ms-pw I2vpn-id I2vpn-id:100:15 

set routing-instances ms-pw vrf-target target:100:115 

set routing-instances ms-pw protocols I2vpn site CE2 source-attachment-identifier 700:700:700 

set routing-instances ms-pw protocols I2vpn site CE2 interface ge-2/0/0.0 target-attachment-identifier 
800:800:800 

set routing-instances ms-pw protocols I2vpn pseudowire-status-tlv 

set routing-instances ms-pw protocols I2vpn oam bfd-liveness-detection minimum-interval 300 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode. 


To configure T-PE11 in the interarea scenario: 


NOTE: Repeat this procedure for the T-PE2 device in the MPLS domain, after modifying the 
appropriate interface names, addresses, and other parameters. 


1. Configure the T-PE1 interfaces. 


[edit interfaces] 

user@T-PE1# set ge-3/1/0 unit 0 family inet address 192.0.2.1/24 
user@T-PE1# set ge-3/1/0 unit 0 family mpls 

user@T-PE1# set ge-3/1/2 encapsulation ethernet-ccc 

user@T-PE1# set ge-3/1/2 unit 0 

user@T-PE1# set loO unit O family inet address 10.255.10.1/32 primary 


2. Set the autonomous system number. 
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[edit routing-options] 
user@T-PE1# set autonomous-system 100 


3. Enable MPLS on all the interfaces of T-PE1, excluding the management interface. 


[edit protocols] 
user@T-PE1# set mpls interface all 
user@T-PE1# set mpls interface fxp0.0 disable 


4. Enable autodiscovery of intermediate S-PEs that make up the MS-PW using BGP. 


[edit protocols] 
user@T-PE1# set bgp family I2vpn auto-discovery-mspw 


5. Configure the BGP group for T-PE1. 


[edit protocols] 
user@T-PE1# set bgp group mspw type internal 


6. Assign local and neighbor addresses to the mspw group for T-PE1 to peer with S-PE1. 


[edit protocols] 
user@T-PE1# set bgp group mspw local-address 10.255.10.1 
user@T-PE1# set bgp group mspw neighbor 10.255.2.1 


7. Configure OSPF on all the interfaces of T-PE1, excluding the management interface. 


[edit protocols] 

user@T-PE1# set ospf area 0.0.0.0 interface lo0.0 
user@T-PE1# set ospf area 0.0.0.0 interface all 
user@T-PE1# set ospf area 0.0.0.0 interface fxp0.0 disable 


8. Configure LDP on all the interfaces of T-PE1, excluding the management interface. 


[edit protocols] 

user@T-PE1# set Idp interface all 
user@T-PE1# set Idp interface fxp0.0 disable 
user@T-PE1# set Idp interface lo0.0 
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9. Configure the Layer 2 VPN routing instance on T-PE1. 


[edit routing-instances] 
user@T-PE1# set ms-pw instance-type I2vpn 


10. Assign the interface name for the mspw routing instance. 


[edit routing-instances] 
user@T-PE1# set ms-pw interface ge-3/1/2.0 


11. Configure the route distinguisher for the mspw routing instance. 


[edit routing-instances] 
user@T-PE1# set ms-pw route-distinguisher 10.10.10.10:15 


12. Configure the Layer 2 VPN ID community for FEC 129 MS-PW. 


[edit routing-instances] 
user@T-PE1# set ms-pw I2vpn-id I2vpn-id:100:15 


13. Configure a VPN routing and forwarding (VRF) target for the mspw routing instance. 


[edit routing-instances] 
user@T-PE1# set ms-pw vrf-target target:100:115 


14. Configure the source attachment identifier (SAI) value using Layer 2 VPN as the routing protocol for 
the mspw routing instance. 


[edit routing-instances] 
user@T-PE1# set ms-pw protocols I2vpn site CE1 source-attachment-identifier 800:800:800 


15. Assign the interface name that connects the CE1 site to the VPN, and configure the target attachment 
identifier (TAI) value using Layer 2 VPN as the routing protocol for the mspw routing instance. 


[edit routing-instances] 
user@T-PE1# set ms-pw protocols I2vpn site CE1 interface ge-3/1/2.0 target-attachment-identifier 
700:700:700 
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16. (Optional) Configure T-PE1 to send MS-PW status TLVs. 


[edit routing-instances] 
user@T-PE1# set ms-pw protocols I2vpn pseudowire-status-tlv 


17. (Optional) Configure OAM capabilities for the VPN. 


[edit routing-instances] 
user@T-PE1# set ms-pw protocols I2vpn oam bfd-liveness-detection minimum-interval 300 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode. 


To configure S-PE1 (RR 1) in the interarea scenario: 


NOTE: Repeat this procedure for the S-PE2 (RR 2) device in the MPLS domain, after modifying 
the appropriate interface names, addresses, and other parameters. 


1. Configure the S-PE1 interfaces. 


[edit interfaces] 

user@S-PE1# set ge-1/3/1 unit O family inet address 192.0.2.9/24 
user@S-PE1# set ge-1/3/1 unit 0 family mpls 

user@S-PE1# set ge-1/3/2 unit 0 family inet address 192.0.2.22/24 
user@S-PE1# set ge-1/3/2 unit 0 family mpls 

user@S-PE1# set loO unit 0 family inet address 10.255.2.1/32 primary 


2. Set the autonomous system number. 


[edit routing-options] 
user@S-PE1# set autonomous-system 100 


3. Enable MPLS on all the interfaces of T-PE1, excluding the management interface. 


[edit protocols] 
user@S-PE1# set mpls interface all 
user@S-PE1# set mpls interface fxp0.0 disable 


4. Enable autodiscovery of S-PE using BGP. 


[edit protocols] 
user@S-PE1# set bgp family I2vpn auto-discovery-mspw 


5. Configure the BGP group for S-PE1. 


[edit protocols] 
user@S-PE1# set bgp group mspw type internal 


6. Configure S-PE1 to act as a route reflector. 


[edit protocols] 
user@S-PE1# set bgp group mspw export next-hop-self 
user@S-PE1# set bgp group mspw cluster 203.0.113.0 


7. Assign local and neighbor addresses to the mspw group for S-PE1 to peer with T-PE1 and S-PE2. 


[edit protocols] 

user@S-PE1# set bgp group mspw local-address 10.255.2.1 
user@S-PE1# set bgp group mspw neighbor 10.255.10.1 (to T-PE1) 
user@S-PE1# set bgp group mspw neighbor 10.255.3.1 (to S-PE2) 


8. Configure OSPF on all the interfaces of S-PE1, excluding the management interface. 


[edit protocols] 

user@S-PE1# set ospf area 0.0.0.0 interface all 
user@S-PE1# set ospf area 0.0.0.0 interface fxp0.0 disable 
user@S-PE1# set ospf area 0.0.0.0 interface 1o0.0 


9. Configure LDP on all the interfaces of S-PE1, excluding the management interface. 


[edit protocols] 

user@S-PE1# set Idp interface all 
user@S-PE1# set Idp interface fxp0.0 disable 
user@S-PE1# set Idp interface lo0.0 


10. Define the policy for enabling next-hop-self and accepting BGP traffic on S-PE1. 
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[edit policy-options] 

user@S-PE1# set policy-statement next-hop-self then next-hop self 
user@S-PE1# set policy-statement send-inetO from protocol bgp 
user@S-PE1# set policy-statement send-inetO then accept 


Results 

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
show routing-instances, show routing-options, and show policy-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


T-PE1 


user@T-PE1# show interfaces 
ge-3/1/0 { 
unit O { 
family inet { 
address 192.0.2.1/24; 
} 


family mpls; 


} 
ge-3/1/2 { 

encapsulation ethernet-ccc; 

unit O; 
} 
lo0 { 

unit O { 

family inet { 
address 10.255.10.1/32 { 
primary; 


user@T-PE1# show routing-options 
autonomous-system 100; 


user@T-PE1# show protocols 


mpls { 
interface all; 
interface fxp0.0 { 
disable; 


} 
bgp { 
family I2vpn { 
auto-discovery-mspw; 
} 
group mspw { 
type internal; 
local-address 10.255.10.1; 
neighbor 10.255.2.1; 


} 
ospf { 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 
} 


interface 100.0; 


} 
Idp { 
interface all; 
interface fxp0.0 { 
disable; 
} 


interface 100.0; 


user@T-PE1# show routing-instances 
ms-pw { 

instance-type |2vpn; 

interface ge-3/1/2.0; 

route-distinguisher 10.10.10.10:15; 

|2vpn-id I2vpn-id:100:15; 

vrf-target target:100:115; 

protocols { 

I2vpn { 
site CE1 { 
source-attachment-identifier 800:800:800; 
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interface ge-3/1/2.0 { 
target-attachment-identifier 700:700:700; 


} 
pseudowire-status-tlv; 
oam { 
bfd-liveness-detection { 
minimum-interval 300; 


S-PE1 (RR 1) 


user@S-PE1# show interfaces 
ge-1/3/1 { 
unit O { 
family inet { 
address 192.0.2.9/24, 
} 


family mpls; 


} 
ge-1/3/2 { 
unit O { 
family inet { 
address 192.0.2.22/24- 
} 


family mpls; 


} 
loO { 
unit O { 
family inet { 
address 10.255.2.1/32 { 
primary; 
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user@S-PE1# show routing-options 
autonomous-system 100; 


user@S-PE1# show protocols 
mpls { 
interface all; 
interface fxp0.0 { 
disable; 


} 
bgp { 
family I2vpn { 
auto-discovery-mspw; 
} 
group mspw { 
type internal; 
local-address 10.255.2.1; 
export next-hop-self; 
cluster 203.0.113.0; 
neighbor 10.255.10.1; 
neighbor 10.255.3.1; 


} 
ospf { 
area 0.0.0.0 { 
interface 100.0; 
interface all; 
interface fxp0.0 { 
disable; 


} 
Idp { 
interface all; 
interface fxp0.0 { 
disable; 
} 


interface 100.0; 


user@S-PE1# show policy-options 
policy-statement next-hop-self { 
then { 
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next-hop self; 


} 

policy-statement send-inetO { 
from protocol bgp; 
then accept; 


If you are done configuring the device, enter commit from configuration mode. 


Configuring an Inter-AS MS-PW 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


T-PE1 


set interfaces ge-3/1/0 unit 0 family inet address 192.0.2.1/24 
set interfaces ge-3/1/0 unit 0 family mpls 

set interfaces ge-3/1/2 encapsulation ethernet-ccc 

set interfaces ge-3/1/2 unit 0 

set interfaces loO unit O family inet address 10.255.10.1/32 primary 
set routing-options autonomous-system 1 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp family I2vpn auto-discovery-mspw 

set protocols bgp group mspw type internal 

set protocols bgp group mspw local-address 10.255.10.1 

set protocols bgp group mspw neighbor 10.255.2.1 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set protocols Idp interface lo0.0 

set routing-instances ms-pw instance-type I2vpn 

set routing-instances ms-pw interface ge-3/1/2.0 

set routing-instances ms-pw route-distinguisher 10.10.10.10:15 
set routing-instances ms-pw |2vpn-id I2vpn-id:100:15 

set routing-instances ms-pw vrf-target target:100:115 
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set routing-instances ms-pw protocols I2vpn site CE1 source-attachment-identifier 800:800:800 

set routing-instances ms-pw protocols I2vpn site CE1 interface ge-3/1/2.0 target-attachment-identifier 
700:700:700 

set routing-instances ms-pw protocols I2vpn pseudowire-status-tlv 

set routing-instances ms-pw protocols I2vpn oam bfd-liveness-detection minimum-interval 300 


P1 


set interfaces ge-2/0/0 unit 0 family inet address 192.0.2.2/24 
set interfaces ge-2/0/0 unit 0 family mpls 

set interfaces ge-2/0/2 unit 0 family inet address 192.0.2.13/24 
set interfaces ge-2/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.13.1/32 primary 
set routing-options autonomous-system 1 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set protocols Idp interface lo0.0 


S-PE1 (ASBR 1) 


set interfaces ge-1/3/1 unit 0 family inet address 192.0.2.9/24 
set interfaces ge-1/3/1 unit 0 family mpls 

set interfaces ge-1/3/2 unit 0 family inet address 192.0.2.22/24 
set interfaces ge-1/3/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.2.1/32 primary 
set routing-options autonomous-system 1 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp family I2vpn auto-discovery-mspw 

set protocols bgp group to_T-PE1 type internal 

set protocols bgp group to_T-PE1 local-address 10.255.2.1 

set protocols bgp group to_T-PE1 export next-hop-self 


1184 


set protocols bgp group to_T-PE1 neighbor 10.255.10.1 

set protocols bgp group to_S-PE2 type external 

set protocols bgp group to_S-PE2 local-address 10.255.2.1 

set protocols bgp group to_S-PE2 peer-as 2 

set protocols bgp group to_S-PE2 neighbor 10.255.3.1 multihop ttl 1 
set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set protocols Idp interface lo0.0 

set policy-options policy-statement next-hop-self then next-hop self 


S-PE2 (ASBR 2) 


set interfaces ge-0/3/1 unit 0 family inet address 192.0.2.10/24 
set interfaces ge-0/3/1 unit 0 family mpls 

set interfaces ge-0/3/2 unit 0 family inet address 192.0.2.14/24 
set interfaces ge-0/3/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.3.1/32 primary 
set routing-options autonomous-system 2 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp family I2vpn auto-discovery-mspw 

set protocols bgp group to_T-PE2 type internal 

set protocols bgp group to_T-PE2 local-address 10.255.3.1 

set protocols bgp group to_T-PE2 export next-hop-self 

set protocols bgp group to_T-PE2 neighbor 10.255.14.1 

set protocols bgp group to_S-PE1 type external 

set protocols bgp group to_S-PE11 local-address 10.255.3.1 

set protocols bgp group to_S-PE1 peer-as 1 

set protocols bgp group to_S-PE1 neighbor 10.255.2.1 multihop ttl 1 
set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set protocols Idp interface lo0.0 

set policy-options policy-statement next-hop-self then next-hop self 


P2 


T-PE2 


set interfaces ge-1/3/1 unit 0 family inet address 192.0.2.5/24 
set interfaces ge-1/3/1 unit 0 family mpls 

set interfaces ge-1/3/2 unit 0 family inet address 192.0.2.4/24 
set interfaces ge-1/3/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.4.1/32 primary 
set routing-options autonomous-system 2 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set protocols Idp interface lo0.0 


set interfaces ge-2/0/0 encapsulation ethernet-ccc 

set interfaces ge-2/0/0 unit 0 

set interfaces ge-2/0/2 unit 0 family inet address 192.0.2.15/24 
set interfaces ge-2/0/2 unit 0 family mpls 

set interfaces loO unit 0 family inet address 10.255.14.1/32 primary 
set routing-options autonomous-system 2 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols bgp family I2vpn auto-discovery-mspw 

set protocols bgp group mspw type internal 

set protocols bgp group mspw local-address 10.255.14.1 

set protocols bgp group mspw neighbor 10.255.3.1 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 

set protocols Idp interface all 

set protocols Idp interface fxp0.0 disable 

set protocols Idp interface lo0.0 

set routing-instances ms-pw instance-type I2vpn 

set routing-instances ms-pw interface ge-2/0/0.0 

set routing-instances ms-pw route-distinguisher 10.10.10.10:15 
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set routing-instances ms-pw |2vpn-id I2vpn-id:100:15 

set routing-instances ms-pw vrf-target target:100:115 

set routing-instances ms-pw protocols I2vpn site CE2 source-attachment-identifier 700:700:700 

set routing-instances ms-pw protocols I2vpn site CE2 interface ge-2/0/0.0 target-attachment-identifier 
800:800:800 

set routing-instances ms-pw protocols I2vpn pseudowire-status-tlv 

set routing-instances ms-pw protocols I2vpn oam bfd-liveness-detection minimum-interval 300 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode. 


To configure the T-PE1 router in the inter-AS scenario: 


NOTE: Repeat this procedure for the T-PE2 device in the MPLS domain, after modifying the 
appropriate interface names, addresses, and other parameters. 


1. Configure the T-PE1 interfaces. 


[edit interfaces] 

user@T-PE1# set ge-3/1/0 unit O family inet address 192.0.2.1/24 
user@T-PE1# set ge-3/1/0 unit 0 family mpls 

user@T-PE1# set ge-3/1/2 encapsulation ethernet-ccc 

user@T-PE1# set ge-3/1/2 unit 0 

user@T-PE1# set loO unit O family inet address 10.255.10.1/32 primary 


2. Set the autonomous system number. 


[edit routing-options] 
user@T-PE1# set autonomous-system 1 


3. Enable MPLS on all the interfaces of T-PE1, excluding the management interface. 


[edit protocols] 
user@T-PE1# set mpls interface all 
user@T-PE1# set mpls interface fxp0.0 disable 
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4. Enable autodiscovery of intermediate S-PEs that make up the MS-PW using BGP. 


[edit protocols] 
user@T-PE1# set bgp family I2vpn auto-discovery-mspw 


5. Configure the BGP group for T-PE1. 


[edit protocols] 
user@T-PE1# set bgp group mspw type internal 


6. Assign local and neighbor addresses to the mspw group for T-PE1 to peer with S-PE1. 


[edit protocols] 
user@T-PE1# set bgp group mspw local-address 10.255.10.1 
user@T-PE1# set bgp group mspw neighbor 10.255.2.1 


7. Configure OSPF on all the interfaces of T-PE1, excluding the management interface. 


[edit protocols] 

user@T-PE1# set ospf area 0.0.0.0 interface lo0.0 
user@T-PE1# set ospf area 0.0.0.0 interface all 
user@T-PE1# set ospf area 0.0.0.0 interface fxp0.0 disable 


8. Configure LDP on all the interfaces of T-PE1, excluding the management interface. 


[edit protocols] 

user@T-PE1# set Idp interface all 
user@T-PE1# set Idp interface fxp0.0 disable 
user@T-PE1# set Idp interface lo0.0 


9. Configure the Layer 2 VPN routing instance on T-PE1. 


[edit routing-instances] 
user@T-PE1# set ms-pw instance-type I2vpn 


10. Assign the interface name for the mspw routing instance. 


[edit routing-instances] 
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user@T-PE1# set ms-pw interface ge-3/1/2.0 


11. Configure the route distinguisher for the mspw routing instance. 


[edit routing-instances] 
user@T-PE1# set ms-pw route-distinguisher 10.10.10.10:15 


12. Configure the Layer 2 VPN ID community for FEC 129 MS-PW. 


[edit routing-instances] 
user@T-PE1# set ms-pw I2vpn-id I2vpn-id:100:15 


13. Configure a VPN routing and forwarding (VRF) target for the mspw routing instance. 


[edit routing-instances] 
user@T-PE1# set ms-pw vrf-target target:100:115 


14. Configure the source attachment identifier (SAI) value using Layer 2 VPN as the routing protocol for 
the mspw routing instance. 


[edit routing-instances] 
user@T-PE1# set ms-pw protocols I2vpn site CE1 source-attachment-identifier 800:800:800 


15. Assign the interface name that connects the CE1 site to the VPN, and configure the target attachment 
identifier (TAI) value using Layer 2 VPN as the routing protocol for the mspw routing instance. 


[edit routing-instances] 
user@T-PE1# set ms-pw protocols I2vpn site CE1 interface ge-3/1/2.0 target-attachment-identifier 
700:700:700 


16. (Optional) Configure T-PE1 to send MS-PW status TLVs. 


[edit routing-instances] 
user@T-PE1# set ms-pw protocols I2vpn pseudowire-status-tlv 


17. (Optional) Configure OAM capabilities for the VPN. 
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[edit routing-instances] 
user@T-PE1# set ms-pw protocols I2vpn oam bfd-liveness-detection minimum-interval 300 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode. 


To configure S-PE1 (ASBR 1) in the inter-AS scenario: 


NOTE: Repeat this procedure for the S-PE2 (ASBR 2) device in the MPLS domain, after modifying 
the appropriate interface names, addresses, and other parameters. 


1. Configure S-PE1 (ASBR 1) interfaces. 


[edit interfaces] 

user@S-PE1# set ge-1/3/1 unit 0 family inet address 192.0.2.9/24 
user@S-PE1# set ge-1/3/1 unit 0 family mpls 

user@S-PE1# set ge-1/3/2 unit 0 family inet address 192.0.2.22/24 
user@S-PE1# set ge-1/3/2 unit O family mpls 

user@S-PE1# set loO unit O family inet address 10.255.2.1/32 primary 


2. Set the autonomous system number. 


[edit routing-options] 
user@S-PE1# set autonomous-system 1 


3. Enable MPLS on all the interfaces of S-PE1 (ASBR 1), excluding the management interface. 


[edit protocols] 
user@S-PE1# set mpls interface all 
user@S-PE1# set mpls interface fxp0.0 disable 


4. Enable autodiscovery of S-PE using BGP. 


[edit protocols] 
user@S-PE1# set bgp family I2vpn auto-discovery-mspw 
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5. Configure the IBGP group for S-PE1 (ASBR 1) to peer with T-PE1. 


[edit protocols] 
user@S-PE1# set bgp group to_T-PE1 type internal 


6. Configure the IBGP group parameters. 


[edit protocols] 

user@S-PE1# set bgp group to_T-PE11 local-address 10.255.2.1 
user@S-PE1# set bgp group to_T-PE1 export next-hop-self 
user@S-PE1# set bgp group to_T-PE1 neighbor 10.255.10.1 


7. Configure the EBGP group for S-PE1 (ASBR 1) to peer with S-PE2 (ASBR 2). 


[edit protocols] 
user@S-PE1# set bgp group to_S-PE2 type external 


8. Configure the EBGP group parameters. 


[edit protocols] 

user@S-PE1# set bgp group to_S-PE2 local-address 10.255.2.1 
user@S-PE1# set bgp group to_S-PE2 peer-as 2 

user@S-PE1# set bgp group to_S-PE2 neighbor 10.255.3.1 multihop ttl 1 


9. Configure OSPF on all the interfaces of S-PE1 (ASBR 1), excluding the management interface. 


[edit protocols] 

user@S-PE1# set ospf area 0.0.0.0 interface all 
user@S-PE1# set ospf area 0.0.0.0 interface fxp0.0 disable 
user@S-PE1# set ospf area 0.0.0.0 interface 100.0 passive 


10. Configure LDP on all the interfaces of S-PE1 (ASBR 1), excluding the management interface. 


[edit protocols] 

user@S-PE1# set Idp interface all 
user@S-PE1# set Idp interface fxp0.0 disable 
user@S-PE1# set Idp interface lo0.0 


11. Define the policy for enabling next-hop-self on S-PE1 (ASBR 1). 
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[edit policy-options] 
user@S-PE1# set policy-statement next-hop-self then next-hop self 


Results 

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, 
show routing-instances, show routing-options, and show policy-options commands. If the output does 
not display the intended configuration, repeat the instructions in this example to correct the configuration. 


T-PE1 


user@T-PE1# show interfaces 
ge-3/1/0{ 
unit O { 
family inet { 
address 192.0.2.1/24, 
} 


family mpls; 


} 
ge-3/1/2 { 

encapsulation ethernet-ccc; 

unit O; 
} 
loO { 

unit O { 

family inet { 
address 10.255.10.1/32 { 


primary; 


user@T-PE1# show routing-options 
autonomous-system 1; 


user@T-PE1# show protocols 
mpls { 
interface all; 


interface fxp0.0 { 
disable; 


} 
bgp { 
family I2vpn { 
auto-discovery-mspw; 
} 
group mspw { 
type internal; 
local-address 10.255.10.1; 
neighbor 10.255.2.1; 


} 
ospf { 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 
} 


interface 100.0; 


} 
Idp { 
interface all; 
interface fxp0.0 { 
disable; 
} 


interface 100.0; 


user@T-PE1# show routing-instances 
ms-pw { 
instance-type |2vpn; 
interface ge-3/1/2.0; 
route-distinguisher 10.10.10.10:15; 
|2vpn-id I2vpn-id:100:15; 
vrf-target target:100:115; 
protocols { 
I2vpn { 
site CE1 { 
source-attachment-identifier 800:800:800; 
interface ge-3/1/2.0 { 
target-attachment-identifier 700:700:700; 
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} 
pseudowire-status-tlv; 
oam { 
bfd-liveness-detection { 
minimum-interval 300; 


S-PE1 (RR 1) 


user@S-PE1# show interfaces 
ge-1/3/1 { 
unit O { 
family inet { 
address 192.0.2.9/24- 
} 


family mpls; 


} 
ge-1/3/2 { 
unit O { 
family inet { 
address 192.0.2.22/24- 
} 


family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 10.255.2.1/32 { 
primary; 
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user@T-PE1# show routing-options 
autonomous-system 1; 


user@S-PE1# show protocols 
mpls { 
interface all; 
interface fxp0.0 { 
disable; 


} 
bgp { 
family I2vpn { 
auto-discovery-mspw; 
} 
group to_T-PE1 { 
type internal; 
local-address 10.255.2.1; 
export next-hop-self; 
neighbor 10.255.10.1; 
} 
group to_S-PE2 { 
type external; 
local-address 10.255.2.1; 
peer-as 2; 
neighbor 10.255.3.1 { 
multihop { 
ttl 1; 


} 
ospf { 
area 0.0.0.0 { 
interface 100.0 { 
passive; 
} 
interface all; 
interface fxp0.0 { 
disable; 


} 
Idp { 
interface all; 
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interface fxp0.0 { 
disable; 
} 


interface 100.0; 


user@T-PE1# show policy-options 
policy-statement next-hop-self { 
then { 
next-hop self; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


Verifying the Routes | 1195 

Verifying the LDP Database | 1198 

Checking the MS-PW Connections on T-PE1 | 1199 
Checking the MS-PW Connections on S-PE1 | 1201 
Checking the MS-PW Connections on S-PE2 | 1202 


Checking the MS-PW Connections on T-PE2 | 1204 


Confirm that the configuration is working properly. 
Verifying the Routes 


Purpose 


Verify that the expected routes are learned. 


Action 
From operational mode, run the show route command for the bgp.I2vpn.1, Idp.I2vpn.1, mpls.0, and 
ms-pw.|2vpn.1 routing tables. 


From operational mode, run the show route table bgp.I2vpn.1 command. 


user@T-PE1> show route table bgp.!2vpn.1 
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bgp.12vpn.1: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


10.10.10.10:15:700:0.0.2.188:700/160 AD2 
STXES/LIO] LSeilseiil, lloesziljoxese 100, irem 10,255.21 





AS path: 2 I, validation-state: unverified 
> to 205.0.113.2 wa ge-3/1/0.0, Puisin Z000LG 


From operational mode, run the show route table Idp.I2vpn.1 command. 





user@T-PE1> show route table Idp.!2vpn.1 


ldp.1l2vpn.1: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 
10.255.2.1:CtrlWord:5:100:15:700:0.0.2.188:700:800:0.0.3.32:800/304 PW2 


= [DIP /9] W6s2ies27 


Discard 


From operational mode, run the show route table mpls.0 command. 





user@T-PE1> show route table mpls.0 


mpls.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) 
































+ = Active Route, Last Active, * = Both 
0 *[MPLS/0] lw6d 00:28:26, metric 1 
Receive 
al *[MPLS/0] lw6d 00:28:26, metric 1 
Receive 
2 *[MPLS/0] lw6d 00:28:26, metric 1 
Receive 
13 *[MPLS/0] lw6d 00:28:26, metric 1 
Receive 
2IIFA0 *[LDP/9] Iw5d 01:26:08, metric 1 
> tO 203,0,113.2 wie ge—3/1/0.0, Perm 
299920 (S=0) > EDP Oi liwS di Ols2ioc087 meter cul 
> co 203,0.113.2 wie ge-S/1/0.0, Pee 
2OQSVS 36 *[LDP/9] lw5d 01:26:08, metric 1 
Om OS Onalls men tcC es 5)/4/OmOF mo wallms UOOMaG 
300096 ww /9]| ISE22e35, mereiee I 
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> to 208.05113-2 wia ge=3/1/0).0, Swap 3200128 
SOONsE2 “([UD2/9]) I6s22335, meiceske I 

> OZ 0ST On Sk 2s velamcge=3//i9/0R 0; swans OOM44 
SOOAS “([LD2/9] I6s22335, meee 

> tO 2Z03.0.113.2 waa ge—-3/1/0.0, Sap 300150 
300144 *(L2VPN/ 7) L6e223 33 

Sela en o/l/ 210 Op Offset: 4 
ge-3/1/2.0 A(L2VPN/7 |) Me:22333, metric2 1 











S cO 203 0,113.2 wie ge-3/1/0.0, Pusin SOOL76, Pusian SOOMLG Geos) 
Oimireecs 252 


From operational mode, run the show route table ms-pw.I2vpn.1 command. 





user@T-PE1> show route table ms-pw.|2vpn.1 


ms-pw.12vpn.1: 4 destinations, 4 routes (4 active, 0 holddown, O hidden) 


+ = Active Route, Last Active, * = Both 








10.10.10, 1OsISe700sO0.0.2,L88e 700/150 AwZ 
[EL /ILVO]| LGEzss27, ikeesilioieese 100, semen 10. 255,21 
AS path: 2 I, validation-state: unverified 
> tO 205,0,113,2 wia ge-S/1/0.0, Pusin 300016 
ORT EOP HOMeRO BSS OO Om Om eio 2a 0107 NO OmAD?. 
~[LAVEN/ LTO] iwScl 23e25s19, wmeicrie2 i 





Indirect 
10.255 .2.leCeieilitoiccls 53 lOOs Lae 7000.0. 2.18383 /00S800S0.0.3.328300/ 304 PZ 


* [DIP /9] Wes2se75) 
Discard 
10.255.2, leCeriliworels 53 LOOsIL Ss SO0S0,.0. 3, 3238003 7000 O.2 1883 700/304 PN 


LEVEN / W]| Les23s27, urexciedie2 i 
> to 205.0.113.2 wa Ge-3/1/0.0, Puisin 200016 


Meaning 


The output shows all the learned routes, including the autodiscovery (AD) routes. 
The AD2 prefix format is RD:SAII-type2, where: 


e RDis the route distinguisher value. 


e SAllI-type2 is the type 2 source attachment identifier value. 
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The PW2 prefix format is Neighbor_Addr:C:PWtype:|2vpn-id:SAll-type2:TAII-type2, where: 


e Neighbor_Addr is the loopback address of neighboring S-PE device. 


e C indicates if Control Word (CW) is enabled or not. 


e Cis CtrlWord if CW is set. 
e Cis NoCtrlWord if CW is not set. 


e PWtype indicates the type of the pseudowire. 


e PWtype is 4 if it is in Ethernet tagged mode. 


e PWtype is 5 if it is Ethernet only. 


e I2vpn-id is the Layer 2 VPN ID for the MS-PW routing instance. 
e SAIl-type2 is the type 2 source attachment identifier value. 


e TAIlI-type2 is the type 2 target attachment identifier value. 


Verifying the LDP Database 


Purpose 
Verify the MS-PW labels received by T-PE1 from S-PE1 and sent from T-PE1 to S-PE1. 


Action 


From operational mode, run the show Idp database command. 





user@T-PE1> show Idp database 


inputs labelmdatrabase, 0m 2 55.07 OSS lO 255.2. eG) 


Label Prefix 

S 10,2552 .1/32 
300112 10 255,31 / 32 
300128 10) 255.54 1/32 
299968 LO. 255,10, 1/32 
299904 10. 255.13 ,1/32 
300144 10,255,114, 1/32 


300176 FEC129 CtriWord ETHERNET 000a0064:0000000f 000002bc:000002bc:000002bc 
00000320:00000320:00000320 


OuEpuiEabcI database men Oh 2 oor O rela i0 Oke Sore eenlash 0) 


Label Prefix 
ZI ISS 10,255 2, 1/32 
300096 10 255.3, 1/32 


300112 10.255 ,4.1/32 


3 
299920 
300128 
300144 


10,255.10. 1/32 

10,255,133 ,1/32 

10. 255.14 1/32 
FEC129 CtrlWord ETHERNET 000a0064:0000000f 00000320:00000320:00000320 
000002bc:000002bc:000002bc 


iigjeuic ieloeil cleitcaloase, 10.255, 10), 130-10), 255,413,130 


Label 
300016 
300128 
300144 
300080 

8 
300160 


IDISSuE ase 


10,299 .2 61/32 


10). 
ALO) 
AL(0) , 
ALO) 
Or, 


DSS) 
2S) 0 
ZDS) 5 


ZS 


BSS) 6 


31/32 
4.1/32 
LO. 1L/s2 
sl. 1/32 
14.1/32 


OQueput Habel database, UOR25 5. 10r 10-10. 255- 3k 


Label 
ZOO ISS 
300096 
SOOT 

3 
BINA 
300128 


Meaning 


Prefix 


ALO) 5 
IL(O) 
SOR 
Os 
LO) 5 
ALO) 


Zoo 
Zoo 
25S) 
DIS) 
2S) 
ZS) 


sally 32 
sSol p32 
sao lf 3e 
oO, L/ 32 
el Bcl/32 
oA Ly 32 


The labels with FEC129 prefix are related to the MS-PW. 


Checking the MS-PW Connections on T-PE1 


Purpose 


Make sure that all of the FEC 129 MS-PW connections come up correctly. 


Action 


From operational mode, run the show I2vpn connections extensive command. 





user@T-P 





E1> show I2vpn connections extensive 


Layer-2 VPN connections: 


Legend for connection status (St) 





EI -- encapsulation invalid NC interfac ncapsulation not CCC/TCC/VPLS 





EM -- encapsulation mismatch WE -- interface and instance encaps not same 


1199 





1200 














VWC=Dm == Waliitued ciremiic clowm NP —-— interface hardware not present 
CM -—- control-word mismatch —> -- only outbound connection is up 
CNP Se SeCiiiie motoroveesehomed <a OnhyvareEno ounce One ci HOnmrssmmtl) 
OR -- out of range Up -—- operational 
OL -—- no outgoing label Dn -—- down 
LD -—- local site signaled down CF -—- call admission control failure 
RD remote site signaled down SC -—- local and remote site ID collision 
LN -- local site not designated LM -- local site ID not minimum designated 
RN remote site not designated RM remote site ID not minimum designated 
XX -—- unknown connection status IL -- no incoming label 

eV Ween siricitecitat MI -- Mesh-Group ID not available 
BK -- Backup connection ST -- Standby connection 
PF —- Profile parse failure PB == PiroieLile lousy 
RS remote site standby SN -- Static Neighbor 
LB -- Local site not best-sit RB Remote site not best-sit 
VM —-— VLAN ID mismatch 
Legend for interface status 
Up -—- operational 
Dn clown 
instance: ms—-pw 

LZwem—dels IG si5 
Number of local interfaces: 1 


Number of local interfaces up: 
ge-3/1/2.0 
































Local source-attachment—id: 800:0.0.3.32:800 (CE1) 
Target-attachment—id Type St Time last up # Up trans 
T0020 504251883 700 rmt Up Sijo Ike Wilei@gss 2Ois il 
Remote PE: 10.255.2.1, Negotiated control-word: Yes (Null) 
Incoming label: 300048, Outgoing label: 300016 
Negotiated PW status TLV: Yes 
local PW status code: 0x00000000, Neighbor PW status code: 0x00000000 
Local interface: ge-3/1/2.0, Status: Up, Encapsulation: ETHERNET 
Pseudowire Switching Points 
Local address Remote address Status 
IO .-2aS eB ai 10,295) 5 Sho 1 forwarding 
10.255 o 35d 10.255) 5 14. forwarding 
Connection History: 
Sep 18 01:10:55 2013 status update timer 
Sep 18 01:10:55 2013 PE route changed 
Sep 18 01:10:55 2013 Out lbl Update 300016 
Sep 18 01:10:55 2013 In lbl Update 300048 
Sejo 18 O1sIOssS BOIS ISS ame wo ge-—3/1/2.0 
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Check the following fields in the output to verify that MS-PW is established between the T-PE devices: 


e Target-attachment-id—Check if the TAI value is the SAI value of T-PE2. 


S-PE2 to T-PE2. 


Meaning 


Remote PE—Check if the T-PE2 loopback address is listed. 
Negotiated PW status TLV—Ensure that the value is Yes. 


Pseudowire Switching Points—Check if the switching points are listed from S-PE1 to S-PE2 and from 


MS-PW is established between T-PE1 and T-PE2 in the forwarding direction. 


Checking the MS-PW Connections on S-PE1 


Purpose 


Make sure that all of the FEC 129 MS-PW connections come up correctly for the mspw routing instance. 


Action 


From operational mode, run the show I2vpn connections instance _MSPW__ extensive command. 


user@S-PI 





(ea 





BK 
BE 
RS 
LB 





VM 


Legend for connection status 





Layer-2 VPN connections: 


EI -- encapsulation invalid 


encapsulation mismatch 





(St) 


NC 


= 
eal 





E1> show I2vpn connections instance __MSPW_ extensive 








interfac ncapsulation not CCC/TCC/VPLS 


interface and instance encaps not same 











Diag —= Waietwell Caliecmilie Clenin NP interface hardware not present 
== Comerol—woircl muLSsiMeEC!n => only outbound connection is up 
== C1PCUALE mot pronalsiemec! <= only inbound connection is up 
—- out of range Up operational 
-—- no outgoing label Dn down 
-- local site signaled down CF call admission control failure 
remote site signaled down SC local and remote site ID collision 
-- local site not designated LM local site ID not minimum designated 
remote site not designated RM remote site ID not minimum designated 
—- unknown connection status IL no incoming label 
== MENU iLsaencGln MI Mesh-Group ID not available 
-- Backup connection Sit Standby connection 
-- Profile parse failure PB Profile busy 
remote site standby SN Static Neighbor 
-- Local site not best-sit RB Remote site not best-sit 
—-— VLAN ID mismatch 


Legend for interface status 


Up -- operational 

Dn -—-— down 

Instance: __ MSPW__ 
LZwwei—dels JOO s iS 





Local source-attachment-—id: 
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TOO OR OR 2 els Siei0l0) 








Target-—attachment—id Type St Time last up # Up trans 
SOOMOR ORs 2110010 rmt Up Seo It Oileilye sissy AOS dl 
Remote PE: 10.255.10.1, Negotiated control-word: Yes (Null), Encapsulation: 
ETHERNET 
Incoming label: 300016, Outgoing label: 300048 
Negotiated PW status TLV: Yes 
local PW status code: 0x00000000, Neighbor PW status code: 0x00000000 
Local source-attachment-—id: 800:0.0.3.32:800 
Target-attachment—id Type St Time last up # Up trans 
OOOO Ree ES SEw 00 rmt Up Seo is Oilsil/gse 2Ols il 
Remote PE: 10.255.3.1, Negotiated control-word: Yes (Null), Encapsulation: 
ETHERNET 
Incoming label: 300000, Outgoing label: 300064 
Negotiated PW status TLV: Yes 
local PW status code: 0x00000000, Neighbor PW status code: 0x00000000 
Pseudowire Switching Points 
Local address Remote address Status 
10 .2aS¢3nl 10). 255), 14 a forwarding 


Check the following fields in the output to verify that MS-PW is established between the T-PE devices: 


Meaning 


Target-attachment-id—Check if the TAI value is the SAI value of T-PE2. 
Remote PE—Check if the T-PE1 and S-PE2 loopback addresses are listed. 
Negotiated PW status TLV—Ensure that the value is Yes. 


Pseudowire Switching Points—Check if the switching points are listed from S-PE2 to T-PE2. 


MS-PW is established between T-PE1 and T-PE2 in the forwarding direction. 


Checking the MS-PW Connections on S-PE2 


Purpose 


Make sure that all of the FEC 129 MS-PW connections come up correctly for the mspw routing instance. 


Action 
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From operational mode, run the show I2vpn connections instance _MSPW__ extensive command. 


user@S-P 


EL 








BK 
PE 
RS 
LB 





VM 





Layer-2 VPN connections: 


Legend for connection status 


encapsulation invalid 
encapsulation mismatch 
== Waserual ciremit cow 
control-word mismatch 
circuit not provisione 
out of range 

no outgoing label 


local site signaled do 





remote site signaled d 





E2> show I2vpn connections instance __MSPW_ extensive 








local site not designa 


interfac ncapsulation not CCC/TCC/VPLS 
interface and instance encaps not same 
interface hardware not present 

only outbound connection is up 

only inbound connection is up 
operational 

down 

call admission control failure 

local and remote site ID collision 


local site ID not minimum designated 





remote site not design 
unknown connection sta 
MTU mismatch 

Backup connection 


Profile parse failure 





remote site standby 


(St) 
NC 
WE 
n NP 
-> 
d << 
Up 
Dn 
wn Ce 
own SC 
ted LM 
ated RM 
US eae 
MI 
Sa 
PE 
SN 
ie RB 


remote site ID not minimum designated 
no incoming label 

Mesh-Group ID not available 

Standby connection 

Profile busy 

Static Neighbor 





Local site not best-si 


VLAN ID mismatch 


Legend for interface status 


Up -—- operational 
Dn — ClO wil 
Instance: __ MSPW__ 





Ta 
80 


LZryoir—sels JOO 3415 


Local source-attachment-—id: 


rget-attachment—id 
ORIOR ORS S2e151010 
Remiowee IHR 10), 25)5),% 4 il, 





x 








ETH 





ERN 


KT 





Incoming label: 300064 
Negotiated PW status T 


local PW status code: 





Pseudowire Switching P 
Local address 
10.255) ¢ 2) 41 


iype 


TES, 


Remote site not best-sit 


TOO3 0.052 1883 700 


Time last up # Up trans 
Sep lemC0 sei Som 20s a 





Negotiated control-word: Yes (Null), Encapsulation: 


, Outgoing label: 300000 


LV: Yes 


0x00000000, 


oints 


Neighbor PW status code: 0x00000000 


Remote address Deals) 
110) 5 2S. ILO) ., forwarding 
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Local source-attachment—id: 800:0.0.3.32:800 
Time last up # Up trans 
Sejo 18 OWsSSss5 2013 1 
Cina LL) ;, 


Target-—attachment—id Type St 
LOO OR OR eS ai 00) rmt Up 


Remote PE: 10.255.14.1, Negotiated control-word: Yes 


= 








Encapsulation: 








ETHERNET 
Incoming label: 300048, Outgoing label: 300112 
Negotiated PW status TLV: Yes 
local PW status code: 0x00000000, Neighbor PW status code: 0x00000000 











Check the following fields in the output to verify that MS-PW is established between the T-PE devices: 


e Target-attachment-id—Check if the TAI value is the SAI value of T-PE1. 
e Remote PE—Check if the S-PE1 and T-PE2 loopback addresses are listed. 
e Negotiated PW status TLV—Ensure that the value is Yes. 


e Pseudowire Switching Points—Check if the switching points are listed from S-PE1 to T-PE1. 


Meaning 
MS-PW is established between T-PE1 and T-PE2 in the reverse direction. 


Checking the MS-PW Connections on T-PE2 


Purpose 


Make sure that all of the FEC 129 MS-PW connections come up correctly. 
Action 


From operational mode, run the show I2vpn connections extensive command. 





user@T-PE2> show I2vpn connections extensive 


Layer-2 VPN connections: 


Legend for connection status (St) 

















EI -- encapsulation invalid NC interfac ncapsulation not CCC/TCC/VPLS 
EM -- encapsulation mismatch WE -- interface and instance encaps not same 
WC=Dm == Wilierual Ciremiic clowm NP —-— interface hardware not present 

CM -—- control-word mismatch => only outbound connection is up 

CNRS Se FC Like OtmOGOveeselomec g= only inbound connection is up 

ORS Ouro eEange Up operational 

OL -- no outgoing label Dn down 

LD -—- local site signaled down CH call admission control failure 

RD remote site signaled down SC local and remote site ID collision 











ID not minimum designated 








VM -- VLAN ID mismatch 


Legend for interface status 
Up -—- operational 


De ClLowan 


instance: ms—pw 
OOR SES 


Number of local interfaces: 1 


L2vpn-id: 


Number of local interfaces up: 


e 


LN -—- local site not designated LM local site ID not minimum designated 
RN remote site not designated RM remote sit 
XX -- unknown connection status IL no incoming label 
—-— MTU mismatch MI Mesh-Group ID not available 
BK -- Backup connection Si Standby connection 
PF —-— Profile parse failure PB Profile busy 
RS remote site standby SN Static Neighbor 
LB -- Local site not best-sit RB Remote site not best-sit 





ge-2/0/0.0 

Locals sounce -ateachment — wc Ol0 Om Om 2a ke srt OO (CE 2) 
Target-attachment—id Typ 
SOO08050.3.d32880C rmt 





Negotiated PW status TLV: Y 
local PW status code: 


Local interface: ge-2/0/0.0 





Pseudowire Switching Points 


Remote PE: 10.255.3.1, Negotiated control-word: Yes 
Incoming label: 300112, Outgoing label: 


es 


0x00000000, 
Sicsiciwiss Wie, 


, 


Time last up # Up trans 
Seo It} Oilesoe2i ALS dl 
(Null) 
300048 
Neighbor PW status code: 0x00000000 

















Encapsulation: ETHERNET 





Local address Remote address Status 
10. Bas 63.1 105295) 5 2.51 forwarding 
10.295 62 od 110) 5 BOS). AMO) .. a forwarding 


Connection History: 


Sep 18 01:35:21 2013 status update timer 





Sejo Is Olssoe2i 201s Pip, 
Scp mec Oks orale Ops 
Sey ils} Wilesag2il Zils} 
Sejs) is} Wilssiag Ail 7 (0)ils} 


Check the following fields in the output to verify that MS-PW is established between the T-PE devices: 


route changed 


Out lbl Update 
In lbl Update 
exe aimiei® wo 


300048 
300112 
ge-2/0/0.0 


e Target-attachment-id—Check if the TAI value is the SAI value of T-PE1. 


e Remote PE—Check if the T-PE1 loopback address is listed. 
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e Negotiated PW status TLV—Ensure that the value is Yes. 


e Pseudowire Switching Points—Check if the switching points are listed from S-PE2 to S-PE1 and from 
S-PE1 to T-PE1. 


Meaning 
MS-PW is established between T-PE1 and T-PE2 in the reverse direction. 


Troubleshooting 


IN THIS SECTION 


@ Ping | 1206 
@ Bidirectional Forwarding Detection | 1207 
@ Traceroute | 1208 


To troubleshoot the MS-PW connection, see: 
Ping 
Problem 


How to check the connectivity between the T-PE devices and between a T-PE device and an intermediary 
device. 


Solution 


Verify that T-PE1 can ping T-PE2. The ping mpls I2vpn fec129 command accepts SAls and TAls as integers 
or IP addresses and also allows you to use the CE-facing interface instead of the other parameters (instance, 
local-id, remote-id, remote-pe-address). 


Checking Connectivity Between T-PE1 and T-PE2 





user@T-PE1> ping mplsl2vpn fec129 instance FEC129-VPWS local-id 800:800:800 remote-pe-address 
10.255.14.1 remote-id 700:700:700 


=== Ising SEsiELsties === 


5 packets transmitted, 5 packets received, 0% packet loss 





user@T-PE1> ping mpls I2vpn fec129 interface ge-3/1/2 
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=== Isjoiline] Sie LSiees; === 


5 packets transmitted, 5 packets received, 0% packet loss 


Checking Connectivity Between T-PE1 and S-PE2 





user@T-PE1> ping mpls I2vpn fec129 interface ge-3/1/2 bottom-label-ttl 2 


=== Isgoling SEairisties === 


5 packets transmitted, 5 packets received, 0% packet loss 


Bidirectional Forwarding Detection 


Problem 
How to use BFD to troubleshoot the MS-PW connection from the T-PE device. 


Solution 


From operational mode, verify the show bfd session extensive command output. 





user@T-PE1> show bfd session extensive 


Detect Transmit 
Address State Interface Time Interval Multiplier 
198, 51.,100 .7/ Up ge-3/1/0.0 OR010 0.300 3 


Client FEC129-OAM, TX interval 0.300, RX interval 0.300 





Session up time 03:12:42 
Local diagnostic None, remote diagnostic None 


Remote state Up, version 1 





Replicated 

Session type: VCCV BFD 

Min async interval 0.300, min slow interval 1.000 

Adaptive async TX interval 0.300, RX interval 0.300 

Local min TX interval 0.300, minimum RX interval 0.300, multiplier 3 
Remote min TX interval 0.300, min RX interval 0.300, multiplier 3 
Local discriminator 19, remote discriminator 19 


Echo mode disabled/inactive 





Remote is control-plane independent 
eM Clam ORMeo mmo coll clo UO Om OpomoertS OO PmmRe Mote. clam OO OP Ome eelna Gea O10) 
Session ID: 0x103 





1 sessions, 1 clients 


Cumulative transmit rate 3.3 pps, 


Traceroute 


Problem 


How to verify that MS-PW was established. 


Solution 


From operational mode, verify traceroute output. 





cumulativ 


receive rat 





user@T-PE1> traceroute mpls I2vpn fec129 interface interface 


Probe options: ttl 64, 


retries 3, exp 7 


ie AL Label Protocol Address 
1 FEC129 10. 255510.1 
2 BRELZ9 10 255.3 ol 
5 FEC1I29 10 - 255.531 
4 IMHO ALAS) 10.2585 14 4 





Path 1 via ge-3/1/2 destination 198.51. 








MPLS Stitching For Virtual Machine Connection 


IN THIS SECTION 


Q&A | 1210 


When Would | Use Stitching? | 1209 
How Does MPLS Stitching Work? | 1209 
How Do | Configure Stitching? | 1210 
Which Switches Support Stitching? | 1210 


Previous Hop 


Cents) 


10,2535 10, 1 


LO, 29.6415 LL 


LO, 2556208 


LO) 510 


Probe Status 


Success 


Success 


Success 





HoBesis 
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By using MPLS, the stitching feature of Junos OS provides connectivity between virtual machines that 
reside either on opposite sides of data center routers or in different data centers. An external controller, 
programmed in the data-plane, assigns MPLS labels to both virtual machines and servers. Then, the signaled 
MPLS labels are used between the data center routers, generating static link switched paths (LSPs), resolved 
over either BGP labeled unicast, RSVP or LDP, to provide the routes dictated by the labels. 


When Would | Use Stitching? 


There are several ways to connect virtual machines. One option when you have virtual machines on 
opposite sides of a router (or different data centers) is to use MPLS stitching. A typical topology for using 
MPLS stitching is shown in Figure 98 on page 1209. 


Figure 98: Virtual Machines on Either Side of Routers 


g043231 


Server 1 Server 2 


The above topology consists of the following MPLS layers: VMs | Servers | ToRs | Router... Router | ToRs 
| Servers | VMs 


NOTE: The label on the left is the top of the label stack. 


How Does MPLS Stitching Work? 


With stitching, the MPLS static allocation of labels demultiplexes incoming traffic onto any device/entity 
in the next layer in the direction of traffic flow. Essentially, there is a label hierarchy that picks up labels 
for the correct top-of-rack switch, server, and virtual machine that receives traffic. Static label assignments 
are done between the top-of-rack switches and the virtual machines. 


For example, imagine that traffic is sent from VM1 to VM3 in Figure 98 on page 1209. When traffic exits 
Server 1, its label stack is L1 | L2 | L3 where: 


e L1 represents the egress top-of-rack switch ToR1. 
e L2 represents the physical server, Server2, towards which the egress-side ToR will forward the traffic. 


e L3: represents the virtual machine on Server2 to which the Server2 should deliver the traffic. 


Traffic arriving at ToR1 needs to be sent to ToR2. Since ToR1 and ToR2 are not directly connected, traffic 
must flow from ToR1 to ToR2 using label-switching starting on the outermost (top) label. Stitching has 
been added to static-LSP functionality to SWAP L1 to a I-BGP label that ToR2 advertises to ToR1. The 
label stack now must contain another label at the top to enable forwarding of the labeled packets between 
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ToR1 and ToR2. An L-Top label is added if L-BGP is resolved over RSVP/LDP. If static LSP is resolved over 
L-BGP, then the top label is swapped with the L-BGP label and there is no L-Top label. When the traffic 
exits ToR1, the stack is: L-top | L-BGP | L2 | L3. 


Traffic from ToR1 to ToR2 is then label switched over any signaled LSP. 


When traffic arrives at ToR2, the top label is removed with PHP (popped) and the label stack becomes 
L-BGP | L2 | L3. Since L-BGP is a implicit null label, ToR2 pops the static LSP label L2 that corresponds to 
the egress server and then forwards the packet to the egress server using the static-LSP configuration on 
ToR2, which corresponds to a single-hop implicit-NULL LSP. 


The outgoing stack becomes L3 and the next-hop is the egress server Server2. 


When traffic arrives at the egress server Server2, Server2 pops L3 and delivers the packet to VM3. 


How Do | Configure Stitching? 


The new keyword stitch has been added under transit to resolve the remote next-hop. For example, instead 
of set protocols mpls static-label-switched-path static-to-ToR2 transit 1000000 next-hop 10.9.82.47, a 
top-of-rack switch redirects packets to another top-of-rack switch with set protocols mpls 
static-label-switched-path static-to- ToR2 transit 1000000 stitch. The show mpls static-lsp command has 
been extended to show the LSP state as 'InProgress' whenever the LSP is waiting for protocol next-hop 
resolution by resolver. 


See the complete example for stitching at Using MPLS Stitching with BGP to Connect Virtual Machines for 
more information. 


Which Switches Support Stitching? 


See Feature Explorer for the list of switches that support the MPLS Stitching For Virtual Machine 
Connections feature. 


Q&A 
Q: Is link and node protection for the next-hop provided by MPLS stitching? 


A: Link and node protection for the next-hop of transit LSP stitched to L-BGP LSP are not needed. That 
is provided by L-BGP LSP. 


TDM Pseudowires Overview 


A TDM pseudowire acts as Layer 2 circuit or service for T1 and E11 circuit signals across an MPLS 
packet-switched network. On ACX Series routers, you configure a TDM pseudowire with Structure-Agnostic 
Time Division Multiplexing (TDM) over Packet (SAToP) on the ACX Series built-in channelized T1 and E1 
interfaces. When you configure a TDM pseudowire, the network between the customer edge (CE) routers 
appears transparent to the CE routers, making it seem that the CE routers are directly connected. With 
the SAToP configuration on the provider edge (PE) router’s T1 and E11 interfaces, the interworking function 
(IWF) forms a payload (frame) that contains the CE router’s T1 and E1 Layer 1 data and control word. This 
data is transported to the remote PE over the pseudowire. The remote PE removes all the Layer 2 and 


MPLS headers added in the network cloud and forwards the control word and the Layer 1 data to the 
remote IWF, which in turn forwards the data to the remote CE router. 


Example: TDM Pseudowire Base Configuration 


IN THIS SECTION 


@ Requirements | 1211 
@ Overview of a TDM Pseudowire Base Configuration | 1211 
@ Configuring an TDM Pseudowire | 1211 


Requirements 


The following is a list of the hardware and software requirements for this configuration. 


e One ACX Series router 


e Junos OS Release 12.2 or later 


Overview of a TDM Pseudowire Base Configuration 


The configuration shown here is the base configuration of an TDM pseudowire with T1 framing on an 
ACX Series router. This configuration is for one provider edge router. To complete the TDM pseudowire 
configuration, you need to repeat this configuration on an other provider edge router in the Multiprotocol 
Label Switched (MPLS) network. 


Configuring an TDM Pseudowire 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them in a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level: 


set chassis fpc 0 pic 0 framing tl 





set interfaces ct1-0/0/0 no-partition interface-type tl 





set interfaces t1-0/0/0 encapsulation satop 
set interfaces t1-0/0/0 unit 0 
set interfaces ge-0/2/0 unit 0 family inet address 20.1.1.2/24 











set interfaces ge-0/2/0 unit 0 family mpls 





set interfaces 100 unit 0 family inet address 70.1.1.1/32 


set protocols rsvp interface ge-0/2/0.0 





set protocols mpls no-cspf 
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SCE PEOLOCOL 
Set Provocolt 
De Emo LOLOC Ons 
See PLOEOCOL 
sce PEOLEOCOL 
SCE WP EOLOCo. 


See PEROLOCOL 








See PLOEOCOL 





mpls 
mpls 
ospf 
ospf 
ospf 
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label-switched-path PEI-to-PE2 to 40.1.1.1 
interface ge-0/2/0.0 





traffic-engineering 
area 0.0.0.0 interface ge-0/2/0.0 


area 0.0.0.0 interface 100.0 passive 


ldp interface ge-0/2/0.0 


ldp interface 100.0 


IZCACEUIE MELGbisore 420 ,1,1,1 imeerracs c1-0/0/0,.0 wiecmel-circidic—idl 


NOTE: To configure a TDM pseudowire with E1 framing, include the e1 statement at the [edit 
chassis fpc 0 pic O framing] hierarchy level instead of the t1 statement shown in this example. 


Step-by-Step Procedure 


1. Configure the framing format: 


[edit] 


user@host# edit chassis 


[edit chassis] 


user@host# set fpc 0 pic O framing t1 


2. Create a T1 interface on a channelized T1 interface (ct1) and enable full channelization with the 
no-partition statement. On the logical T1 interface, set the Structure-Agnostic TDM over Packet 
(SAToP) encapsulation mode. 


[edit] 


user@host# edit interfaces 


[edit interfaces] 
user@host# set ct1-0/0/0 no-partition interface-type t1 
user@host# set t1-0/0/0 encapsulation satop 
user@host# set t1-0/0/0 unit 0 
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3. Create a Gigabit Ethernet interface and enable MPLS on that interface. Create the loopback (loO) 
interface: 


[edit interfaces] 

user@host# set ge-0/2/0 unit 0 family inet address 20.1.1.2/24 
user@host# set ge-0/2/0 unit O family mpls 

user@host# set loO unit O family inet address 70.1.1.1/32 


4. Enable the MPLS and RSVP protocols on the MPLS interface—ge-0/2/0.0: 


[edit] 

user@host# edit protocols 

[edit protocols] 

user@host# set rsvp interface ge-0/2/0.0 
user@host# set mpls interface ge-0/2/0.0 


5. Configure LDP. If you configure RSVP for a pseudowire, you must also configure LDP: 


[edit protocols] 
user@host# set Idp interface ge-0/2/0.0 
user@host# set Idp interface lo0.0 


6. Configure a point-to-point label-switched path (LSP) and disable constrained-path LSP computation: 


[edit protocols] 
user@host# set mpls label-switched-path PE1-to-PE2 to 40.1.1.1 
user@host# set mpls no-cspf 


7. Configure OSPF and enable traffic engineering on the MPLS interface—ge-0/2/0.0, and on the loopback 
(lo) interface: 


[edit protocols] 

user@host# set ospf traffic-engineering 

user@host# set ospf area 0.0.0.0 interface ge-0/2/0.0 
user@host# set ospf area 0.0.0.0 interface lo0.0 passive 
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8. Uniquely identify a Layer 2 circuit for the TDM pseudowire: 


[edit protocols] 
user@host# set I2circuit neighbor 40.1.1.1 interface t1-0/0/0.0 virtual-circuit-id 1 


Results 


[edit] 
user@host# show 


Chiaisisuasuad| 
roe O i 
ple © { 
icenmaling; ie lp 


} 
interfaces { 


Stel O/ O10 
no-partition interface-type tl; 


} 
EL-O/O/O 
encapsulation satop; 


winaic, Op 
} 
ge-0/2/0 { 
Binwic O ff 
family inet { 
addisesisie7 Or luelmees/ 2:47 


} 
family mpls; 


} 
Leo 4 
winsie 0 ff 
family inet { 
aceleess VOL. /s2e 


} 


PHOEOCOMmS ma 


ESV 
interface ge-0/2/0.0; 


} 
mpls { 
MO-CSIIE 2 
label-switched-path PE1-to-PE2 { 
c@ 051,10. 1° 














} 
interface ge-0/2/0.0; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface ge-0/2/0.0; 
interface 100.0 { 


passive; 


} 

ldp { 
interface ge-0/2/0.0; 
interface 100.0; 


} 
UZAkeuseciwakic 4 
neighbor 40.1.1.1 { 
interface t1-0/0/0.0 { 


WaLicie wie ll —Cculieealic—aiel ibe 


Configuring Load Balancing for Ethernet Pseudowires 
You can configure load balancing for IPv4 traffic over Layer 2 Ethernet pseudowires. You can also configure 


load balancing for Ethernet pseudowires based on IP information. The option to include IP information in 
the hash key provides support for Ethernet circuit cross-connect (CCC) connections. 


NOTE: This feature is supported only on M120, M320, MX Series, and T Series routers. 


To configure load balancing for IPv4 traffic over Layer 2 Ethernet pseudowires, include the ether-pseudowire 
statement at the [edit forwarding-options hash-key family mpls payload] hierarchy level: 
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[edit forwarding-options] 
hash-key { 
family mpls { 
(label-1 | no-labels); 
payload { 
ether-pseudowire; 


NOTE: You must also configure either the label-1 or the no-labels statement at the [edit 
forwarding-options hash-key family mpls] hierarchy level. 


You can also configure load balancing for Ethernet pseudowires based on IP information. This functionality 
provides support for load balancing for Ethernet cross-circuit connect (CCC) connections. To include IP 


information in the hash key, include the ip statement at the [edit forwarding-options hash-key family mpls 
payload] hierarchy level: 


[edit forwarding-options] 
hash-key { 
family mpls { 
(label-1 | no-labels); 
payload { 
ip; 
} 


NOTE: You must also configure either the label-1 or no-labels statement at the [edit 
forwarding-options hash-key family mpls] hierarchy level. 


You can configure load balancing for IPv4 traffic over Ethernet pseudowires to include only Layer 3 IP 
information in the hash key. To include only Layer 3 IP information, include the layer-3-only option at the 
[edit forwarding-options family mpls hash-key payload ip] hierarchy level: 


[edit forwarding-options] 
hash-key { 
family mpls { 
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(label-1 | no-labels); 
payload { 
ip { 
layer-3-only; 


NOTE: You must also configure either the label-1 or no-labels statement at the [edit 
forwarding-options hash-key family mpls] hierarchy level. 


Configuring Load Balancing Based on MAC Addresses 


The hash key mechanism for load-balancing uses Layer 2 media access control (MAC) information such as 
frame source and destination address. To load-balance traffic based on Layer 2 MAC information, include 
the family multiservice statement at the [edit forwarding-options hash-key] hierarchy level: 


family multiservice { 
destination-mac; 


source-mac, 


To include the destination-address MAC information in the hash key, include the destination-mac option. 
To include the source-address MAC information in the hash key, include the source-mac option. 


NOTE: Any packets that have the same source and destination address will be sent over the 
same path. 


NOTE: You can configure per-packet load balancing to optimize VPLS traffic flows across multiple 
paths. 
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NOTE: Aggregated Ethernet member links will now use the physical MAC address as the source 
MAC address in 802.3ah OAM packets. 


NOTE: ACX Series routers do not support VPLS. 


Release History Table 


Release Description 


14.1X53 Starting in Junos OS Release 14.1X53 and Junos OS Release 16.1, an Ethernet pseudowire is 
used to carry Ethernet or 802.3 Protocol Data Units (PDUs) over an MPLS network enabling 
service providers to offer emulated Ethernet services over existing MPLS networks. 
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Configuring Class of Service for MPLS LSPs 


IN THIS SECTION 


@ = Class of Service for MPLS Overview | 1220 
@ = Configuring the MPLS CoS Values | 1220 
@ Rewriting IEEE 802.1p Packet Headers with the MPLS CoS Value | 1223 


The following sections provide an overview of MPLS class of service (CoS) and describe how to configure 
the MPLS CoS value: 


Class of Service for MPLS Overview 


When IP traffic enters an LSP tunnel, the ingress router marks all packets with a CoS value, which is used 
to place the traffic into a transmission priority queue. On the router, for SDH/SONET and T3 interfaces, 
each interface has four transmit queues. The CoS value is encoded as part of the MPLS header and remains 
in the packets until the MPLS header is removed when the packets exit from the egress router. The routers 
within the LSP utilize the CoS value set at the ingress router. The CoS value is encoded by means of the 

CoS bits (also known as the EXP or experimental bits). For more information, see “MPLS Label Allocation” 
on page 422. 


MPLS class of service works in conjunction with the router’s general CoS functionality. If you do not 
configure any CoS features, the default general CoS settings are used. For MPLS class of service, you might 
want to prioritize how the transmit queues are serviced by configuring weighted round-robin, and to 
configure congestion avoidance using random early detection (RED).. 


Configuring the MPLS CoS Values 


When traffic enters an LSP tunnel, the CoS value in the MPLS header is set in one of three ways: 


e The number of the output queue into which the packet was buffered and the packet loss priority (PLP) 
bit are written into the MPLS header and are used as the packet’s CoS value. This behavior is the default, 
and no configuration is required. Default MPLS EXP Classifier explains the default MPLS CoS values, and 
summarizes how the CoS values are treated. 


e You seta fixed CoS value on all packets entering the LSP tunnel. A fixed CoS value means that all packets 
entering the LSP receive the same class of service. 


e You set an MPLS EXP rewrite rule to override the default behavior. 


To set a fixed CoS value on all packets entering the LSP, include the class-of-service statement: 


class-of-service cos-value; 
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You can include this statement at the following hierarchy levels: 


e [edit protocols mpls] 

e [edit protocols mpls label-switched-path path-name] 

e [edit protocols mpls label-switched-path path-name primary path-name] 

e [edit protocols mpls label-switched-path path-name secondary path-name] 

e [edit protocols rsvp interface interface-name link-protection] 

e [edit protocols rsvp interface interface-name link-protection bypass destination] 

e [edit logical-systems logical-system-name protocols mpls] 

e [edit logical-systems logical-system-name protocols mpls label-switched-path path-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path path-name primary 
path-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path path-name secondary 
path-name] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection ] 


e [edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass 
destination] 


The CoS value set using the class-of-service statement at the [edit protocols mpls] hierarchy level 
supersedes the CoS value set at the [edit class-of-service] hierarchy level for an interface. Effectively, the 
CoS value configured for an LSP overrides the CoS value set for an interface. 


The class-of-service statement at the [edit protocols mpls label-switched-path] hierarchy level assigns an 
initial EXP value for the MPLS shim header of packets in the LSP. This value is initialized at the ingress 
routing device only and overrides the rewrite configuration established for that forwarding class. However, 
the CoS processing (weighted round robin [WRR] and RED) of packets entering the ingress routing device 
is not changed by the class-of-service statement on an MPLS LSP. Classification is still based on the 
behavior aggregate (BA) classifier at the [edit class-of-service] hierarchy level or the multifield classifier 
at the [edit firewall] hierarchy level. 


BEST PRACTICE: We recommend configuring all routing devices along the LSP to have the same 
input classifier for EXP, and, if a rewrite rule is configured, all routing devices should have the 
same rewrite configuration. Otherwise, traffic at the next LSR might be classified into a different 
forwarding class, resulting in a different EXP value being written to the EXP header. 


The CoS value can be a decimal number from O through 7. This number corresponds to a 3-bit binary 
number. The high-order 2 bits of the CoS value select which transmit queue to use on the outbound 
interface card. 
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The low-order bit of the CoS value is treated as the PLP bit and is used to select the RED drop profile to 
use on the output queue. If the low-order bit is 0, the non-PLP drop profile is used, and if the low-order 
bit is 1, the PLP drop profile is used. It is generally expected that RED will more aggressively drop packets 
that have the PLP bit set. For more information about RED and drop profiles, see Managing Congestion 
Using RED Drop Profiles and Packet Loss Priorities. 


NOTE: Configuring the PLP drop profile to drop packets more aggressively (for example, setting 
the CoS value from 6 to 7) decreases the likelihood of traffic getting through. 


Table 26 on page 1222 summarizes how MPLS CoS values correspond to the transmit queue and PLP bit. 
Note that in MPLS, the mapping between the CoS bit value and the output queue is hard-coded. You 
cannot configure the mapping for MPLS; you can configure it only for IPv4 traffic flows, as described in 
Understanding How Forwarding Classes Assign Classes to Output Queues. 


Table 26: MPLS CoS Values 


MPLS CoS Value Bits Transmit Queue PLP Bit 
0 000 6) Not set 
1 001 0 Set 
2 010 1 Not set 
3 011 1 Set 
4 100 2 Not set 
5 101 2 Set 
6 110 3 Not set 
Z 111 3 Set 


Because the CoS value is part of the MPLS header, the value is associated with the packets only as they 
travel through the LSP tunnel. The value is not copied back to the IP header when the packets exit from 
the LSP tunnel. 
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To configure class of service (CoS) for Multiprotocol Label Switching (MPLS) packets in a label-switched 
path (LSP): 


1. Specify the CoS value 


If you do not specify a CoS value, the IP precedence bits from the packet’s IP header are used as the 
packet’s CoS value. 


Rewriting IEEE 802.1p Packet Headers with the MPLS CoS Value 


For Ethernet interfaces installed on a T Series router or an M320 router with a peer connection to an M 
Series router or a T Series router, you can rewrite both MPLS CoS and IEEE 802.1p values to a configured 
value (the MPLS CoS values are also known as the EXP or experimental bits). Rewriting these values allows 
you to pass the configured value to the Layer 2 VLAN path. To rewrite both the MPLS CoS and IEEE 802.1p 
values, you must include the EXP and IEEE 802.1p rewrite rules in the class of service interface configuration. 
The EXP rewrite table is applied when you configure the IEEE 802.1p and EXP rewrite rules. 


For information about how to configure the EXP and IEEE 802.1p rewrite rules, see Rewriting Packet 


Headers to Ensure Forwarding Behavior. 


Configuring MPLS Rewrite Rules 


IN THIS SECTION 


@ Rewriting the EXP Bits of All Three Labels of an Outgoing Packet | 1223 
@ ~~ Rewriting MPLS and IPv4 Packet Headers | 1224 


You can apply a number of different rewrite rules to MPLS packets. 


For more information about how to configure statements at the [edit class-of-service] hierarchy level, see 
the Class of Service User Guide (Routers and EX9200 Switches). 


The following sections describe how you can apply rewrite rules to MPLS packets: 


Rewriting the EXP Bits of All Three Labels of an Outgoing Packet 


In interprovider, carrier-of-carrier, and complex traffic engineering scenarios, it is sometimes necessary to 
push three labels on the next hop. 


By default, on M Series routers except the M320, the top MPLS EXP label of an outgoing packet is not 
rewritten when you configure swap-push-push and triple-push operations. You can rewrite the EXP bits 
of all three labels of an outgoing packet, thereby maintaining the class of service (CoS) of an incoming 
MPLS or non-MPLS packet. 
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To push three labels on incoming MPLS packets, include the exp-swap-push-push default statement at 
the [edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules] hierarchy level: 


[edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules] 
exp-swap-push-push default; 


To push three labels on incoming non-MPLS packets, include the exp-push-push-push default statement 
at the [edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules] hierarchy 
level: 


[edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules] 
exp-push-push-push default; 


For more information about how to configure statements at the [edit class-of-service] hierarchy level, see 
the Class of Service User Guide (Routers and EX9200 Switches). 


Rewriting MPLS and IPv4 Packet Headers 


You can apply a rewrite rule to MPLS and IPv4 packet headers simultaneously. This allows you to initialize 
MPLS EXP and IP precedence bits at LSP ingress. You can configure different rewrite rules depending on 
whether the traffic is VPN or non-VPN. 


To rewrite MPLS and IPv4 packet headers, include the protocol statement at the [edit class-of-service 
interfaces interface-name unit logical-unit-number rewrite-rules exp rewrite-rule-name] hierarchy level: 


[edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules exp rewrite-rule-name] 
protocol types; 


Use the protocol statement to specify the types of MPLS packets and packet headers to which to apply 
the rewrite rule. The MPLS packet can be a standard MPLS packet or an MPLS packet with an IPv4 payload. 
Specify the type of MPLS packet by using the following options: 


mpls-any—Applies the rewrite rule to MPLS packets and writes the code point value to MPLS headers. 


mpls-inet-both—Applies the rewrite rule to VPN MPLS packets with IPv4 payloads. Writes the code 
point value to the MPLS and IPv4 headers in T Series (except T4000 routers) and M320 routers. On M 
Series routers, except the M320, the mpls-inet-both option causes all ingress MPLS LSP packets with 
IPv4 payloads to be initialized with O00 code points for IP precedence and MPLS EXP values. 


mpls-inet-both-non-vpn—Applies the rewrite rule to any non-VPN MPLS packets with IPv4 payloads. 
Writes the code point value to the MPLS and IPv4 headers in T Series and M320 routers. On M Series 
routers, except the M320, the mpls-inet-both-non-vpn option causes all ingress MPLS LSP packets with 
IPv4 payloads to be initialized with O00 code points for IP precedence and MPLS EXP values. 


For a detailed example on how to configure rewrite rules for MPLS and IPv4 packets and for more 
information about how to configure class of service, see the Class of Service User Guide (Routers and EX9200 
Switches). 


Configuring CoS Bits for an MPLS Network 


When traffic enters a labeled-switch path (LSP) tunnel, the CoS bits in the MPLS header are set in one of 
two ways: 


e The number of the output queue into which the packet was buffered and the packet loss priority (PLP) 
bit are written into the MPLS header and are used as the packet’s CoS value. This behavior is the default, 
and no configuration is required. The Junos OS Class of Service Configuration Guide explains the IP CoS 
values, and summarizes how the CoS bits are treated. 


e You seta fixed CoS value on all packets entering the LSP tunnel. A fixed CoS value means that all packets 
entering the LSP receive the same class of service. 


To set a fixed CoS value on all packets entering the LSP: 


1. Specify a class of service value for the LSP: 


NOTE: The CoS value set using the class-of-service statement at the [edit protocols mpls] 
hierarchy level supersedes the CoS value set at the [edit class-of-service] hierarchy level for 
an interface. Effectively, the CoS value configured for an LSP overrides the CoS value set for 
an interface. 


[edit protocols mpls] 


user@switch# set class-of-service cos-value 


Configuring CoS on an MPLS Provider Edge Switch Using IP Over MPLS 


You can use class of service (CoS) within MPLS networks to prioritize certain types of traffic during periods 
of congestion. This topic describes configuring CoS components on a provider edge (PE) switch that is 
using IP Over MPLS. 


This task describes how to create a custom DSCP classifier and a custom EXP rewrite rule on the ingress 
PE switch. It includes configuring a policer firewall filter and applying it to the customer-edge interface of 
the ingress PE switch. The policer firewall filter ensures that the amount of traffic forwarded through the 
MPLS tunnel never exceeds the requested bandwidth allocation. 


Before you begin, configure the basic components for an MPLS network: 
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e Configure two PE switches. See “Configuring MPLS on Provider Edge EX8200 and EX4500 Switches 
Using Circuit Cross-Connect” on page 74. 


e Configure one or more provider switches. See “Configuring MPLS on EX8200 and EX4500 Provider 
Switches” on page 78. 


This topic includes: 


41: Configuring CoS | 1226 
2. Configuring an LSP Policer | 1227 


Configuring CoS 


To configure CoS on a provider edge switch: 


1. Import the default DSCP classifier classes to the custom DSCP classifier that you are creating: 


[edit class-of-service] 


user@switch# set classifiers dscp classifier-name import default 


2. Add a forwarding class to this custom DSCP classifier and specify a loss priority and code point: 


[edit class-of-service] 
user@switch# set classifiers dscp classifier-name forwarding-class forwarding-class loss-priority 


loss-priority code-points code-point 
3. Specify the values for the custom EXP rewrite rule, e1: 


[edit class-of-service] 
user@switch# set rewrite-rules exp e1 forwarding-class forwarding-class loss-priority loss-priority 


code-points code-point 


4. On EX8200 switches only, bind the custom EXP rewrite rule to the interface: 


[edit class-of-service] 


user@switch# set class-of-service interfaces interface unit unit rewrite-rules exp e1 
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Configuring an LSP Policer 


To configure an LSP policer: 


NOTE: You cannot configure LSP policers on EX8200 switches. EX8200 switches do not support 
LSP policers. 


1. Specify the number of bits per second permitted, on average, for the firewall policer, which will later 
be applied to the customer-edge-interface: 


[edit firewall] 


user@switch# set policer mypolicer if-exceeding bandwidth-limit 500m 


2. Specify the maximum size permitted for bursts of data that exceed the given bandwidth limit for this 
policer: 





[edit firewall policer] 


user@switch# set mypolicer if-exceeding burst-size-limit 33553920 


3. Discard traffic that exceeds the rate limits for this policer: 





[edit firewall policer] 


user@switch# set mypolicer then discard 
4. To reference the policer, configure a filter term that includes the policer action: 


[edit firewall] 


user@switch# set family inet filter myfilter term t1 then policer mypolicer 
5. Apply the filter to the customer-edge interface: 


[edit interfaces] 


user@switch# set ge-2/0/3 unit O family inet address 192.168.121.1/16 policing filter myfilter 


NOTE: You can also configure schedulers and shapers as needed. See Defining CoS Schedulers 
and Scheduler Maps (CLI Procedure). 
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Configuring CoS on an MPLS Provider Edge Switch Using Circuit Cross-Connect 


You can use class of service (CoS) within MPLS networks to prioritize certain types of traffic during periods 
of congestion. This topic describes configuring CoS components on a provider edge (PE) switch that is 
using MPLS over circuit-cross connect (CCC). 


NOTE: On EX Series switches other than EX8200 switches, if you are using MPLS over CCC, 
you can use only one DSCP or IP precedence classifier and only one IEEE 802.1p classifier on 
the CCC interfaces. 


This procedure is for creating a custom DSCP classifier and a custom EXP rewrite rule on the ingress PE. 
It also includes enabling a policer on the label-switched path (LSP) of the ingress PE to ensure that the 
amount of traffic forwarded through the LSP never exceeds the requested bandwidth allocation. 


This topic includes: 


1. Configuring CoS | 1228 
2; Configuring an LSP Policer | 1229 


Configuring CoS 


To configure CoS on a provider edge switch: 


1. Import the default DSCP classifier classes to the custom DSCP classifier that you are creating: 


[edit class-of-service] 


user@switch# set classifiers dscp classifier-nameimport default 


2. Add the expedited-forwarding class to this custom DSCP classifier, specifying a loss priority and code 
point: 


[edit class-of-service] 
user@switch# set classifiers dscp classifier-name forwarding-class forwarding-class loss-priority 


loss-priority code-points code-point 
3. Specify the values for the custom EXP rewrite rule, e1: 


[edit class-of-service] 
user@switch# set rewrite-rules exp e1 forwarding-class forwarding-class loss-priority loss-priority 


code-point code-point 
4. Bind the DSCP classifier to the CCC interface: 


[edit ] 
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user@switch# set class-of-service interfaces interface unit unit classifier classifier-name 


5. On EX8200 switches only, bind the custom EXP rewrite rule to the interface: 
[edit class-of-service] 


user@switch# set class-of-service interfaces interface unit unit rewrite-rules exp e1 


Configuring an LSP Policer 


To configure an LSP policer: 


NOTE: You cannot configure LSP policers on EX8200 switches. EX8200 switches do not support 
LSP policers. 


1. Specify the number of bits per second permitted, on average, for the policer, which will later be applied 
to the LSP: 


[edit firewall] 


set policer mypolicer if-exceeding bandwidth-limit 500m 


2. Specify the maximum size permitted for bursts of data that exceed the given bandwidth limit for this 
policer: 


[edit firewall policer] 





set mypolicer if-exceeding burst-size-limit 33553920 


3. Discard traffic that exceeds the rate limits for this policer: 


[edit firewall policer] 





set mypolicer then discard 
4. To reference the policer, configure a filter term that includes the policer action: 


[edit firewall] 


user@switch# set family any filter myfilter term t1 then policer mypolicer 


5. Apply the filter to the LSP: 


[edit protocols mpls] 
set label-switched-path Isp_to_pe2_ge1 policing filter myfilter 
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NOTE: You can also configure schedulers and shapers as needed. See Defining CoS Schedulers 
and Scheduler Maps (CLI Procedure). 


Configuring CoS on Provider Switches of an MPLS Network 


You can add class-of-service (CoS) components to your MPLS networks on EX Series switches to achieve 
end-to-end Differentiated Services to match your specific business requirements. The configuration of 
CoS components on the provider switches is the same regardless of whether the provider edge (PE) 
switches are using MPLS over CCC or IP over MPLS. 


This task shows how to configure a custom EXP classifier and custom EXP rewrite rule on the provider 
switch. 


1. Import the default EXP classifier classes to the custom EXP classifier that you are creating: 


[edit class-of-service] 


user@switch# set classifiers exp exp1 import default 


2. Add the expedited-forwarding class to this custom EXP classifier, specifying a loss priority and code 
point: 


[edit class-of-service] 
user@switch# set classifiers exp exp1 forwarding-class expedited-forwarding loss-priority low 


code-points 010 
3. Specify the values for the custom EXP rewrite rule, e1: 


[edit class-of-service] 
user@switch# set rewrite-rules exp e1 forwarding-class expedited-forwarding loss-priority low 


code-point 111 
4. On EX8200 switches only, bind the custom EXP rewrite rule to the interface: 


[edit class-of-service] 


user@switch# set class-of-service interfaces ge-0/0/2 unit O rewrite-rules exp e1 


NOTE: You can also configure schedulers and shapers as needed. See Defining CoS Schedulers 
and Scheduler Maps (CLI Procedure). 


Understanding Using CoS with MPLS Networks on EX Series Switches 


IN THIS SECTION 


EXP Classifiers and EXP rewrite Rules | 1231 
Guidelines for Using CoS Classifiers on CCCs | 1232 
Using CoS Classifiers with IP over MPLS | 1232 
Setting CoS Bits inan MPLS Header | 1233 

EXP Rewrite Rules | 1234 

Policer | 1234 


Schedulers | 1235 


You can use class of service (CoS) within MPLS networks to prioritize certain types of traffic during periods 
of congestion. See EX Series Switch Software Features Overview for a complete list of the Junos OS MPLS 
features that are supported on specific EX Series switches. 


Juniper Networks EX Series Ethernet Switches support Differentiated Service Code Point (DSCP) or IP 
precedence and IEEE 802.1p CoS classifiers on the customer-edge interfaces of the ingress provider edge 
(PE) switch. DSCP or IP precedence classifiers are used for Layer 3 packets. IEEE 802.1p is used for Layer 
2 packets. 


When a packet enters a customer-edge interface of the ingress PE switch, the switch associates the packet 
with a particular CoS servicing level before putting the packet onto the label-switched path (LSP). The 
switches within the LSP utilize the CoS value set at the ingress PE switch. The CoS value that was embedded 
in the classifier is translated and encoded in the MPLS header by means of the EXP or experimental bits. 
EX Series switches enable a default EXP classifier and a default EXP rewrite rule. For more information 
about EXP classifiers and EXP rewrite rules, see EXP Classifiers and EXP rewrite Rules. 


This topic includes: 


EXP Classifiers and EXP rewrite Rules 


EX Series switches enable a default EXP classifier and a default EXP rewrite rule. You can configure a 
custom EXP classifier and a custom EXP rewrite rule if you prefer. However, the switch supports only one 
type of EXP classifier (default or custom) and only one EXP rewrite rule (default or custom). 


You do not bind the EXP classifier or the EXP rewrite rule to individual interfaces. The switch automatically 
and implicitly applies the default or the custom EXP classifier and the default or the custom EXP rewrite 
rule to the appropriate MPLS-enabled interfaces. Because rewrite rules affect only egress interfaces, the 
switch applies the EXP rewrite rule only to those MPLS interfaces that are transmitting MPLS packets (not 
to the MPLS interfaces that are receiving the packets). 
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After traversing the MPLS tunnel, the traffic flows out from the egress provider edge (PE) switch. Before 
the traffic leaves the egress interface, the egress PE switch copies the EXP bits from the MPLS header to 
the most significant bits in the original IP packet--- that is, to the IP precedence bits. Note that this is the 
default behavior only on Juniper Networks EX8200 Ethernet Switches (standalone or Virtual Chassis) that 
are configured for MPLS. 


Guidelines for Using CoS Classifiers on CCCs 


When you are configuring CoS for MPLS over circuit cross-connect (CCC), there are some additional 
guidelines, as follows: 


e You must explicitly bind a CoS classifier to the CCC interface on the ingress PE switch. 


e You must use the same DSCP, IP precedence, or IEEE 802.1p classifier on CCC interfaces. However, if 
the CCC interfaces are on the same switch, you cannot configure both a DSCP and an IP precedence 
classifier on these interfaces. Thus, if you configure one CCC interface to use a DSCP classifier DSCP1, 
you cannot configure another CCC interface to use another DSCP classifier DSCP2. All the CCC interfaces 
on the switch must use the same DSCP (or IP precedence) classifier and the same IEEE 802.1p classifier. 


e You cannot configure one CCC interface to use a DSCP classifier and another CCC interface to use an 
IP precedence classifier, because these classifier types overlap. 


e You can configure one CCC interface to use a DSCP classifier and another CCC interface to use IEEE 
802.1p classifier. 


e You can configure one CCC interface to use both a DSCP and an IEEE 802.1p classifier. If you configure 
a CCC interface to use both these classifiers, the DSCP classifier is used for routing Layer 3 packets and 
the IEEE 802.1p classifier is used for routing Layer 2 packets. 


e You can configure one CCC interface to use both an IP precedence and an IEEE 802.1p classifier. If you 
configure a CCC interface to use both these classifiers, the IP precedence classifier is used for routing 
Layer 3 packets and the IEEE 802.1p classifier is used for routing Layer 2 packets. 


NOTE: These guidelines are not applicable to Juniper Networks EX8200 Ethernet Switches 
(standalone or Virtual Chassis). 


You can define multiple DSCP, IP precedence, and IEEE 802.1p classifiers for the non-CCC interfaces on 
a switch. 


Using CoS Classifiers with IP over MPLS 


When you are configuring CoS for IP over MPLS, the customer-edge interface uses the CoS configuration 
for the switch as the default. You do not have to bind a classifier to the customer-edge interface in this 
case. There are no restrictions on using multiple DSCP, IP precedence, and IEEE 802.1p classifiers on the 
same switch. 


e You can modify the CoS classifier for a particular interface, but it is not required. 
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e You can configure a DSCP classifier, DSCP1 on the first interface, another DSCP classifier, DSCP2 on 
the second interface, and an IP precedence classifier on a third interface, and so forth. 


Setting CoS Bits in an MPLS Header 


When traffic enters an LSP tunnel, the CoS bits in the MPLS header are set in one of two ways: 


e The number of the output queue into which the packet was buffered and the packet loss priority (PLP) 
bit are written into the MPLS header and are used as the packet’s CoS value. This behavior is the default, 
and no configuration is required. The Class of Service User Guide (Routers and EX9200 Switches) explains 
the IP CoS values, and summarizes how the CoS bits are treated. 


e You seta fixed CoS value on all packets entering the LSP tunnel. A fixed CoS value means that all packets 
entering the LSP receive the same class of service. 


The CoS value can be a decimal number from O through 7. This number corresponds to a 3-bit binary 
number. The high-order 2 bits of the CoS value select which transmit queue to use on the outbound 


interface card. 


The low-order bit of the CoS value is treated as the PLP bit and is used to select the RED drop profile to 
use on the output queue. If the low-order bit is 0, the non-PLP drop profile is used, and if the low-order 
bit is 1, the PLP drop profile is used. It is generally expected that random early detection (RED) will more 
aggressively drop packets that have the PLP bit set. For more information about RED and drop profiles, 

see the Class of Service User Guide (Routers and EX9200 Switches). 


NOTE: Configuring the PLP drop profile to drop packets more aggressively (for example, setting 
the CoS value from 6 to 7) decreases the likelihood of traffic getting through. 


Table 27 on page 1233 summarizes how MPLS CoS values correspond to the transmit queue and PLP bit. 
Note that in MPLS, the mapping between the CoS bit value and the output queue is hard-coded. You 
cannot configure the mapping for MPLS; you can configure it only for IPv4 traffic flows, as described in 
the Class of Service User Guide (Routers and EX9200 Switches). 


Table 27: MPLS CoS Values 


MPLS CoS Value Bits Transmit Queue PLP Bit 
0) 000 0) Not set 
1 001 0 Set 

2 010 1 Not set 


3 011 a Set 
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Table 27: MPLS CoS Values (continued) 


MPLS CoS Value Bits Transmit Queue PLP Bit 
4 100 2 Not set 
5 101 2 Set 
6 110 3 Not set 
7 111 3 Set 


Because the CoS value is part of the MPLS header, the value is associated with the packets only while 
they travel through the LSP tunnel. The value is not copied back to the IP header when the packets exit 
from the LSP tunnel. 


NOTE: On EX8200 switches that run MPLS-based Layer 2 virtual private networks (VPNs): 


e If you configure an LSP CoS, the EXP bits of the MPLS packet continue to use the same CoS 
values that are configured at the interface level. 


e For Virtual Chassis, if the input and output interfaces are on different line cards, then the loss 
priority value that you configured on the first line card is not carried to the subsequent line 
cards. The loss priority for the outgoing traffic from the subsequent line cards is always set to 
low. 


EXP Rewrite Rules 


When traffic passes from the customer-edge interface to an MPLS interface, the DSCP, IP precedence, 
or IEEE 802.1p CoS classifier is translated into the EXP bits within the MPLS header. You cannot disable 
the default EXP rewrite rule, but you can configure your own custom EXP classifier and a custom EXP 
rewrite rule. You cannot bind the EXP classifier to individual MPLS interfaces; the switch applies it globally 
to all the MPLS-enabled interfaces on the switch. 


Only one EXP rewrite rule (either default or custom) is supported on a switch. The switch applies it to all 
the egress interfaces on which MPLS is enabled.. This is, however, not the case with EX8200 switches. 
With EX8200 switches, you must explicitly apply the rewrite rule on each of the egress interfaces. 


Policer 


Policing helps to ensure that the amount of traffic forwarded through an LSP never exceeds the requested 
bandwidth allocation. During periods of congestion (when the total rate of queuing packets exceeds the 
rate of transmission), any new packets being sent to an interface can be dropped because there is no place 
to store them. You can configure a policer on the ingress PE switch to prevent this: 
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e If you are using MPLS over CCC, you bind the policer to the LSP. You cannot bind a policer to a CCC 
interface. 


e If you are using IP over MPLS, you bind the policer to the inet-family customer-edge interface. You 
cannot bind a policer to the LSP when you are using IP over MPLS. 


NOTE: You cannot configure LSP policers on EX8200 switches. 


Schedulers 


The schedulers for using CoS with MPLS are the same as for the other CoS configurations on EX Series 
switches. Default schedulers are provided for best-effort and network-control forwarding classes. If you 
are using assured-forwarding, expedited-forwarding, or any custom forwarding class, we recommend that 
you configure a scheduler to support that forwarding class. See Understanding CoS Schedulers. 


Example: Combining CoS with MPLS on EX Series Switches 


IN THIS SECTION 


Requirements | 1236 

Overview and Topology | 1236 
Configuring the Local PE Switch | 1238 
Configuring the Remote PE Switch | 1241 
Configuring the Provider Switch | 1242 


Verification | 1243 


You can use class of service (CoS) within MPLS networks to prioritize certain types of traffic during periods 
of congestion. The CoS value is included within the MPLS label, which is passed through the network, 
enabling end-to-end CoS across the network. 


MPLS services are often used to ensure better performance for low-latency applications such as VoIP and 
other business-critical functions. These applications place specific demands on a network for successful 
transmission. CoS gives you the ability to control the mix of bandwidth, delay, jitter, and packet loss while 
taking advantage of the MPLS labeling mechanism. 


This example shows how to configure CoS on an MPLS network that is using a unidirectional circuit 
cross-connect (CCC) from the ingress provider edge (PE) switch to the egress PE switch. for the 
customer-edge interface of the ingress provider edge (PE) switch. It describes adding the configuration of 
CoS components to the ingress PE switch, the egress PE switch, and the core provider switches of the 
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existing MPLS network. Because of the unidirectional configuration, the DSCP classifier needs to be 
configured only on the ingress PE switch. 
Requirements 


This example uses the following hardware and software components: 


e Junos OS Release 10.1 or later for EX Series switches 


e Three EX Series switches 
Before you configure CoS with MPLS, be sure you have: 


Configured an MPLS network with two PE switches and one provider switch. See “Example: Configuring 
MPLS on EX8200 and EX4500 Switches” on page 42. This example assumes that an MPLS network has 
been configured using a cross circuit-connect (CCC). 


Overview and Topology 


This example describes adding custom classifiers and custom rewrite rules to switches in an MPLS network 
that is using MPLS over CCC. 


It is a unidirectional configuration. Therefore, you need to configure custom classifiers and custom rewrite 
rules as follows: 


e On the ingress PE switch: custom DSCP classifier and custom EXP rewrite rule 
e On the egress PE switch: custom EXP classifier 


e On the provider switch: customer EXP classifier and custom EXP rewrite rule 


NOTE: You can also configure schedulers and shapers as needed. If you are using 
assured-forwarding, expedited-forwarding, or other custom forwarding classes, we recommend 
that you configure a scheduler to support that forwarding class. See Defining CoS Schedulers and 
Scheduler Maps (CLI Procedure). 


The example creates a custom DSCP classifier (dscp1) on the ingress PE switch and binds this classifier to 
the CCC interface. It includes configuration of a policer on the ingress PE switch. The policer is applied as 
a filter on the label-switched path (LSP) Isp_to_pe2_ge1(created in “Example: Configuring MPLS on EX8200 
and EX4500 Switches” on page 42) to ensure that the amount of traffic forwarded through the LSP never 
exceeds the requested bandwidth allocation. 


This example creates a custom EXP rewrite rule (exp1) on the ingress PE switch, specifying a loss-priority 
and code point to be used for the expedited-forwarding class as the packet travels through the LSP. The 
switch applies this custom rewrite rule on the core interfaces ge-0/0/5.0 and ge-0/0/6.0, which are the 

egress interfaces for this switch. 


Table 28 on page 1237 shows the CoS configuration components added to the ingress PE switch. 


Table 28: CoS Configuration Components on the Ingress PE Switch 


Property 


Local PE switch hardware 


Policing filter configured and applied 
to the LSP. 


Custom DSCP classifier 


Custom EXP rewrite rule 


Customer-edge interface 


Core interfaces 


Settings 


EX Series switch 


policing filter mypolicer 


filter myfilter 


dscp1 


el 


ge-0/0/1.0 


ge-0/0/5.0 and ge-0/0/6.0 
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Description 


PE-1 


Name of the rate-limiting policer. 


Name of the filter, which refers to the 
policer 


Specifies the name of the custom 
DSCP classifier 


Name of the custom EXP rewrite rule. 


Interface that receives packets from 


devices outside the network. 


The custom DSCP classifier must be 
specified on this CCC interface. 


Interfaces that transmit MPLS packets 
to other switches within the MPLS 
network. 


The EXP rewrite rule is applied 
implicitly to these interfaces. 


Table 29 on page 1237 shows the CoS configuration components added to the egress PE switch in this 


example. 


Table 29: CoS Configuration Components of the Egress PE Switch 


Property 


Remote provider edge switch 
hardware 


Custom EXP classifier 


Customer-edge interface 


Settings 


EX Series switch 


exp1 


ge-0/0/1.0 


Description 


PE-2 


Name of custom EXP classifier 


Interface that transmits packets from 
this network to devices outside the 
network. No CoS classifier is specified 
for this interface. A scheduler can be 
specified. 
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Table 29: CoS Configuration Components of the Egress PE Switch (continued) 


Property 


Core interfaces 


Settings 


ge-0/0/7.0 and ge-0/0/8.0 


Description 


Core interfaces on PE-2 that receive 
MPLS packets from the provider 
switch. The EXP classifier is enabled 
by default on the switch and applied 
implicitly to these interfaces. 


Table 30 on page 1238 shows the MPLS configuration components used for the provider switch in this 


example. 


Table 30: CoS Configuration Components of the Provider Switch 


Property 


Provider switch hardware 


Custom EXP classifier 
Custom EXP rewrite rule 


Core interfaces receiving packets 
from other MPLS switches. 


Core interfaces transmitting packets 
to other switches within the MPLS 
network. 


Configuring the Local PE Switch 


CLI Quick Configuration 


Settings 


EX Series switch 


exp1 


el 


ge-0/0/5.0 and ge-0/0/6.0 


ge-0/0/7.0 and ge-0/0/8.0 


Description 


Transit switch within the MPLS 
network configuration. 


Name of the custom EXP classifier. 


Name of the custom EXP rewrite rule. 


Interfaces that connect the provider 
switch to the ingress PE switch 
(PE-1). The EXP classifier is enabled 
by default on the switch and applied 
implicitly to these interfaces. 


Interfaces that transmit packets to 
the egress PE (PE-2). The EXP rewrite 
rule is applied implicitly on these 
interfaces. Schedulers can also be 
specified and will be applied to these 
interfaces. 


To quickly configure a custom DSCP classifier, custom EXP rewrite rule, and a policer on the local PE 


switch, copy the following commands and paste them into the switch terminal window of PE-1: 


[edit] 


set class-of-service classifiers dscp dscp1 import default 
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set class-of-service classifiers dscp dscp1 forwarding-class expedited-forwarding loss-priority low 
code-points 000111 

set class-of-service rewrite-rules exp e1 forwarding-class expedited-forwarding loss-priority low 
code-point 111 

set class-of-service interfaces ge-0/0/1 unit 0 classifier dscp1 

set firewall policer mypolicer if-exceeding bandwidth-limit 500m 

set firewall policer mypolicer if-exceeding burst-size-limit 33553920 

set firewall policer mypolicer then discard 

set firewall family any filter myfilter term t1 then policer mypolicer 


set protocols mpls label-switched-path Isp_to_pe2_ge1 to 127.1.1.3 policing filter myfilter 


Step-by-Step Procedure 


To configure a custom DSCP classifier, custom EXP rewrite rule, and a policer on the ingress PE switch: 
1. Import the default DSCP classifier classes to the custom DSCP classifier that you are creating: 


[edit class-of-service] 


user@switch# set classifiers dscp dscp1 import default 


2. Add the expedited-forwarding class to this custom DSCP classifier, specifying a loss priority and code 
point: 


[edit class-of-service] 
user@switch# set classifiers dscp dscp1 forwarding-class expedited-forwarding loss-priority low 
code-points 000111 


3. Specify the values for the custom EXP rewrite rule, e1: 


[edit class-of-service] 
user@switch# set rewrite-rules exp e1 forwarding-class expedited-forwarding loss-priority low 


code-point 111 
4. Bind the DSCP classifier to the CCC interface: 


[edit ] 
user@switch# set class-of-service interfaces ge-0/0/1 unit 0 classifier dscp1 


5. Specify the number of bits per second permitted, on average, for the firewall policer, which will later 
be applied to the LSP: 


[edit firewall] 


set policer mypolicer if-exceeding bandwidth-limit 500m 
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. Specify the maximum size permitted for bursts of data that exceed the given bandwidth limit for this 
policer: 


[edit firewall policer] 





set mypolicer if-exceeding burst-size-limit 33553920 


. Discard traffic that exceeds the rate limits for this policer: 


[edit firewall policer] 





set mypolicer then discard 


. To reference the policer, configure a filter term that includes the policer action: 


[edit firewall] 


user@switch# set family any filter myfilter term t1 then policer mypolicer 


. Apply the filter to the LSP: 


[edit protocols mpls] 
set label-switched-path Isp_to_pe2_ge1 policing filter myfilter 


Results 


Display the results of the configuration: 


[edit] 
user@switch# show 
class-of-service { 
classifiers { 
dscp dscp1 { 
import default; 
forwarding-class expedited-forwarding { 
loss-priority low code-points 000111; 


} 
interfaces { 
ge-0/0/1 { 
unit O { 
classifiers { 
dscp dscp1; 


rewrite-rules { 
exp e1 { 
forwarding-class expedited-forwarding { 
loss-priority low code-point 111; 


} 
firewall { 
family any { 
filter myfilter { 
term t1 { 


then policer mypolicer; 


} 
policer mypolicer { 
if-exceeding { 
bandwidth-limit 500m; 
burst-size-limit 33553920; 
} 


then discard; 


Configuring the Remote PE Switch 


CLI Quick Configuration 


To quickly configure a custom EXP classifier on the remote PE switch, copy the following commands and 
paste them into the switch terminal window of PE-2: 


[edit] 
set class-of-service classifiers exp exp1 import default 
set class-of-service classifiers exp exp1 forwarding-class expedited-forwarding loss-priority low 


code-points 010 


Step-by-Step Procedure 


To configure a custom EXP classifier on the egress PE switch: 
1. Import the default EXP classifier classes to the custom EXP classifier that you are creating: 


[edit class-of-service] 


user@switch# set classifiers exp exp1 import default 
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2. Add the expedited-forwarding class to this custom EXP classifier, specifying a loss priority and code 
point: 


[edit class-of-service] 
user@switch# set classifiers exp exp1 forwarding-class expedited-forwarding loss-priority low 


code-points 010 


Results 


Display the results of the configuration: 


[edit] 
user@switch# show 
class-of-service { 
classifiers { 
exp exp1 { 
import default; 
forwarding-class expedited-forwarding { 
loss-priority low code-points 010; 


Configuring the Provider Switch 


CLI Quick Configuration 


To quickly configure a custom EXP classifier and a custom EXP rewrite rule on the provider switch, copy 
the following commands and paste them into the switch terminal window of the provider switch: 


[edit] 

set class-of-service classifiers exp exp1 import default 

set class-of-service classifiers exp exp1 forwarding-class expedited-forwarding loss-priority low 
code-points 010 

set class-of-service rewrite-rules exp e1 forwarding-class expedited-forwarding loss-priority low 
code-point 111 


Step-by-Step Procedure 


To configure a custom EXP classifier and a custom EXP rewrite rule on the provider switch: 
1. Import the default EXP classifier classes to the custom EXP classifier that you are creating: 


[edit class-of-service] 


user@switch# set classifiers exp exp1 import default 


1243 


2. Add the expedited-forwarding class to this custom EXP classifier, specifying a loss priority and code 
point: 


[edit class-of-service] 
user@switch# set classifiers exp exp1 forwarding-class expedited-forwarding loss-priority low 
code-points 010 


3. Specify the values for the custom EXP rewrite rule, e1: 


[edit class-of-service] 
user@switch# set rewrite-rules exp e1 forwarding-class expedited-forwarding loss-priority low 
code-point 111 


Results 


Display the results of the configuration: 


[edit] 
user@switch# show 
class-of-service { 
classifiers { 
exp exp1 { 
import default; 
forwarding-class expedited-forwarding { 
loss-priority low code-points 010; 


} 
rewrite-rules { 
exp e1 { 
forwarding-class expedited-forwarding { 
loss-priority low code-point 111; 


Verification 


IN THIS SECTION 


@ Verifying That the Policer Firewall Filter ls Operational | 1244 
@ Verifying That the CoS Classifiers Are Going to the Right Queue | 1244 


1244 


@ Verifying the CoS Forwarding Table Mapping | 1248 
@ Verifying the Rewrite Rules | 1249 


To confirm that the configuration is working properly, perform these tasks: 


Verifying That the Policer Firewall Filter Is Operational 


Purpose 


Verify the operational state of the policer that is configured on the ingress PE switch. 
Action 


user@switch> show firewall 


Filter: myfilter 


Policers: 

Name Packets 

mypolicer-tl 0 
Meaning 


This output shows that the firewall filter mypolicer has been created. 


Verifying That the CoS Classifiers Are Going to the Right Queue 


Purpose 


Verify that the CoS classifiers are going to the right queue. 
Action 


user@switch> show class-of-service forwarding-table classifier 


Classifier table index: 7, # entries: 64, Table type: DSCP 
Entry # Code point Forwarding-class # PLP 
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Classifier table index: 
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Table type: 





Table type: IPv4 precedence 


Table type: 
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8) 101 0 0 
6 110 0 0 
V iid 0 0 


Classifier table index: 9346, # entries: 64, Table type: DSCP 





Entry # Code point Forwarding-class # PLP 


0 000000 0 0 

1 000001 0 0 

Zz 000010 0 0 

S 000011 0 0 

4 000100 0 0 

5 000101 0 0 

6 000110 0 0 

7 000111 1 0 

8 001000 0 0 

9 001001 0 0 
10 001010 0 0 
di 001011 0 0 
alee 001100 0 0 
13 001101 0 0 
14 001110 0 0 
sls) OAL aL aL aL 0 0 
16 010000 0 0 
17 010001 0 0 
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Meaning 


This output shows that a new DSCP classifier has been created, index 9346, on the ingress PE switch 


(PE-1). 


Verifying the CoS Forwarding Table Mapping 


Purpose 


For each logical interface, display either the table index of the classifier for a given code point type or the 
queue number (if it is a fixed classification) in the forwarding table. 


Action 


user@switch>show class-of-service forwarding-table classifier mapping 
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Table Index/ 


Interface Index Q num Table type 
ge-0/0/1.0 OZ 9346 DS Cr 
Meaning 


The results show that the new DSCP classifier, index number 9346, is bound to interface ge-0/0/1.0. 


Verifying the Rewrite Rules 


Purpose 


Display mapping of the queue number and loss priority to code point value for each rewrite rule as it exists 
in the forwarding table. 


Action 


user@switch>show class-of-service forwarding-table rewrite-rule 


Rewrite table index: 31, # entries: 4, Table type: DSCP 





FC# Low bits State High bits State 
0 000000 Enabled 000000 Enabled 
i 101110 Enabled 101110 Enabled 
2 001010 Enabled 001100 Enabled 
3 110000 Enabled 111000 Enabled 














Rewrite table index: 34, # entries: 4, Table type: IEEE 802.1 














EC# Low bits State High bits State 
0 000 Enabled 001 Enabled 
il 010 Enabled 011 Enabled 
2 100 Enabled 101 Enabled 
3 110 Enabled 111 Enabled 








Rewrite table index: 35, # entries: 4, Table type: IPv4 precedence 





EC# Low bits State High bits State 
0 000 Enabled 000 Enabled 
il 101 Enabled 101 Enabled 
2 001 Enabled 001 Enabled 
3 110 Enabled 111 Enabled 








Rewrite table index: 9281, # entries: 1, Table type: EXP 
EC# Low bits State High bits State 
1 111 Enabled 000 Disabled 
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Meaning 
This output shows that a new EXP classifier with the index number 9281 has been created. 


Understanding CoS MPLS EXP Classifiers and Rewrite Rules 


IN THIS SECTION 


@ EXP Classifiers | 1251 
@ EXP Rewrite Rules | 1253 
@ = Schedulers | 1253 


You can use class of service (CoS) within MPLS networks to prioritize certain types of traffic during periods 
of congestion by applying packet classifiers and rewrite rules to the MPLS traffic. MPLS classifiers are 
global and apply to all interfaces configured as family mpls interfaces. 


When a packet enters a customer-edge interface on the ingress provider edge (PE) switch, the switch 
associates the packet with a particular CoS servicing level before placing the packet onto the label-switched 
path (LSP). The switches within the LSP utilize the CoS value set at the ingress PE switch to determine the 
CoS service level. The CoS value embedded in the classifier is translated and encoded in the MPLS header 
by means of the experimental (EXP) bits. 


EXP classifiers map incoming MPLS packets to a forwarding class and a loss priority, and assign MPLS 
packets to output queues based on the forwarding class mapping. EXP classifiers are behavior aggregate 
(BA) classifiers. 


EXP rewrite rules change (rewrite) the CoS value of the EXP bits in outgoing packets on the egress queues 
of the switch so that the new (rewritten) value matches the policies of a targeted peer. Policy matching 
allows the downstream routing platform or switch in a neighboring network to classify each packet into 
the appropriate service group. 


NOTE: On QFX5200, QFX5100, QFX3500, QF3600, and EX4600 switches, and on QFabric 
systems, there is no default EXP classifier. If you want to classify incoming MPLS packets using 
the EXP bits, you must configure a global EXP classifier. The global EXP classifier applies to all 
MPLS traffic on interfaces configured as family mpls. 


On QFX10000 switches, there is a no default EXP classifier. If you want to classify incoming 
MPLS packets using the EXP bits, you must configure EXP classifiers and apply them to logical 
interfaces configured as family mpls. (You cannot apply classifiers to physical interfaces.). You 
can configure up to 64 EXP classifiers. 


There is no default EXP rewrite rule. If you want to rewrite the EXP bit value at the egress 
interface, you must configure EXP rewrite rules and apply them to logical interfaces. 


EXP classifiers and rewrite rules are applied only to interfaces that are configured as family mpls 
(for example, set interfaces xe-0/0/35 unit O family mpls.) 


This topic includes: 


EXP Classifiers 

On QFX5200, QFX5100, EX4600, QFX3500, and QFX3600 switches, and on QFabric systems, unlike 
DSCP and IEEE 802.1p BA classifiers, EXP classifiers are global to the switch and apply to all switch 
interfaces that are configured as family mpls. On QFX10000 switches, you apply EXP classifiers to individual 
logical interfaces, and different interfaces can use different EXP classifiers. 
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When you configure and apply an EXP classifier, MPLS traffic on all family mpls interfaces uses the EXP 
classifier, even on interfaces that also have a fixed classifier. If an interface has both an EXP classifier and 
a fixed classifier, the EXP classifier is applied to MPLS traffic and the fixed classifier is applied to all other 
traffic. 


Also unlike DSCP and IEEE 802.1p BA classifiers, there is no default EXP classifier. If you want to classify 
MPLS traffic based on the EXP bits, you must explicitly configure an EXP classifier and apply it to the 
switch interfaces. Each EXP classifier has eight entries that correspond to the eight EXP CoS values (0 
through 7, which correspond to CoS bits 000 through 111). 


You can configure up to 64 EXP classifiers. 


However, on QFX5200, QFX5100, EX4600, and legacy CLI switches, the switch uses only one MPLS EXP 
classifier as a global classifier on all interfaces. After you configure an MPLS EXP classifier, you can configure 
that classifier as the global EXP classifier by including the EXP classifier in the [edit class-of-service 
system-defaults classifiers exp] hierarchy level. All switch interfaces configured as family mpls use the 
global EXP classifier to classify MPLS traffic. 


On these switches, only one EXP classifier can be configured as the global EXP classifier at any time. If 
you want to change the global EXP classifier, delete the global EXP classifier configuration (use the 
user@switch# delete class-of-service system-defaults classifiers exp configuration statement), then 
configure the new global EXP classifier. 


QFX10000 switches do not support global EXP classifiers. You can configure one EXP classifier and apply 
it to multiple logical interfaces, or configure multiple EXP classifiers and apply different EXP classifiers to 
different logical interfaces. 


If an EXP classifier is not configured, then if a fixed classifier is applied to the interface, the MPLS traffic 
uses the fixed classifier. (Switches that have a default EXP classifier use the default classifier.) If no EXP 
classifier and no fixed classifier are applied to the interface, MPLS traffic is treated as best-effort traffic 
using the 802.1 default untrusted classifier. DSCP classifiers are not applied to MPLS traffic. 


On QFX5200, QFX5100, EX4600, and legacy CLI switches, because the EXP classifier is global, you cannot 
configure some ports to use a fixed IEEE 802.1p classifier for MPLS traffic on some interfaces and the 
global EXP classifier for MPLS traffic on other interfaces. When you configure a global EXP classifier, all 
MPLS traffic on all interfaces uses the EXP classifier. 


NOTE: The switch uses only the outermost label of incoming EXP packets for classification. 


NOTE: MPLS packets with 802.1Q tags are not supported. 


EXP Rewrite Rules 


As MPLS packets enter or exit a network, edge switches might be required to alter the class-of-service 
(CoS) settings of the packets. EXP rewrite rules set the value of the EXP CoS bits within the header of the 
outgoing MPLS packet on family mpls interfaces. Each rewrite rule reads the current forwarding class and 
loss priority associated with the packet, locates the chosen CoS value from a table, and writes that CoS 
value into the packet header, replacing the old CoS value. EXP rewrite rules apply only to MPLS traffic. 


EXP rewrite rules apply only to logical interfaces. You cannot apply EXP rewrite rules to physical interfaces. 


There are no default EXP rewrite rules. If you want to rewrite the EXP value in MPLS packets, you must 
configure EXP rewrite rules and apply them to logical interfaces. If no rewrite rules are applied, all MPLS 
labels that are pushed have a value of zero (0). The EXP value remains unchanged on MPLS labels that are 
swapped. 


You can configure up to 64 EXP rewrite rules, but you can only apply 16 EXP rewrite rules at any time on 
the switch. On a given logical interface, all pushed MPLS labels have the same EXP rewrite rule applied to 
them. You can apply different EXP rewrite rules to different logical interfaces on the same physical interface. 


You can apply an EXP rewrite rule to an interface that has a DSCP, DSCP IPv6, or IEEE 802.1p rewrite 
rule. Only MPLS traffic uses the EXP rewrite rule. MPLS traffic does not use DSCP or DSCP IPvé6 rewrite 
rules. 


If the switch is performing penultimate hop popping (PHP), EXP rewrite rules do not take effect. If both 
an EXP classifier and an EXP rewrite rule are configured on the switch, then the EXP value from the last 
popped label is copied into the inner label. If either an EXP classifier or an EXP rewrite rule (but not both) 
is configured on the switch, then the inner label EXP value is sent unchanged. 


NOTE: On each physical interface, either all forwarding classes that are being used on the 
interface must have rewrite rules configured or no forwarding classes that are being used on 
the interface can have rewrite rules configured. On any physical port, do not mix forwarding 
classes with rewrite rules and forwarding classes without rewrite rules. 


Schedulers 


The schedulers for using CoS with MPLS are the same as for the other CoS configurations on the switch. 
Default schedulers are provided only for the best-effort, fcoe, no-loss, and network-control default 
forwarding classes. If you configure a custom forwarding class for MPLS traffic, you need to configure a 
scheduler to support that forwarding class and provide bandwidth to that forwarding class. 
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Configuring Rewrite Rules for MPLS EXP Classifiers 


You configure EXP rewrite rules to alter CoS values in outgoing MPLS packets on the outbound family 
mpls interfaces of a switch to match the policies of a targeted peer. Policy matching allows the downstream 
routing platform or switch in a neighboring network to classify each packet into the appropriate service 
group. 


To configure an EXP CoS rewrite rule, create the rule by giving it a name and associating it with a forwarding 
class, loss priority, and code point. This creates a rewrite table. After the rewrite rule is created, enable it 
on a logical family mpls interface. EXP rewrite rules can only be enabled on logical family mpls interfaces, 
not on physical interfaces or on interfaces of other family types. You can also apply an existing EXP rewrite 
rule on a logical interface. 


NOTE: There are no default rewrite rules. 


You can configure up to 64 EXP rewrite rules, but you can only use 16 EXP rewrite rules at any time on 
the switch. On a given family mpls logical interface, all pushed MPLS labels have the same EXP rewrite 
rule applied to them. You can apply different EXP rewrite rules to different logical interfaces on the same 
physical interface. 


NOTE: On each physical interface, either all forwarding classes that are being used on the 
interface must have rewrite rules configured, or no forwarding classes that are being used on 
the interface can have rewrite rules configured. On any physical port, do not mix forwarding 
classes with rewrite rules and forwarding classes without rewrite rules. 


NOTE: To replace an existing rewrite rule on the interface with a new rewrite rule of the same 
type, first explicitly remove the existing rewrite rule and then apply the new rule. 


To create an EXP rewrite rule for MPLS traffic and enable it on a logical interface: 


1. Create an EXP rewrite rule: 


user@switch# set class-of-service rewrite-rules exp rewrite-rule-name forwarding-class 


forwarding-class-name loss-priority level code-points [aliases] [bit-patterns] 


For example, to configure an EXP rewrite rule named exp-rr-1 for a forwarding class named mpls-1 
with a loss priority of low that rewrites the EXP code point value to 001: 
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user@switch# set class-of-service rewrite-rules exp exp-rr-1 forwarding-class mpls-1 loss-priority 
low code-points 001 
. Apply the rewrite rule to a logical interface: 


user@switch # set class-of-service interfaces interface-name unit logical-unit rewrite-rules exp 


rewrite-rule-name 

For example, to apply a rewrite rule named exp-rr-1 to logical interface xe-0/0/10.0: 

user@switch# set class-of-service interfaces xe-0/0/10 unit O rewrite-rules exp exp-rr-1 
NOTE: In this example, all forwarding classes assigned to port xe-O0/0/10 must have rewrite 


rules. Do not mix forwarding classes that have rewrite rules with forwarding classes that do 
not have rewrite rules on the same interface. 
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Configuring CoS Bits for an MPLS Network 


When traffic enters a labeled-switch path (LSP) tunnel, the CoS bits in the MPLS header are set in one of 


two ways: 


e The number of the output queue into which the packet was buffered and the packet loss priority (PLP) 
bit are written into the MPLS header and are used as the packet’s CoS value. This behavior is the default, 
and no configuration is required. The Class of Service User Guide (Routers and EX9200 Switches) explains 
the IP CoS values, and summarizes how the CoS bits are treated. 


e You seta fixed CoS value on all packets entering the LSP tunnel. A fixed CoS value means that all packets 
entering the LSP receive the same class of service. 


To set a fixed CoS value on all packets entering the LSP: 


1. Specify a class of service value for the LSP: 


NOTE: The CoS value set using the class-of-service statement at the [edit protocols mpls] 
hierarchy level supersedes the CoS value set at the [edit class-of-service] hierarchy level for 
an interface. Effectively, the CoS value configured for an LSP overrides the CoS value set for 
an interface. 


[edit protocols mpls] 


user@switch# set class-of-service cos-value 
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Configuring a Global MPLS EXP Classifier 


EXP packet classification associates incoming packets with a particular MPLS CoS servicing level. EXP 
behavior aggregate (BA) classifiers examine the MPLS EXP value in the packet header to determine the 
CoS settings applied to the packet. EXP BA classifiers allow you to set the forwarding class and loss priority 
of an MPLS packet based on the incoming CoS value. 


You can configure up to 64 EXP classifiers, however, the switch uses only one MPLS EXP classifier as a 
global classifier, which is applied only on interfaces configured as family mpls. All family mpls switch 
interfaces use the global EXP classifier to classify MPLS traffic. 


There is no default EXP classifier. If you want to classify incoming MPLS packets using the EXP bits, you 
must configure a global EXP classifier. The global classifier applies to all MPLS traffic on all family mpls 
interfaces. 


If a global EXP classifier is configured, MPLS traffic on family mpls interfaces uses the EXP classifier. If a 
global EXP classifier is not configured, then if a fixed classifier is applied to the interface, the MPLS traffic 
uses the fixed classifier. If no EXP classifier and no fixed classifier is applied to the interface, MPLS traffic 
is treated as best-effort traffic. DSCP classifiers are not applied to MPLS traffic. 


To configure an MPLS EXP classifier using the CLI: 
1. Create an EXP classifier and associate it with a forwarding class, a loss priority, and a code point: 


[edit class-of-service classifiers] 
user@switch# set (dscp | ieee-802.1 | exp) classifier-name forwarding-class forwarding-class-name 


loss-priority level code-points [aliases] [bit-patterns] 


2. Apply the EXP classifier to the switch interfaces: 


[edit class-of-service] 


user@switch# set system-defaults classifiers exp classifier-name 
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Introduction to GMPLS 


Traditional MPLS is designed to carry Layer 3 IP traffic using established IP-based paths and associating 
these paths with arbitrarily assigned labels. These labels can be configured explicitly by a network 
administrator, or can be dynamically assigned by means of a protocol such as LDP or RSVP. 
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GMPLS generalizes MPLS in that it defines labels for switching varying types of Layer 1, Layer 2, or Layer 3 
traffic. GMPLS nodes can have links with one or more of the following switching capabilities: 


e Fiber-switched capable (FSC) 

e Lambda-switched capable (LSC) 

e Time-division multiplexing (TDM) switched-capable (TSC) 
e Packet-switched capable (PSC) 


Label-switched paths (LSPs) must start and end on links with the same switching capability. For example, 
routers can establish packet-switched LSPs with other routers. The LSPs might be carried over a 
TDM-switched LSP between SONET add/drop multiplexers (ADMs), which in turn might be carried over 
a lambda-switched LSP. 


The result of this extension of the MPLS protocol is an expansion in the number of devices that can 
participate in label switching. Lower-layer devices, such as OXCs and SONET ADMs, can now participate 
in GMPLS signaling and set up paths to transfer data. A router can participate in signaling optical paths 
across a transport network. 


Two service models determine the visibility that a client node (a router, for example) has into the optical 
core or transport network. The first is through a user-to-network interface (UNI), which is often referred 
to as the overlay model. The second is known as the peer model. Juniper Networks supports both models. 


NOTE: There is not necessarily a one-to-one correspondence between a physical interface and 
a GMPLS interface. If aGMPLS connection uses a nonchannelized physical connector, the GMPLS 
label can use the physical port ID. However, the label for channelized interfaces often is based 
ona channel or time slot. Consequently, it is best to refer to GMPLS labels as identifiers for a 
resource on a traffic engineering link. 


To establish LSPs, GMPLS uses the following mechanisms: 


e An out-of-band control channel and a data channel—RSVP messages for LSP setup are sent over an 
out-of-band control network. Once the LSP setup is complete and the path is provisioned, the data 
channel is up and can be used to carry traffic. The Link Management Protocol (LMP) is used to define 
and manage the data channels between a pair of nodes. You can optionally use LMP to establish and 
maintain LMP control channels between peers running the same Junos OS Release. 


RSVP-TE extensions for GMPLS—RSVP-TE is already designed to signal the setup of packet LSPs. This 
has been extended for GMPLS to be able to request path setup for various kinds of LSPs (nonpacket) 
and request labels like wavelengths, time slots, and fibers as label objects. 


Bidirectional LSPs—Data can travel both ways between GMPLS devices over a single path, so nonpacket 
LSPs are signaled to be bidirectional. 


T 
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GMBPLS Terms and Acronyms 


Forwarding adjacency 


Generalized MPLS 
(GMPLS) 


GMPLS label 


GMPLS LSP types 


Link Management 


Protocol 


Traffic engineering link 


GMPLS Operation 


A forwarding path for sending data between GMPLS-enabled devices. 


An extension to MPLS that allows data from multiple layers to be switched over label-switched paths 


(LSPs). GMPLS LSP connections are possible between similar Layer 1, Layer 2, and Layer 3 devices. 


Layer 3 identifiers, fiber port, time-division multiplexing (TDM) time slot, or dense wavelength-division 


multiplexing (DWDM) wavelength of a GMPLS-enabled device used as a next-hop identifier. 


The four types of GMPLS LSPs are: 


e Fiber-switched capable (FSC)—LSPs are switched between two fiber-based devices, such optical 


cross-connects (OXCs) that operate at the level of individual fibers. 


e@ Lambda-switched capable (LSC)—LSPs are switched between two DWDM devices, such as such as 


OXCs that operate at the level of individual wavelengths. 
e TDM-switched capable (TDM)—LSPs are switched between two TDM devices, such as SONET ADMs. 


e Packet-switched capable (PSC)—LSPs are switched between two packet-based devices, such as routers 


or ATM switches. 


A protocol used to define a forwarding adjacency between peers and to maintain and allocate resources 


on the traffic engineering links. 


A logical connection between GMPLS-enabled devices. Traffic engineering links can have addresses or 
IDs and are associated with certain resources or interfaces. They also have certain attributes 
(encoding-type, switching capability, bandwidth, and so on). The logical addresses can be routable, 
although this is not required because they are acting as link identifiers. Each traffic engineering link 


represents a forwarding adjacency between a pair of devices. 


The basic functionality of GMPLS requires close interaction between RSVP and LMP. It works in the 


following sequence: 


1. LMP notifies RSVP of the new entities: 


e Traffic engineering link (forwarding adjacency) 
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e Resources available for the traffic engineering link 


e Control peer 


2. GMPLS extracts the LSP attributes from the configuration and requests RSVP to signal one or more 
specific paths, which are specified by the traffic engineering link addresses. 


3. RSVP determines the local traffic engineering link, corresponding control adjacency and active control 
channel, and transmission parameters (such as IP destination). It requests that LMP allocate a resource 
from the traffic engineering link with the specified attributes. If LMP finds a resource matching the 
attributes, label allocation succeeds. RSVP sends a PathMsg hop by hop until it reaches the target 
router. 


4. When the target router receives the PathMsg, RSVP again requests that LMP allocate a resource based 
on the signaled parameters. If label allocation succeeds, the router sends back a ResvMsg. 


5. If the signaling is successful, a bidirectional optical path is provisioned. 


GMPLS and OSPF 


You can configure OSPF for GMPLS. OSPF is an interior gateway protocol (IGP) that routes packets within 
a single autonomous system (AS). OSPF uses link-state information to make routing decisions. 


GMPLS and CSPF 


GMPLS introduces extra constraints for computing paths for GMPLS LSPs that use CSPF. These additional 
constraints affect the following link attributes: 


e Signal type (minimum LSP bandwidth) 
e Encoding type 
e Switching type 


These new constraints are populated in the traffic engineering database with the exchange of an 
interface-switching capability descriptor type, length, value (TLV) through an IGP. 


The ignored constraints that are exchanged through the interface switching capability descriptor include: 


e Maximum LSP bandwidth 


e Maximum transmission unit (MTU) 


The CSPF path computation is the same as in non-GMPLS environments, except that the links are also 
limited by GMPLS constraints. 


Each link can have multiple interface-switching capability descriptors. All the descriptors are checked 
before a link is rejected. 
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The constraints are checked in the following order: 


1. 


The signal type configured for the GMPLS LSP signifies the amount of bandwidth requested. If the 
desired bandwidth is less than the minimum LSP bandwidth, the interface-switching descriptor is 
rejected. 


. The encoding type of the link for the ingress and the egress interfaces should match. The encoding 


type is selected and stored at the ingress node after all the constraints are satisfied by the link and is 
used to select the link on the egress node. 


. The switching type of the links of the intermediate switches should match that of the GMPLS LSP 


specified in the configuration. 


GMPLS Features 


The Junos OS includes the following GMPLS functionality: 


An out-of-band control plane makes it possible to signal LSP path setup. 


RSVP-TE extensions support additional objects beyond Layer 3 packets, such as ports, time slots, and 
wavelengths. 


The LMP protocol creates and maintains a database of traffic engineering links and peer information. 
Only the static version of this protocol is supported in the Junos OS. You can optionally configure LMP 
to establish and maintain LMP control channels between peers running the same Junos OS Release. 


Bidirectional LSPs are required between devices. 


Several GMPLS label types that are defined in RFC 3471, Generalized 

MPLS-—Signaling Functional Description, such as MPLS, Generalized, SONET/SDH, Suggested, and Upstream, 
are supported. Generalized labels do not contain a type field, because the nodes should know from the 
context of their connection what type of label to expect. 


Traffic parameters facilitate GMPLS bandwidth encoding and SONET/SDH formatting. 


Other supported attributes include interface identification and errored interface identification, 
user-to-network (UNI)-style signaling, and secondary LSP paths. 


Configuring MPLS Paths for GMPLS 


As part of the configuration for GMPLS, you need to establish an MPLS path for each unique device 


connected through GMPLS. Configure the traffic engineering link remote address as the address at the 
[edit protocols mpls path path-name] hierarchy level. Constrained Shortest Path First (CSPF) is supported 


so you can choose either the strict or loose option with the address. 


See LMP Configuration Overview for information about how to obtain a traffic engineering link remote 


address. 
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To configure the MPLS path, include the path statement at the [edit protocols mpls] hierarchy level: 


[edit protocols mpls] 
path path-name { 
next-hop-address (strict | loose); 


For information about how to configure MPLS paths, see “Creating Named Paths” on page 488. 


Tracing LMP Traffic 


To trace LMP protocol traffic, include the traceoptions statement at the [edit protocols link-management] 
hierarchy level: 


[edit protocols link-management] 

traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag <flag-modifier> <disable>; 


Use the file statement to specify the name of the file that receives the output of the tracing operation. All 
files are placed in the directory /var/log. 


The following trace flags display the operations associated with the sending and receiving of various LMP 
messages: 


e all—Trace all available operations 


e hello-packets—Trace hello packets on any LMP control channel 


init—Output from the initialization messages 


packets—Trace all packets other than hello packets on any LMP control channel 


parse—Operation of the parser 


process—Operation of the general configuration 


route-socket—Operation of route socket events 


routing—Operation of the routing protocols 


server—Server processing operations 
e show—Servicing operations for show commands 


e state—Trace state transitions of the LMP control channels and traffic engineering links 


Each flag can carry one or more of the following flag modifiers: 


e detail—Provide detailed trace information 
e receive—Packets being received 


e send—Packets being transmitted 


Configuring MPLS LSPs for GMPLS 
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To enable the proper GMPLS switching parameters, configure the label-switched path (LSP) attributes 
that are appropriate for your network connection. The default value for switching-type is psc-1, which is 
also appropriate for standard MPLS. 


To configure the LSP attributes, include the Isp-attributes statement at the [edit protocols mpls 
label-switched-path Isp-name] hierarchy level: 


[edit protocols mpls label-switched-path Isp-name] 
Isp-attributes { 

encoding-type type; 

gpid gpid; 

signal-bandwidth type; 

switching-type type; 


If you include the no-cspf statement in the label-switched path configuration, you must also configure 
primary and secondary paths, or the configuration cannot be committed. 


The following sections describe how to configure each of the LSP attributes for a GMPLS LSP: 


Configuring the Encoding Type 
You need to specify the encoding type of the payload carried by the LSP. It can be any of the following: 
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e ethernet—Ethernet 

e packet—Packet 

e pdh—Plesiochronous digital hierarchy (PDH) 
e sonet-sdh—SONET/SDH 


The default value is packet. 


To configure the encoding type, include the encoding-type statement at the [edit protocols mpls 
label-switched-path Isp-name Isp-attributes] hierarchy level: 


[edit protocols mpls label-switched-path Isp-name Isp-attributes] 
encoding-type type; 


Configuring the GPID 


You need to specify the type of payload carried by the LSP. The payload is the type of packet underneath 
the MPLS label. The payload is specified by the generalized payload identifier (GPID). 


You can specify the GPID with any of the following values: 


e hdic—High-Level Data Link Control (HDLC) 

e ethernet—Ethernet 

e ipv4—IP version 4 (default) 

e pos-scrambling-crc-16—For interoperability with other vendors’ equipment 

e pos-no-scrambling-crc-16—For interoperability with other vendors’ equipment 
e pos-scrambling-crc-32—For interoperability with other vendors’ equipment 

e pos-no-scrambling-crc-32—For interoperability with other vendors’ equipment 


e ppp—Point-to-Point Protocol (PPP) 


To configure the GPID, include the gpid statement at the [edit protocols mpls label-switched-path Isp-name 
Isp-attributes] hierarchy level: 


[edit protocols mpls label-switched-path Isp-name Isp-attributes] 
gpid gpid; 


Configuring the Signal Bandwidth Type 


The signal bandwidth type is the encoding used for path computation and admission control. To configure 
the signal bandwidth type, include the signal-bandwidth statement at the [edit protocols mpls 
label-switched-path Isp-name Isp-attributes] hierarchy level: 
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[edit protocols mpls label-switched-path Isp-name Isp-attributes] 
signal-bandwidth type; 


Configuring GMPLS Bidirectional LSPs 


Because MPLS and GMPLS use the same configuration hierarchy for LSPs, it is helpful to know which LSP 
attributes control LSP functionality. Standard MPLS packet-switched LSPs are unidirectional, whereas 
GMPLS nonpacket LSPs are bidirectional. 


If you use the default packet-switching type of psc-1, your LSP becomes unidirectional. To enable aGMPLS 
bidirectional LSP, you must select a non-packet-switching type option, such as lambda, fiber, or ethernet. 
Include the switching-type statement at the [edit protocols mpls label-switched-path Isp-name 
Isp-attributes] hierarchy level: 


[edit protocols mpls label-switched-path Isp-name Isp-attributes] 
switching-type (lambda | fiber | ethernet); 


Allowing Nonpacket GMPLS LSPs to Establish Paths Through Routers Running Junos OS 


By setting the A-bit in the Admin Status object. you can enable nonpacket GMPLS LSPs to establish paths 
through routers that run Junos. When an ingress router sends an RSVP PATH message with the Admin 
Status A-bit set, an external device (not a router running the Junos OS) can either perform a Layer 1 path 
setup test or help bring up an optical cross-connect. 


When set, the A-bit in the Admin Status object indicates the administrative down status for a GMPLS LSP. 
This feature is used specifically by nonpacket GMPLS LSPs. It does not affect control path setup or data 
forwarding for packet LSPs. 


Junos does not distinguish between the control path setup and data path setup. Other nodes along the 
network path use RSVP PATH signaling using the A-bit in a meaningful way. 


To configure the Admin Status object for a GMPLS LSP, include the admin-down statement: 


admin-down; 


You can include this statement at the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name] 


e [edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name] 
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Gracefully Tearing Down GMPLS LSPs 
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You can gracefully tear down nonpacket GMPLS LSPs. An LSP that is torn down abruptly, a common 
process in a packet-switched network, can cause stability problems in nonpacket-switched networks. To 
maintain the stability of nonpacket-switched networks, it might be necessary to tear down LSPs gracefully. 


The following sections describe how to tear down GMPLS LSPs gracefully: 
Temporarily Deleting GMPLS LSPs 


You can gracefully tear down a GMPLS LSP using the clear rsvp session gracefully command. 


This command gracefully tears down an RSVP session for a nonpacket LSP in two passes. In the first pass, 
the Admin Status object is signaled along the path to the endpoint of the LSP. During the second pass, the 
LSP is taken down. Using this command, the LSP is taken down temporarily. After the appropriate interval, 
the GMPLS LSP is resignaled and then reestablished. 


The clear rsvp session gracefully command has the following properties: 


e It only works on the ingress and egress routers of an RSVP session. If used on a transit router, it has the 
same behavior as the clear rsvp session command. 


e It only works for nonpacket LSPs. If used with packet LSPs, it has the same behavior as the clear rsvp 
session command. 


For more information, see the CLI Explorer. 


Permanently Deleting GMPLS LSPs 


When you disable an LSP in the configuration, the LSP is permanently deleted. By configuring the disable 
statement, you can disable a GMPLS LSP permanently. If the LSP being disabled is a nonpacket LSP, then 
the graceful LSP tear-down procedures that use the Admin Status object are used. If the LSP being disabled 
is a packet LSP, then the regular signaling procedures for LSP deletion are used. 


To disable a GMPLS LSP, include the disable statement at any of the following hierarchy levels: 


e [edit protocols mpls label-switched-path Isp-name]—Disable the LSP. 


e [edit protocols link-management te-link te-link-name]—Disable a traffic engineering link. 
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e [edit protocols link-management te-link te-link-name interface interface-name]—Disable an interface 
used by a traffic engineering link. 


Configuring the Graceful Deletion Timeout Interval 


The router that initiates the graceful deletion procedure for an RSVP session waits for the graceful deletion 
timeout interval to ensure that all routers along the path (especially the ingress and egress routers) have 
prepared for the LSP to be taken down. 


The ingress router initiates the graceful deletion procedure by sending the Admin Status object in the path 
message with the D bit set. The ingress router expects to receive an Resv message with the D bit set from 
the egress router. If the ingress router does not receive this message within the time specified by the 

graceful deletion timeout interval, it initiates a forced tear-down of the LSP by sending a PathTear message. 


To configure the graceful deletion timeout interval, include the graceful-deletion-timeout statement at 
the [edit protocols rsvp] hierarchy level. You can configure a time between 1 through 300 seconds. The 
default value is 30 seconds. 


graceful-deletion-timeout seconds; 


You can configure this statement at the following hierarchy levels: 


e [edit protocols rsvp] 


e [edit logical-systems logical-system-name protocols rsvp] 


You can use the show rsvp version command to determine the current value configured for the graceful 


deletion timeout. 
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Understanding GMPLS RSVP-TE Signaling 


Signaling is the process of exchanging messages within the control plane to set up, maintain, modify, and 
terminate data paths (label-switched paths (LSPs)) in the data plane. Generalized MPLS (GMPLS) is a 
protocol suite that extends the existing control plane of MPLS to manage further classes of interfaces and 
to support other forms of label switching, such as time-division multiplexing (TDM), fiber (port), Lambda, 
and so on. 


GMPLS extends intelligent IP/MPLS connections from Layer 2 and Layer 3 all the way to Layer 1 optical 
devices. Unlike MPLS, which is supported mainly by routers and switches, GMPLS can also be supported 
by optical platforms, including SONET/SDH, optical cross-connects (OXCs), and dense wave division 
multiplexing (DWDM). 


In addition to labels, which are primarily used to forward data in MPLS, other physical entries, such as 
wavelengths, time slots, and fibers can be used as label objects to forward data in GMPLS, thereby leveraging 
the existing control plane mechanisms to signal different kinds of LSPs. GMPLS uses RSVP-TE to be able 
to request the other label objects to signal the various kinds of LSPs (nonpacket). Bidirectional LSPs and 
an out-of-band control channel and a data channel using the Link Management Protocol (LMP) are the 
other mechanisms that are used by GMPLS to establish LSPs. 


Need for GMPLS RSVP-TE VLAN LSP Signaling 


The traditional Layer 2 point-to-point services use Layer 2 circuits and Layer 2 VPN technologies that are 
based on LDP and BGP. In the traditional deployment, the customer edge (CE) devices do not participate 
in the signaling of the Layer 2 service. The provider edge (PE) devices manage and provision the Layer 2 
service to provide end-to-end connectivity between the CE devices. 


One of the biggest challenges of having the PE devices provision the Layer 2 services for each Layer 2 
circuit between a pair of CE devices is the network management burden on the provider network. 


Figure 99 on page 1270 illustrates how the Layer 2 service is set up and used by the CE routers ina 
LDP/BGP-based Layer 2 VPN technology. Two CE routers CE1 and CE2 are connected to a provider MPLS 
network through the PE routers PE1 and PE2 respectively. The CE routers are connected to the PE routers 
by Ethernet links. Routers CE1 and CE2 are configured with VLAN1 and VLAN2 logical Layer 3 interfaces, 
so they appear to be directly connected. Routers PE1 and PE2 are configured with Layer 2 circuit 
(pseudowire) to carry the Layer 2 VLAN traffic between the CE routers. The PE routers use packet MPLS 
LSPs within the provider MPLS network to carry the Layer 2 VLAN traffic. 
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Figure 99: Traditional Layer 2 Point-to-Point Services 
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With the introduction of GMPLS-based VLAN LSP signaling, the need for the PE (also called server-layer) 
network to provision each individual Layer 2 connection between the CE (also called client) devices is 
minimized. The client router requests the server-layer router to which it is directly connected, for setting 
up the Layer 2 service to connect with a remote client router through GMPLS signaling. 


The server-layer devices extend the signaling through the server-layer network to connect with the remote 
client routers. In the process, the server-layer device sets up the data plane for the Layer 2 service at the 
server-client border, and sets up the data plane for carrying the Layer 2 traffic within the server-layer 
network. With the Layer 2 service setup, the client routers can run IP/MPLS directly on top of the Layer 
2 service and have IP/MPLS adjacency with each other. 


In addition to reducing the provisioning activity needed on the server-layer devices, GMPLS signaling also 
provides the client routers with the flexibility of bringing up the Layer 2 circuits on an on-demand basis 
without depending on the server-layer administration for the provisioning of the Layer 2 service. 


Using the same topology as in Figure 1, Figure 100 on page 1270 illustrates how the Layer 2 service is set 
up and used by the client routers in GMPL RSVP-TE-based Layer 2 VPN technology. 


Figure 100: GMPLS RSVP-TE VLAN LSP 
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In Figure 100 on page 1270, instead of configuring a pseudowire to carry the Layer 2 VLAN traffic between 
the client routers, Routers PE1 and PE2 are configured with an IP-based communication channel and other 
GMPLS-specific configurations (identification of Ethernet links as TE-links) for allowing the exchange of 
GMPLS RSVP-TE signaling messages with the client routers. Routers CE1 and CE2 are also configured 
with an IP-based communication channel and relevant GMPLS configuration for exchanging the GMPLS 
RSVP-TE signaling messages with the server-layer routers. Routers CE1 and CE2 establish an IP/MPLS 
adjacency on top of this Layer 2 service. 
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GMPLS RSVP-TE VLAN LSP Signaling Functionality 


Based on Figure 100 on page 1270, the client router establishes the Layer 2 service in the server-layer 
network as follows: 


1. Router CE1 initiates GMPLS RSVP-TE signaling with Router PE1. In this signaling message, Router CE1 
indicates the VLAN on the Ethernet link for which it needs the Layer 2 service and the remote CE 
router, Router CE2, with which the VLAN should be connected. 


Router CE1 also indicates the remote PE router, Router PE2, to which Router CE2 is connected, and 
the exact Ethernet link connecting Router CE2 to Router PE2 on which the Layer 2 service is required 
in the signaling message. 


2. Router PE1 uses the information from Router CE1 in the signaling message and determines the remote 
PE router, Router PE2, with which Router CE2 is attached. Router PE1 then establishes a packet MPLS 
LSP (associated bidirectional) through the server-layer MPLS network for carrying the VLAN traffic 
and then passes the GMPLS RSVP-TE signaling message to Router PE2 using the LSP hierarchy 
mechanism. 


3. Router PE2 propagates the GMPLS RSVP-TE signaling message to Router CE2 with the VLAN to be 
used on the PE2-CE2 Ethernet link. 


4. Router CE2 responds with an acknowledgment to the GMPLS RSVP-TE signaling message to Router 
PE2. Router PE2 then propagates it to Router PE1, which in turn propagates it to Router CE1. 


5. As part of this message propagation, Routers PE1 and PE2 set up the forwarding plane to enable 
bidirectional flow of VLAN Layer 2 traffic between Routers CE1 and CE2. 


LSP Hierarchy with GMPLS RSVP-TE VLAN LSP 


The Layer 2 service in GMPLS RSVP-TE VLAN LSP signaling is brought up using a hierarchy mechanism 
in which two different RSVP LSPs are created for the Layer 2 service: 


e An end-to-end VLAN LSP that has state information at the client and server-layer routers. 


e An associated bidirectional packet transport LSP that is present in the server-layer routers (PE and P) 
of the server-layer network. 


The LSP hierarchy avoids sharing information about technology-specific LSP characteristics with the core 
nodes of the server-layer network. This solution cleanly separates the VLAN LSP state and the transport 
LSP state, and ensures that the VLAN LSP state is only present on the nodes (PE, CE) where it is needed. 


Path Specification for GMPLS RSVP-TE VLAN LSP 


The path for the GMPLS RSVP-TE LSP is configured as an Explicit Route Object (ERO) at the initiating 
client router. As this LSP traverses different network domains (initiating, terminating at client network, 
and traversing the server-layer network), the LSP setup falls under the category of an interdomain LSP 
setup. In an interdomain scenario, one network domain generally does not have full visibility into the 


topology of the other network domain. Hence, the ERO that gets configured at the initiating client router 
does not have full hop information for the server-layer portion. This feature requires that the ERO configured 
at the CE router has three hops, with the first hop being a strict hop identifying the CE1-PE1 Ethernet 
link, the second hop being a loose hop identifying the egress PE router (PE2), and the third hop being a 
strict hop identifying the CE2-PE2 Ethernet link. 


GMPLS RSVP-TE VLAN LSP Configuration 


The configuration required to set up a GMPLS VLAN LSP at the client and server routers uses the existing 
GMPLS configuration model with some extensions. The Junos OS GMPLS configuration model for nonpacket 
LSPs is targeted toward bringing the physical interfaces up and running through GMPLS RSVP-TE signaling, 
whereas signaling a GMPLS RSVP-TE VLAN LSP aims at bringing up individual VLANs on top of a physical 
interface. The ethernet-vlan configuration statement under the [edit protocols link-management te-link] 
hierarchy enables this. 


The client router has physical interfaces connected to a server network, and the server network provides 
a point-to-point connection between two client routers over the attached physical interfaces. The physical 
interface is brought into an operational state by GMPLS RSVP-TE as follows: 


1. The client router maintains a routing or signaling adjacency with the server network node to which the 
physical interface is connected, typically through a control channel different from the physical interface, 
because the physical interface itself is brought up and running only after the signaling. 


2. The client router and the server network node identify the physical interfaces connecting them using 
the TE-link mechanism. 


3. The client router and the server network node use the TE-link identifier (IP address) as the GMPLS 
RSVP hop and the physical interface identifier as the GMPLS label values in the GMPLS RSVP-TE 
signaling messages to bring the physical interface into an operational state. 


In the existing GMPLS configuration, the server and client network nodes use the protocols 
link-management peer peer-name configuration statement to specify the adjacent peer node. Because a 
client router can have one or more physical interfaces connected to the server network node, these physical 
interfaces are grouped and identified by an IP address through the protocols link-management te-link 
link-name configuration statement. The TE-link is assigned a local IP address, a remote IP address, anda 
list of physical interfaces. The TE-link is then associated with the protocols link-management peer peer-name 
te-link te-link-list configuration statement. 


The out-of-band control channel that is required for exchanging signaling messages is specified using the 
protocols link-management peer peer-name control-channel interface-name configuration statement. The 
existence of the server or client network node is made visible to the RSVP and IGP (OSPF) protocols 
through the peer-interface interface-name configuration statement under the [edit protocols rsvp] and 
[edit protocols ospf] hierarchy levels. 


In the existing GMPLS configuration, the label (upstream label and resv label) that is carried in the signaling 
message is an integer identifier that identifies the physical interface that is required to be brought up. As 
the label is used to identify the physical interface, the existing GMPLS configuration allows multiple 
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interfaces to be grouped under a single TE-link. In the existing GMPLS configuration, there is sufficient 
information in the GMPLS RSVP-TE signaling message, such as TE-link address and label value, to identify 
the physical interface that is required to be brought up. In contrast, for GMPLS RSVP-TE VLAN LSP 
configuration, the VLAN ID value is used as the label in the signaling message. 


In the GMPLS RSVP-TE VLAN LSP configuration, if multiple interfaces are allowed to be configured under 
a single TE-link, using VLAN ID as the label value in the signaling message can cause ambiguity as to which 
physical interface on which the VLAN has to be provisioned. Therefore, the TE-link is configured with the 
ethernet-vlan configuration statement, if the number of physical interfaces that can be configured under 
the TE-link is restricted to only one. 


In the existing GMPLS configuration, the bandwidth for a nonpacket LSP is a discrete quantity that 
corresponds to the bandwidth of the physical interface that needs to be brought up. So, the GMPLS LSP 
configuration does not allow any bandwidth to be specified, but allows the bandwidth to be specified only 
through the signal-bandwidth configuration statement under the [protocols mpls label-switched-path 
Isp-name I|sp-attributes] hierarchy level. In the GMPLS VLAN LSP configuration, bandwidth is specified 
similar to that of a packet LSP. In the GMPLS VLAN LSP configuration, the bandwidth option is supported 
and signal-bandwidth is not supported. 


Associated Bidirectional Packet LSP 


The GMPLS RSVP-TE VLAN LSP is carried on an associated bidirectional transport LSP within the 
server-layer network, which is a single-sided provisioned LSP. The transport LSP signaling is initiated as a 
unidirectional LSP from the source router to the destination router in the forward direction, and the 
destination router in turn initiates the signaling of the unidirectional LSP in the reverse direction back to 
the source router. 


Make-Before-Break for Associated Bidirectional Packet and GMPLS RSVP-TE VLAN LSP 


The make-before-break support for an associated bidirectional transport LSP follows a similar model, 
where the destination router for the forward direction of the bidirectional LSP does not perform any 
make-before-break operations on the reverse direction of the bidirectional LSP. It is the source router 
(initiator of the associated bidirectional LSP) that initiates the make-before-break newer instance of the 
associated bidirectional LSP, and the destination router in turn initiates the make-before-break newer 
instance in the other direction. 


For instance, in Figure 100 on page 1270, the unidirectional transport LSP is initiated from Router PE1 to 
Router PE2 in the forwarding direction, and in turn Router PE2 initiates the transport LSP to Router PE1 
in the reverse direction. When a make-before-break instance occurs, only Router PE1 as the initiating 
client router can establish a new instance of the associated bidirectional LSP. Router PE2 in turn initiates 
the make-before-break newer instance in the reverse direction. 


The make-before-break support for the associated bidirectional transport LSP is used only in scenarios 
where the transport LSP gets into a state of being locally protected due to link or node failure on the path 
of the LSP. The GMPLS RSVP-TE VLAN LSP uses the make-before-break mechanism for adjusting seamless 
bandwidth changes. 
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NOTE: Periodic re-optimization is not enabled for the associated bidirectional transport LSPs. 


The newer make-before-break instance of the GMPLS VLAN LSP is supported under the following 
constraints: 


e It should originate from the same client router as the older instance and be destined to the same client 
router as the older instance. 


e It should use the same server-client links at both the server-client ends as the older instance. 
e It should use the same VLAN label at the server-client links as the older instance. 


e The GMPLS VLAN LSP should be configured as adaptive when the bandwidth change is initiated from 
the CLI, or else the current instance of the VLAN LSP is torn down and a new VLAN LSP instance is 
established. 


The make-before-break operation for the GMPLS VLAN LSP on the server-layer edge router is rejected 
if these constraints are not met. 


On the server-layer edge routers, when a make-before-break instance of the GMPLS VLAN LSP is seen, 
a completely new, separate associated bidirectional transport LSP is created to support this 
make-before-break instance. The existing associated bidirectional LSP (supporting the older instance) is 
not triggered to initiate a make-before-break instance at the transport LSP level. An implication of this 
choice (of initiating a new transport LSP) is that at the server-layer resource/bandwidth sharing does not 
happen when a make-before-break operation is performed for the GMPLS VLAN LSP. 


Supported and Unsupported Features 
Junos OS supports the following features with the GMPLS RSVP-TE VLAN LSP: 


e Request for specific bandwidth and local protection for the VLAN LSP on the client router to the 
server-layer router. 


e Nonstop active routing (NSR) support for the GMPLS VLAN LSP at the client routers, server-layer edge 
routers, and associated bidirectional transport LSP at the server-layer edge routers. 


e Multichassis support. 
Junos OS does not support the following GMPLS RSVP-TE VLAN LSP functionality: 


e Graceful restart support for associated bidirectional packet LSP and GMPLS VLAN LSP. 
e End-to-end path computation for GMPLS VLAN LSP using CSPF algorithm at the client router. 
e Non-CSPF routing-based discovery of next-hop routers by the different client, server-layer edge routers. 


e Automatic provisioning of the client Layer 3 VLAN interfaces upon the successful setup of the VLAN 
LSP at the client routers. 


e MPLS OAM (LSP-ping, BFD). 
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e Packet MPLS applications, such as next-hop in static route and in IGP shortcuts. 


e Local cross connect mechanism, where a client router connects to a remote client router which is 
connected to the same server router. 


e Junos OS Services Framework. 
e IPvé support. 
e Logical systems. 


e Aggregated Ethernet/SONET/IRB interfaces at the server-client link. 


Example: Configuring GMPLS RSVP-TE VLAN LSP Signaling 
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This example shows how to configure GMPLS RSVP-TE VLAN LSP signaling on the client routers to enable 
one client router to connect with a remote client router through a server-layer network using the LSP 
hierarchy. This enables the client routers to establish, maintain, and provision the Layer 2 services, without 
depending on the server-layer administration, thereby reducing the burden on the operational expenses 
of the provider network. 


Requirements 


This example uses the following hardware and software components: 


e Six routers that can be a combination of M Series Multiservice Edge Routers, MX Series 5G Universal 
Routing Platforms, T Series Core Routers, and PTX Series Packet Transport Routers 


e Junos OS Release 14.2 or later running on the client routers and server-layer edge routers 
Before you begin: 

1. Configure the device interfaces. 

2. Configure the interface-associated VLANs. 


3. Configure the following routing protocols: 


e RSVP 
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e MPLS 
e LMP 


Overview 


Starting with Junos OS Release 14.2, the Layer 2 services between two client routers across an 
external/third-party server-layer network are set up by the client routers on an on-demand basis through 
GMPLS RSVP-TE signaling. This feature provides the client routers the flexibility to establish, maintain, 
and provision the Layer 2 services, without depending on the server-layer administration, thereby reducing 
the burden on the operational expenses of the provider network. In traditional Layer 2 VPN technology 
based on LDP and BGP, the provider network handled the provisioning activity for each Layer 2 circuit 
established between two client routers. 


Figure 101 on page 1276 illustrates the setting up and signaling of the GMPLS VLAN LSP between two client 
routers, CE1 and CE2, across a server-layer network with two server-layer edge routers, PE1 and PE2, 
and one server-layer core router, P. 


Figure 101: Setting Up a GMPLS VLAN LSP 
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The signaling of GMPLS VLAN LSP is executed as follows: 


1. Initiating GMPLS VLAN LSP at CE1 


Router CE1 initiates the GMPLS VLAN LSP setup by sending the GMPLS RSVP-TE path message to 
Router PE1. The signaling between CE1 and PE11 is over an out-of-band control channel, which is a 
separate control VLAN configured on the Ethernet link connecting the two routers. 


The GMPLS RSVP-TE path message initiated by Router CE1 is used to perform the following: 


a. Identify the Ethernet link on which the VLAN is active. 


b. Abstract the Ethernet link as a TE-link and assign an IP address to identify the Ethernet link. 


c. Allocate a VLAN ID from the pool of free VLANs managed by Router CE1 for every Ethernet link 
connecting Router PE1 to the identified Ethernet link. 


This VLAN ID can also be used for the GMPLS VLAN LSP at the CE2-PE2 Ethernet link. 


d. Identify the VLAN for which the Layer 2 service is required to be set up using the allocated VLAN 
ID as the upstream label object and the upstream direction label value. 


e. Include an ERO object that helps Router PE1 in establishing the VLAN LSP through the server-layer 
network to the remote client router, CE2. The ERO object in the path message includes three hops: 


e First hop—Strict hop identifying the initiating client-server Ethernet link, PE1-CE1. 

e Second hop—Loose hop identifying the remote server-layer router, PE2. 

e Third hop—Strict hop identifying the remote clinet-server Ethernet link, PE2-CE2. 
f. Include the bandwidth required for the GMPLS VLAN LSP. 


g. Include any local-protection required within the server-layer network for the VLAN LSP. 


. Initiating Associated Bidirectional Transport LSP at PE1 


After Router PE1 receives the path message from Router CE1, the message is validated to check the 
availability of the Ethernet link and VLAN ID. In the server-layer network, the Layer 2 services between 
the server-layer routers, PE1 and PE2, are provided at the data plane in a manner similar to Layer 2 
circuits. Router PE1 brings up a transport LSP to Router PE2 and then extends the GMPLS VLAN LSP 
as a hierarchical LSP running on top of the PE1-PE2 transport LSP. The PE1-PE2 transport LSP is a 
packet LSP and is bidirectional in nature. This is because the GMPLS VLAN LSP is bidirectional and 
each server-layer router needs to be able to do the following: 


e Receive traffic from the server-client Ethernet link (for example, the PE1-CE11 link) and send it to the 
remote server-layer router, PE2. 


e Receive traffic from remote Router PE2 and send it on the PE1-CE1 Ethernet link. 


For each GMPLS VLAN LSP, a packet transport LSP is set up within the server-layer network. The 
transport LSP is exclusively used to carry traffic of the GMPLS VLAN LSP for which it was created. The 
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transport LSP is dynamically created at the time of receiving the GMPLS VLAN LSP; thus, no 
configuration is required to trigger its creation. The transport LSP established for the VLAN LSP inherits 
the bandwidth and the local-protection attributes from the VLAN LSP. 


Router PE1 signals the PE1-PE2 transport LSP to Router PE2. Router PE1 determines the destination 
for the transport LSP from the loose hop specified in the ERO object of the GMPLS RSVP-TE path 
message from Router CE1 and then signals the VLAN LSP. However, if the PE1-PE2 transport LSP fails 
to establish, Router PE1 sends back a path error message to Router CE1, and the GMPLS VLAN LSP 
is not established as well. 


3. Setting Up the Associated Bidirectional Transport LSP Between the Server-Layer Routers 


The associated bidirectional LSP between routers PE1 and PE2 consists of two unidirectional packet 
LSPs: 


e PE1-to-PE2 
e PE2-to-PE1 


Router PE1 initiates signaling of a unidirectional packet LSP to Router PE2. This unidirectional packet 
LSP constitutes the forward direction (PE1-to-PE2) of the associated bidirectional LSP, and the path 
message carries the Extended Association Object indicating this is a single-sided provisioning model. 
On receiving the path message for the LSP, Router PE2 responds with a Resv message and triggers the 
signaling of a unidirectional packet LSP to Router PE1 with the same path as (PE1-to-PE2) in the reverse 
direction. This unidirectional packet LSP uses the PE2-to-PE1 direction of the associated bidirectional 
LSP, and this path message carries the same Extended Association Object seen in the PE1-to-PE2 path 
message. 


When Router PE1 receives the Resv message for the PE1-to-PE2 unidirectional LSP and the path 
message for the PE2-to-PE1 unidirectional LSP, PE1 binds the PE1-to-PE2 and PE2-to-PE11 unidirectional 
LSPs by matching the Extended Association Objects carried in the respective path messages. For the 
path message for the PE2-to-PE1 unidirectional LSP, Router PE1 responds with the Resv Message. On 
receiving the Resv message for the PE1-to-PE2 LSP and the path message for the PE2-to-PE1 LSP, 
Router PE1 has established the associated bidirectional packet transport LSP. 


4. Setting Up the GMPLS VLAN LSP at Router PE1 


After successfully establishing the transport LSP, Router PE1 triggers the signaling of the GMPLS VLAN 
LSP. Router PE1 sends the GMPLS RSVP-TE path message corresponding to the VLAN LSP directly to 
Router PE2, which is bidirectional in nature and includes the upstream label object. 


Router PE2 is not aware of the association between the transport LSP and the VLAN LSP. This association 
is indicated to Router PE2 by Router PE1. 


5. Setting Up the GMPLS VLAN LSP at Router PE2 


On receiving the VLAN LSP path message from Router PE1, Router PE2 verifies the availability of the 
transport LSP. If the transport LSP is not available or the LSP setup is in progress, the VLAN LSP 
processing is put on hold. When the transport LSP is available, Router PE2 processes the VLAN LSP 
path message. The ERO object in this path message indicates that the next hop is a strict hop identifying 
the PE2-to-CE2 Ethernet link. The ERO object can indicate the VLAN ID to be used on the PE2-to-CE2 
Ethernet link by Router PE2. 


Router PE2 appropriately allocates the VLAN ID to be sent as the upstream label in the VLAN LSP path 
message to Router CE2, and sends it through an out-of-band control channel. 


. Processing the GMPLS VLAN LSP at Router CE2 


On receiving the GMPLS RSVP-TE LSP from Router PE2, Router CE2 validates the availability of VLAN 
ID for allocation on the PE2-to-CE2 link. Router CE2 then allocates the VLAN ID for this VLAN LSP 
and sends back a Resv message to Router PE2 with the VLAN ID as the label object in the Resv message. 


. Processing the GMPLS VLAN LSP at Router PE2 


On receiving the Resv message from Router CE2, Router PE2 validates that the label object in the Resv 
message has the same VLAN ID as in the path message. Router PE2 then allocates a 20-bit MPLS label, 
which is included in the Resv message sent to Router PE1. 


Router PE2 then programs the forwarding plane with the entries to provide the Layer 2 service 
functionality. 


NOTE: For all the VLAN IDs that can be allocated as labels on the PE1-to-CE1 and PE2-CE2 
Ethernet links, you must manually configure logical interfaces for circuit cross-connect (CCC) 
purposes on the server-layer edge routers and not for other families, such as IPv4, IPv6, or 
MPLS. 


. Processing the GMPLS VLAN LSP at Router PE1 


On receiving the Resv message for the VLAN LSP from Router PE2, Router PE1 sends a Resv message 
to Router CE1 with the same VLAN ID it received as the upstream label from Router CE1. Router PE1 
programs the forwarding plane with the entries to provide the Layer 2 service functionality as Router 
PE2. 


. Processing the GMPLS VLAN LSP at Router CE1 


On receiving the Resv message from Router PE1, Router CE1 validates that the VLAN ID received in 
the Resv message matches the VLAN ID in the upstream label in the path message it sent. This completes 
the setup of the GMPLS VLAN LSP from Router CE1 to Router CE2. 
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NOTE: 

e The GMPLS VLAN LSP setup does not result in the addition of any forwarding plane entries 
at the client routers, CE1 and CE2. Only the server-layer routers, PE1 and PE2, add the 
forwarding plane entries for the GMPLS VLAN LSP. 


e There is no routing information exchange between the client and the server-layer routers. 
The client and server-layer routers do not exchange their network topology information 


with each other. 


10. Accounting for Bandwidth of the GMPLS VLAN LSP 


On successfully setting up the GMPLS VLAN LSP, both the client and server-layer routers reduce the 
amount of available bandwidth on the server-client Ethernet links by the bandwidth amount allocated 
for the GMPLS VLAN LSP. This bandwidth accounting information is used for admission control purposes 
when additional GMPLS VLAN LSPs are brought up on the server-client Ethernet links. 


11. Using GMPLS VLAN LSP by the Client Routers 


After successfully setting up the GMPLS VLAN LSP, the client routers - CE1 and CE2 - need to be 
manually configured with the VLAN logical interface on top of the server-client Ethernet links with the 
signaled VLAN ID. This logical interface needs to be configured with the IP address and needs to be 
included in the IGP protocol. As a result of this configuration, Routers CE1 and CE2 establish IGP 
adjacency and exchange data traffic over the Layer 2 service established through the GMPLS signaling. 


Figure 102 on page 1281 illustrates the data traffic flow of the GMPLS VLAN LSP from Router CE1 to 
Router CE2 after the LSP setup is complete and the necessary CE1-to-CE2 IGP/MPLS adjacency has 
been established. The server-layer transport LSP originates from Router PE1, traverses a single 
server-layer core router, Router P, and reaches Router PE2. The server-layer transport LSP is shown 
as a penultimate-hop pop LSP, where Router P pops off the transport LSP label, and only the service 
label is present on the P-to-PE2 link. 
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Figure 102: Data Traffic Flow of GMPLS VLAN LSP 
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Topology 


In Figure 103 on page 1281, GMPLS RSVP-TE VLAN LSP signaling is used to establish the Layer 2 services 
between the client routers, Router CE1 and Router CE2. The server routers, Router PE1 and Router PE2, 
have a GRE tunnel established with each of the directly connected client routers. Routers P1 and P2 are 
also server routers in the server-layer network. 


Figure 103: Configuring GMPLS RSVP-TE VLAN LSP Signaling 
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Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


CE1 


set interfaces ge-0/0/0 vian-tagging 

set interfaces ge-0/0/0 unit 1 vian-id 1 

set interfaces ge-0/0/0 unit 1 family inet address 1.1.1.1/30 

set interfaces ge-0/0/0 unit 1 family mpls 

set interfaces ge-0/0/0 unit 10 vian-id 10 

set interfaces ge-0/0/0 unit 10 family inet address 10.10.10.1/24 

set interfaces ge-0/0/0 unit 10 family mpls 

set interfaces gre unit O tunnel source 1.1.1.1 

set interfaces gre unit 0 tunnel destination 1.1.1.2 

set interfaces gre unit O family inet address 10.35.100.25/30 

set interfaces loO unit O family inet address 10.255.10.1/32 

set routing-options router-id 10.255.10.1 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols rsvp peer-interface PE1 

set protocols mpls no-cspf 

set protocols mpls label-switched-path CE1-to-CE2 from 10.255.10.1 
set protocols mpls label-switched-path CE1-to-CE2 to 10.255.10.6 
set protocols mpls label-switched-path CE1-to-CE2 Isp-attributes switching-type ethernet-vlan 
set protocols mpls label-switched-path CE1-to-CE2 Isp-attributes upstream-label vian-id 10 
set protocols mpls label-switched-path CE1-to-CE2 bandwidth 100m 
set protocols mpls label-switched-path CE1-to-CE2 primary path1 
set protocols mpls path path1 10.35.1.2 strict 

set protocols mpls path path1 10.255.10.5 loose 

set protocols mpls path path1 10.36.1.1 strict 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols link-management te-link link10 local-address 10.35.1.1 
set protocols link-management te-link link10 remote-address 10.35.1.2 
set protocols link-management te-link link10 ethernet-vlan 

set protocols link-management te-link link10 interface ge-0/0/0 

set protocols link-management peer PE1 address 10.255.10.2 

set protocols link-management peer PE1 control-channel gre.O 

set protocols link-management peer PE1 te-link link10 


PE1 


P1 


set interfaces ge-0/0/0 vilan-tagging 

set interfaces ge-0/0/0 encapsulation flexible-ethernet-services 

set interfaces ge-0/0/0 unit 1 vian-id 1 

set interfaces ge-0/0/0 unit 1 family inet address 1.1.1.2/30 

set interfaces ge-0/0/0 unit 1 family mpls 

set interfaces ge-0/0/0 unit 10 encapsulation vian-ccc 

set interfaces ge-0/0/0 unit 10 vian-id 10 

set interfaces ge-0/0/1 unit 0 family inet address 70.70.70.1/30 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 20.20.20.1/30 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces gre unit O tunnel source 1.1.1.2 

set interfaces gre unit 0 tunnel destination 1.1.1.1 

set interfaces gre unit O family inet address 10.35.100.26/30 

set interfaces loO unit O family inet address 10.255.10.2/32 

set routing-options router-id 10.255.10.2 

set protocols rsvp associated-bidirectional-Isp single-sided-provisioning 
set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols rsvp peer-interface CE1 dynamic-bidirectional-transport 
set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols link-management te-link link1 local-address 10.35.1.2 
set protocols link-management te-link link1 remote-address 10.35.1.1 
set protocols link-management te-link link1 ethernet-vlan vian-id-range 1-1000 
set protocols link-management te-link link1 interface ge-0/0/0 

set protocols link-management peer CE1 address 10.255.10.1 

set protocols link-management peer CE1 control-channel gre.O 

set protocols link-management peer CE1 te-link link1 


set interfaces ge-0/0/0 unit 0 family inet address 90.90.90.1/24 
set interfaces ge-0/0/0 unit 0 family mpls 
set interfaces ge-0/0/1 unit 0 family inet address 70.70.70.2/24 
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P2 


PE2 


set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 80.80.80.2/24 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.10.3/32 
set routing-options router-id 10.255.10.3 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


set interfaces ge-0/0/0 unit 0 family inet address 90.90.90.2/30 
set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 30.30.30.1/30 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 20.20.20.2/30 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.10.4/32 

set routing-options router-id 10.255.10.4 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


set interfaces ge-0/0/0 vian-tagging 

set interfaces ge-0/0/0 encapsulation flexible-ethernet-services 
set interfaces ge-0/0/0 unit 0 vian-id 1 

set interfaces ge-0/0/0 unit 0 family inet address 2.2.2.2/30 
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CE2 


set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/0 unit 10 encapsulation vian-ccc 

set interfaces ge-0/0/0 unit 10 vian-id 10 

set interfaces ge-0/0/1 unit 0 family inet address 30.30.30.2/30 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 80.80.80.1/30 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces gre unit O tunnel source 2.2.2.2 

set interfaces gre unit 0 tunnel destination 2.2.2.1 

set interfaces gre unit O family inet address 10.35.101.26/30 

set interfaces loO unit O family inet address 10.255.10.5/32 

set routing-options router-id 10.255.10.5 

set protocols rsvp associated-bidirectional-Isp single-sided-provisioning 
set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols rsvp peer-interface CE2 dynamic-bidirectional-transport 
set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols link-management te-link link1 local-address 10.36.1.2 
set protocols link-management te-link link1 remote-address 10.36.1.1 
set protocols link-management te-link link1 ethernet-vlan vian-id-range 1-1000 
set protocols link-management te-link link1 interface ge-0/0/0 

set protocols link-management peer CE2 address 10.255.10.6 

set protocols link-management peer CE2 control-channel gre.O 

set protocols link-management peer CE2 te-link link1 


set interfaces ge-0/0/0 vilan-tagging 

set interfaces ge-0/0/0 unit 1 vian-id 1 

set interfaces ge-0/0/0 unit 1 family inet address 2.2.2.1/24 

set interfaces ge-0/0/0 unit 1 family mpls 

set interfaces ge-0/0/0 unit 10 vian-id 10 

set interfaces ge-0/0/0 unit 10 family inet address 10.10.10.2/24 
set interfaces ge-0/0/0 unit 10 family mpls 

set interfaces gre unit O tunnel source 2.2.2.1 

set interfaces gre unit 0 tunnel destination 2.2.2.2 
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set interfaces gre unit O family inet address 10.35.101.25/30 

set interfaces loO unit O family inet address 10.255.10.6/32 

set routing-options router-id 10.255.10.6 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols rsvp peer-interface PE2 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols link-management te-link link10 local-address 10.36.1.1 
set protocols link-management te-link link10 remote-address 10.36.1.2 
set protocols link-management te-link link10 ethernet-vlan vlan-id-range 1-1000 
set protocols link-management te-link link10 interface ge-0/0/0 

set protocols link-management peer PE2 address 10.255.10.5 

set protocols link-management peer PE2 control-channel gre.O 

set protocols link-management peer PE2 te-link link10 


Configuring the Client Router 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Router CE1: 


NOTE: Repeat this procedure for Router CE2 in the server-layer network, after modifying the 
appropriate interface names, addresses, and any other parameters for the router. 


1. Configure the interface connecting Router CE1 to Router PE1. 


[edit interfaces] 
user@CE1# set ge-0/0/0 vian-tagging 


2. Configure the control VLAN for the ge-0/0/0 interface. 


[edit interfaces] 

user@CE1# set ge-0/0/0 unit 1 vlan-id 1 

user@CE1# set ge-0/0/0 unit 1 family inet address 1.1.1.1/30 
user@CE1# set ge-0/0/0 unit 1 family mpls 
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3. Configure the LSP VLAN on the ge-0/0/0 interface. 


[edit interfaces] 

user@CE1# set ge-0/0/0 unit 10 vian-id 10 

user@CE1# set ge-0/0/0 unit 10 family inet address 10.10.10.1/24 
user@CE1# set ge-0/0/0 unit 10 family mpls 


4. Configure the GRE tunnel as the controlling interface for Router CE1. 


[edit interfaces] 

user@CE1# set gre unit O tunnel source 1.1.1.1 

user@CE1# set gre unit O tunnel destination 1.1.1.2 
user@CE1# set gre unit O family inet address 10.35.100.25/30 


5. Configure the loopback interface of Router CE1. 


[edit interfaces] 
user@CE1# set loO unit 0 family inet address 10.255.10.1/32 


6. Configure the loopback address of Router CE1 as its router ID. 


[edit routing-options] 
user@CE1# set router-id 10.255.10.1 


7. Enable RSVP on all the interfaces of Router CE1, excluding the management interface. 


[edit protocols] 
user@CE1# set rsvp interface all 
user@CE1# set rsvp interface fxp0.0 disable 


8. Configure the RSVP peer interface for Router CE1. 


[edit protocols] 
user@CE1# set rsvp peer-interface PE1 


9. Disable automatic path computation for label-switched paths (LSPs). 


[edit protocols] 
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user@CE1# set mpls no-cspf 


10. Configure the LSP to connect Router CE1 to Router CE2. 


[edit protocols] 
user@CE1# set mpls label-switched-path CE1-to-CE2 from 10.255.10.1 
user@CE1# set mpls label-switched-path CE1-to-CE2 to 10.255.10.6 


11. Configure the CE1-to-CE2 LSP attributes. 


[edit protocols] 

user@CE1# set mpls label-switched-path CE1-to-CE2 Isp-attributes switching-type ethernet-vlan 
user@CE1# set mpls label-switched-path CE1-to-CE2 Isp-attributes upstream-label vian-id 10 
user@CE1# set mpls label-switched-path CE1-to-CE2 bandwidth 100m 


12. Configure the CE1-to-CE2 LSP path and path parameters. 


[edit protocols] 

user@CE1# set mpls label-switched-path CE1-to-CE2 primary path1 
user@CE1# set mpls path path1 10.35.1.2 strict 

user@CE1# set mpls path path1 10.255.10.5 loose 

user@CE1# set mpls path path1 10.36.1.1 strict 


13. Enable MPLS on all the interfaces of Router CE1, excluding the management interface. 


[edit protocols] 
user@CE1# set mpls interface all 
user@CE1# set mpls interface fxp0.0 disable 


14. Configure a traffic engineering link, and assign addresses for the local and remote end of the link. 


[edit protocols] 
user@CE1# set link-management te-link link10 local-address 10.35.1.1 
user@CE1# set link-management te-link link10 remote-address 10.35.1.2 


15. Enable setting up of Layer 2 VLAN LSP on the link10 traffic engineering link. 


[edit protocols] 
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user@CE1# set link-management te-link link10 ethernet-vlan 


16. Configure the Router CE1 interface as the member interface of the link10 traffic engineering link. 


[edit protocols] 
user@CE1# set link-management te-link link10 interface ge-0/0/0 


17. Configure Router PE1 as the Link Management Protocol (LMP) peer for Router CE1, and configure the 
peer attributes. 


[edit protocols] 

user@CE1# set link-management peer PE1 address 10.255.10.2 
user@CE1# set link-management peer PE1 control-channel gre.O 
user@CE1# set link-management peer PE1 te-link link10 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 
and show protocols commands. If the output does not display the intended configuration, repeat the 
instructions in this example to correct the configuration. 


user@CE1# show interfaces 
ge-0/0/0 { 
vian-tagging; 
unit 1 { 
vlan-id 1; 
family inet { 
address 1.1.1.1/30; 
} 
family mpls; 
} 
unit 10 { 
vlan-id 10; 
family inet { 
address 10.10.10.1/24; 
} 


family mpls; 


gre { 
unit O { 


tunnel { 
source 1.1.1.1; 
destination 1.1.1.2; 

} 

family inet { 
address 10.35.100.25/30; 


} 
lo0 { 
unit O { 
family inet { 
address 10.255.10.1/32; 


user@CE1# show routing-options 
router-id 10.255.10.1; 


user@CE1# show protocols 
rsvp { 
interface all; 
interface fxp0.0 { 
disable; 
} 
peer-interface PE1; 
} 
mpls { 
no-cspf; 
label-switched-path CE1-to-CE2 { 
from 10.255.10.1; 
to 10.255.10.6; 
Isp-attributes { 
switching-type ethernet-vlan; 
upstream-label { 
vilan-id 10; 


} 
bandwidth 100m; 
primary path1; 

} 

path path1 { 
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10.35.1.2 strict; 
10.255.10.5 loose; 
10.36.1.1 strict; 

} 

interface all; 

interface fxp0.0 { 
disable; 


} 
link-management { 
te-link link10 { 
local-address 10.35.1.1; 
remote-address 10.35.1.2; 
ethernet-vlan; 
interface ge-0/0/0; 
} 
peer PE1 { 
address 10.255.10.2; 
control-channel gre.0; 
te-link link10; 


Configuring the Server Router 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 


information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Router PE1: 


NOTE: Repeat this procedure for Router PE2 in the server-layer network, after modifying the 
appropriate interface names, addresses, and any other parameters for the router. 


1. Configure the interface connecting Router PE1 to Router CE1. 


[edit interfaces] 
user@PE1# set ge-0/0/0 vian-tagging 
user@PE1# set ge-0/0/0 encapsulation flexible-ethernet-services 


2. Configure the control VLAN for the ge-0/0/0 interface. 
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[edit interfaces] 

user@PE1# set ge-0/0/0 unit 1 vlan-id 1 

user@PE1# ge-0/0/0 unit 1 family inet address 1.1.1.2/30 
user@PE1# set ge-0/0/0 unit 1 family mpls 


3. Configure the LSP VLAN on the ge-0/0/0 interface. 


[edit interfaces] 
user@PE1# set ge-0/0/0 unit 10 encapsulation vlan-ccc 
user@PE1# set ge-0/0/0 unit 10 vian-id 10 


4. Configure the interface connecting Router PE1 to the core routers (Router P1 and Router P2). 


[edit interfaces] 

user@PE1# set ge-0/0/1 unit 0 family inet address 70.70.70.1/30 
user@PE1# set ge-0/0/1 unit O family mpls 

user@PE1# set ge-0/0/2 unit 0 family inet address 20.20.20.1/30 
user@PE1# set ge-0/0/2 unit O family mpls 


5. Configure the GRE tunnel as the controlling interface for Router PE1. 


[edit interfaces] 

user@PE1# set gre unit 0 tunnel source 1.1.1.2 

user@PE1# set gre unit O tunnel destination 1.1.1.1 
user@PE1# set gre unit O family inet address 10.35.100.26/30 


6. Configure the loopback interface of Router PE1. 


[edit interfaces] 
user@PE1# set loO unit O family inet address 10.255.10.2/32 


7. Configure the loopback address of Router PE1 as its router ID. 


[edit routing-options] 
user@PE1# set router-id 10.255.10.2 


8. Configure an associated bidirectional LSP, and enable unidirectional reverse LSP setup for single-sided 
provisioned forward LSP. 
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[edit protocols] 
user@PE1# set rsvp associated-bidirectional-Isp single-sided-provisioning 


9. Enable RSVP on all the interfaces of Router PE1, excluding the management interface. 


[edit protocols] 
user@PE1# set rsvp interface all 
user@PE1# set rsvp interface fxp0.0 disable 


10. Configure the RSVP peer interface for Router PE1, and enable dynamic setup of bidirectional packet 
LSP for transporting nonpacket GMPLS LSP. 


[edit protocols] 
user@PE1# set rsvp peer-interface CE1 dynamic-bidirectional-transport 


11. Enable MPLS on all the interfaces of Router PE1, excluding the management interface. 


[edit protocols] 
user@PE1# set mpls interface all 
user@PE1# set mpls interface fxp0.0 disable 


12. Configure OSPF with traffic engineering capabilities. 


[edit protocols] 
user@PE1# set ospf traffic-engineering 


13. Enable OSPF area 0 on all the interfaces of Router PE1, excluding the management interface. 


[edit protocols] 
user@PE1# set ospf area 0.0.0.0 interface all 
user@PE1# set ospf area 0.0.0.0 interface fxp0.0 disable 


14. Configure a traffic engineering link, and assign addresses for the local and remote end of the link. 


[edit protocols] 
user@PE1# set link-management te-link link1 local-address 10.35.1.2 
user@PE1# set link-management te-link link1 remote-address 10.35.1.1 
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15. Enable setting up of a Layer 2 VLAN LSP for a specific range of VLANs on the link1 traffic engineering 
link. 


[edit protocols] 
user@PE1# set link-management te-link link1 ethernet-vlan vian-id-range 1-1000 


16. Configure the Router PE1 interface as the member interface of the link1 traffic engineering link. 


[edit protocols] 
user@CE1# set link-management te-link link1 interface ge-0/0/0 


17. Configure Router CE1 as the LMP peer for Router PE1, and configure the peer attributes. 


[edit protocols] 

user@CE1# set link-management peer CE1 address 10.255.10.1 
user@CE1# set link-management peer CE1 control-channel gre.O 
user@CE1# set link-management peer CE1 te-link link1 


Results 

From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 
and show protocols commands. If the output does not display the intended configuration, repeat the 
instructions in this example to correct the configuration. 


user@PE1# show interfaces 
ge-0/0/0 { 
vian-tagging; 
encapsulation flexible-ethernet-services; 
unit 1 { 
vian-id 1; 
family inet { 
address 1.1.1.2/30; 
} 
family mpls; 
} 
unit 10 { 
encapsulation vian-ccc; 
vilan-id 10; 


} 
ge-0/0/1 { 
unit O { 


family inet { 
address 70.70.70.1/30; 
} 


family mpls; 


} 
ge-0/0/2 { 
unit O { 
family inet { 
address 20.20.20.1/30; 
} 


family mpls; 


} 
gre { 
unit O { 
tunnel { 
source 1.1.1.2; 
destination 1.1.1.1; 
} 
family inet { 
address 10.35.100.26/30; 


} 
loO { 
unit O { 
family inet { 
address 10.255.10.2/32; 


user@PE1# show routing-options 
router-id 10.255.10.2; 


user@PE1# show protocols 
rsvp { 
associated-bidirectional-Isp single-sided-provisioning; 
interface all; 
interface fxp0.0 { 
disable; 
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peer-interface CE1 { 
dynamic-bidirectional-transport; 


} 
mpls { 
interface all; 
interface fxp0.0 { 
disable; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 


} 


link-management { 

te-link link1 { 
local-address 10.35.1.2; 
remote-address 10.35.1.1; 
ethernet-vlan { 

vian-id-range 1-1000; 

} 
interface ge-0/0/0; 

} 

peer CE1 { 
address 10.255.10.1; 
control-channel gre.0; 
te-link link1; 


Verification 


IN THIS SECTION 


@ = -Verifying the Traffic Engineering Link Status on the Client Routers | 1297 
@ Verifying the RSVP Session Status on the Client Routers | 1298 
@ Verifying the LSP Status on the Server Router | 1299 


@ Verifying the CCC Entries in the MPLS Routing Table of the Server Routers | 1300 
@ ~~ Verifying End-to-End Connectivity | 1301 


Confirm that the configuration is working properly. 


Verifying the Traffic Engineering Link Status on the Client Routers 


Purpose 


Verify the status of the traffic engineering link configured between Router CE1 and Router CE2. 


Action 


From operational mode, run the show link-management and the show link-management te-link detail 
commands. 





user@CE1> show link-management 


Peer name: PE1, System identifier: 50740 


Stare: Up, Control address: 10,255. 110.2 
Hello interval: 150, Hello dead interval: 500 








Control—-channel Stace 
gre.0 Active 
TE ninks!: 

link10 


TE link name: link10, State: Up 





Local identifier: 65075, Remote identifier: 0, Local address: 10.35.1.1, Remote 











address: 10.35.1.2, Encoding: Ethernet, Switching: EVPL, Minimum bandwidth: Obps, 





Maximum bandwidth: 1000Mbps, Total bandwidth: 1000Mbps, Available bandwidth: 
900Mbps 





Name State Local ID Remote ID Bandwidth Used 
LSP-name 

ge-0/0/0 Up 54183 0 1000Mbps_ Yes 
CE1-to-CE2 

















user@CE1> show link-management te-link detail 





TE link name: link10, State: Up 
Local identifier: 65075, Remote identifier: 0, Local address: 10.35.1.1, Remote 
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address: 10.35.1.2, Encoding: Ethernet, Switching: EVPL, Minimum bandwidth: Obps, 


Maximum bandwidth: 1000Mbps, Total bandwidth: 1000Mbps, Available bandwidth: 
900Mbps 


Resounce sw ge 0.0/0 ulyoc iE DS yStcmetGentit tore miotat cia Up LOGal: 
identifier: 54183, Remote identifier: 0 





Total bandwidth: 1000Mbps, Unallocated bandwidth: 900Mbps 














Traffic parameters: Encoding: Ethernet, Switching: EVPL, Granularity: Unknown 





aximum allocations: 4094, Number of allocations: 1, 


in use: Yes 


Unique allocations: 1, 


LSP name: CE1-to-CE2, Local label: 10, Remote label: 10, Allocated bandwidth: 
100Mbps 





user@CE2> show link-management 


Peer name: PE2, System identifier: 50743 


Sieeieee Wh) Comemeil ackiesesss 10,255, 10,5 





Hello interval: 150, Hello dead interval: 500 





Control-channel Seas 
gre.0 Active 
ama, haalkesse 

link10 


TE link name: link10, State: Up 








Local identifier: 65075, Remote identifier: 0, Local address: 10.36.1.1, Remote 


address: 10.36.1.2, Encoding: Ethernet, Switching: EVPL, Minimum bandwidth: Obps, 











Maximum bandwidth: 1000Mbps, Total bandwidth: 1000Mbps, Available bandwidth: 
900Mbps 














Name State Local ID Remote ID Bandwidth Used 
LSP-name 
ge-0/0/0 Up 54183 0 1000Mbps_ Yes 
Chl eos Che, 
Meaning 


The Link Management Protocol (LMP) peering has been established between the client routers, and the 
traffic engineering link is up on both Routers CE1 and CE2. 


Verifying the RSVP Session Status on the Client Routers 


Purpose 
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Verify the status of the RSVP sessions between Router CE1 and Router CE2. 
Action 


From operational mode, run the show rsvp session command. 





user@CE1> show rsvp session 


Ingress RSVP: 1 sessions 














To From State Rt Style Labelin Labelout LSPname 
10,255 410.6 10,455, 105i Up @ i ime = OMCE So — Cha Baickint 
Total 1 displayed, Up 1, Down 0 








Egress RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 





user@CE2> show rsvp session 


Ingress RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Egress RSVP: 1 sessions 


° From State Rt Style Labelin Labelout LSPname 
10.255 410.6 10.255,10 1 Up (Ol iL dep im0) = Cal-eoHCin2 Buel 














Total 1 displayed, Up 1, Down 0 


Transit RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 


The RSVP sessions are established between the ingress router, Router CE1, and the egress router, Router 
CE2. 


Verifying the LSP Status on the Server Router 


Purpose 
Verify the status of the MPLS LSP on Router PE1. 


Action 


From operational mode, run the show mpls Isp command. 





user@PE1> show mpls lsp 


Ingress LSP: 1 sessions 











fe) From State 
10,255 41055 10,255.10 ,2 Up 
wiles Os LOs gil 7/6310 255), 10), 2-S110 . 25S). LO 
Total 1 displayed, Up 1, Down 0 
Egress LSP: 1 sessions 
To From State 
ORS Sian? ORAS Spe ORS Up 
WileMmsOglOs Gil 7Os 10,255 10 .<2-S110 , 255. 10 
Total 1 displayed, Up 1, Down 0 
Transit LSP: 1 sessions 
To From State 
10.255 410.6 10,255,100 .i Up 
Total 1 displayed, Up 1, Down 0 


Meaning 
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Iie, 12 
Qo * 


ActivePath LSPname 


.5 Assoc-Bidir 


Rt Style Labelin Labelout LSPname 
O i wR 3 


.o:rev 


Rt Style Labelin Labelout LSPname 
@ i ine 10 ZIM Clril—to=C 














ayy lelaielalig 


The CE1-to-CE2 LSP is established, and the output displays the LSP attributes. 


Verifying the CCC Entries in the MPLS Routing Table of the Server Routers 


Purpose 


Verify the circuit cross-connect (CCC) interface entries in the MPLS routing table. 


Action 


From operational mode, run the show route table mpls.0 and the show route forwarding-table ccc 


ccc-interface commands. 





user@PE1> show route table mpls.0 








mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, O hidden) 
+ = Active Route, Last Active, * = Both 
0 *[MPLS/0O] ld 22:14:51, metric 1 
Receive 
i 2s | MIPINS//@]| icl Zee shi, metcrae Il 
Receive 
2 MPLS /O@] cl Z2eiasSil, mecrie il 
Receive 
U3} (MPLS /O]) Ite! 2QoiaeSil, meee I 





























Receive 


299824 = [ROWE /T/ Ll] LIS S28 


OF, wSicicae 1) 


> wila Ge-0/0/0.10, Pos 


ge-0/0/0.10 


SRewe/ T/L] LIs32807, 


meeeste il 


> to 20.20.20.2 wie Ga-0/0/2.0, 





label-—switched-path CE1-to-CE2 


user@PE1> show route forwarding-table ccc ge-0/0/0.10 


Routing table: default.mpls 


MPLS: 
Destination Type RtRef Next hop 
ge-0/0/0.10 (CCC) user 0 20.20.20.2 
581 2 ge-0/0/2.0 
Routing table: __mpls-oam__.mpls 
MPLS: 
Destination Type RtRef Next hop 
default perm 0 

Meaning 


The output displays the CCC interface that is the client-router-facing interface and the next-hop details 


for that interface. 


Verifying End-to-End Connectivity 


Purpose 


Verify the connectivity between Router CE1 and the remote client router, Router CE2. 


Action 


From operational mode, run the ping command. 


user@CE1> ping 10.10.10.2 





Type Index 


PusheagoSi0isr, 


Type Index 


dscd 




















PING LOO 10,2 (10,0102) 8 5G clara locas 

64 bytes from 10.10.10.2: icmp_seq=0 ttl=64 time=15. 
64 bytes from 10.10.10.2: icmp_seq=1 tt1l=64 time=13. 
64 bytes from 10.10.10.2: icmp_seq=2 ttl=64 time=13. 
64 bytes from 10.10.10.2: icmp_seq=3 tt1l=64 time=10. 
64 bytes from 10.10.10.2: icmp_seq=4 ttl=64 time=12. 


AG 
=== 10 10,102 joie SESELSELeCS =—— 


LS} 
3aS} 
769 
341 
3) 7) 


ms 


ms 


ms 


ms 


ms 


NhRef Netif 
Push 299872 (top) 


NhRef Netif 
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5 packets transmitted, 5 packets received, 0% packet loss 


round-trip min/avg/max/stddev = 10.341/13.035/15.113/1.575 ms 


Meaning 


The ping from Router CE1 to Router CE2 is successful. 
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CHAPTER 17 


CCC, TCC, and Layer 2.5 Switching 


IN THIS CHAPTER 
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| CCC, TCC, and Layer 2.5 Switching Configuration 
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TCC and Layer 2.5 Switching Overview 


Translational cross-connect (TCC) allows you to forward traffic between a variety of Layer 2 protocols or 
circuits. It is similar to its predecessor, CCC. However, while CCC requires the same Layer 2 encapsulations 
on both sides of a router (such as Point-to-Point Protocol [PPP] or Frame Relay-to-Frame Relay), TCC lets 
you connect different types of Layer 2 protocols interchangeably. With TCC, combinations such as 
PPP-to-ATM and Ethernet-to-Frame Relay cross-connections are possible. Also, TCC can be used to create 
Layer 2.5 VPNs and Layer 2.5 circuits. 


Consider a sample topology (Figure 104 on page 1305) in which you can configure a full-duplex Layer 2.5 
translational cross-connect between Router A and Router C, using a Juniper Networks router, Router B, 
as the TCC interface. In this topology, Router B strips all PPP encapsulation data from frames arriving from 
Router A and adds ATM encapsulation data before the frames are sent to Router C. All Layer 2 negotiations 
are terminated at the interconnecting router (Router B). 


Figure 104: Sample Translation Cross-Connect Topology 


ae | PPP ; lL ATM “4 tL 
QE Nel ne 


TCC functionality is different from standard Layer 2 switching. TCC only swaps Layer 2 headers. No other 


7221 


go172 


processing, such as header checksums, time-to-live (TTL) decrementing, or protocol handling, is performed. 
Currently, TCC is supported in IPv4, ISO, and MPLS. 


Ethernet TCC is supported on interfaces that carry IPv4 traffic only. For 8-port, 12-port, and 48-port Fast 
Ethernet PICs, TCC and extended VLAN CCC are not supported. For 4-port Gigabit Ethernet PICs, extended 
VLAN CCC and extended VLAN TCC are not supported. 


Configuring VLAN TCC Encapsulation 


VLAN TCC encapsulation allows circuits to have different media on either side of the forwarding path. 
VLAN TCC encapsulation supports TPID 0x8100 only. You must include configuration statements at the 
logical and physical interface hierarchy levels. 


Starting in Junos OS Release 20.1R1, aggregated Ethernet interfaces support VLAN translational 
cross-connect (TCC) encapsulation. For configuring VLAN TCC encapsulation, you must have the member 
links of aggregated Ethernet with VLAN TCC encapsulation supported hardware. 


NOTE: MxX series routers does not perform any external commit check for member links of 
aggregated interfaces for the VLAN TCC encapsulation supported hardware. 
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To configure VLAN TCC encapsulation, include the encapsulation statement and specify the vlan-tcc 
option: 


[edit interfaces interface-name unit logical-unit-number] 
encapsulation vlan-tcc; 


You can include this statement at the following hierarchy levels: 


e [edit interfaces interface-name unit logical-unit-number } 


e [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number] 


Additionally, configure the logical interface by including the proxy and remote statements: 


proxy { 
inet-address; 


} 
remote { 
(inet-address | mac-address); 


You can include these statements at the following hierarchy levels: 


e [edit interfaces interface-name unit logical-unit-number family tcc] 


e [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family tcc] 


The proxy address is the IP address of the non-Ethernet TCC neighbor for which the TCC router is acting 
as a proxy. 


The remote address is the IP or MAC address of the remote router. The remote statement provides ARP 
capability from the TCC switching router to the Ethernet neighbor. The MAC address is the physical Layer 
2 address of the Ethernet neighbor. 


When VLAN TCC encapsulation is configured on the logical interface, you also must specify flexible 
Ethernet services on the physical interface. To specify flexible Ethernet services, include the encapsulation 
statement at the [edit interfaces interface-name] hierarchy level and specify the flexible-ethernet-services 
option: 


[edit interfaces interface-name] 
encapsulation flexible-ethernet-services; 


Extended VLAN TCC encapsulation supports TPIDs 0x8100 and 0x9901. Extended VLAN TCC is specified 
at the physical interface level. When configured, all units on that interface must use VLAN TCC 
encapsulation, and no explicit configuration is needed on logical interfaces. 
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One-port Gigabit Ethernet, 2-port Gigabit Ethernet, and 4-port Fast Ethernet PICs with VLAN tagging 
enabled can use VLAN TCC encapsulation. To configure the encapsulation on a physical interface, include 
the encapsulation statement at the [edit interfaces interface-name] hierarchy level and specify the 
extended-vlan-tcc option: 


[edit interfaces interface-name] 
encapsulation extended-vlan-tcc; 


For VLAN TCC encapsulation, all VLAN IDs from 1 through 1024 are valid. VLAN ID 0 is reserved for 
tagging the priority of frames. 


Extended VLAN TCC is not supported on 4-port Gigabit Ethernet PICs. 


Configuring Translation Cross-Connect Interface Switching 


To configure a full-duplex Layer 2.5 translation cross-connect between two routers (A and C), you can 
configure a Juniper Networks router (Router B) as the TCC interface. Ethernet TCC encapsulation provides 
an Ethernet wide area circuit for interconnecting IP traffic. Consider the topology in Figure 105 on page 1307 
where the Router A-to-Router B circuit is PPP, and the Router B-to-Router C circuit accepts packets 
carrying standard TPID values. 


Figure 105: Sample Topology of Layer 2.5 Translational Cross-Connect 


| so-1/1/0 so-1/0/1 / A 0011.2233.4455 0001.0002.0008 / A \ 
oT 10.10.10.3/24 PPP oT [—~ Ethernet 10.10.10.2/24 7 [7 iS 


If traffic flows from Router A to Router C, the Junos OS strips all PPP encapsulation data from incoming 

packets and adds Ethernet encapsulation data before forwarding the packets. If traffic flows from Router 
C to Router A, the Junos OS strips all Ethernet encapsulation data from incoming packets and adds PPP 

encapsulation data before forwarding the packets. 


To configure the router as the translational cross-connect interface: 


1. In the configuration mode, at the [edit] hierarchy level, first configure the interface that is connected 
to Router A. 


[edit] 
user@host# edit interfaces interface-name 


2. (Optional) Specify the description of the interface. For example, you could specify the interface name 
on Router A that is connected to this interface. 
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[edit interfaces interface-name] 
user@host# set description description 


. Specify the encapsulation. If the Router A to Router B circuit is PPP, then specify ppp-tcc as the 
encapsulation. If the Router A to Router B circuit is frame relay, specify frame-relay-tcc. 


[edit interfaces interface-name] 
user@host# set encapsulation encapsulation-type 


. Inthe configuration mode, at the [edit] hierarchy level, first configure the interface that is connected 
to Router C. 


[edit] 
user@host# edit interfaces interface-name 


. (Optional) Specify the description of this interface. For example, you could specify the interface name 
on Router C that is connected to this interface. 


[edit interfaces interface-name] 
user@host# set description description 


. Specify the encapsulation. If the Router B to Router C circuit is Ethernet, then specify ethernet-tcc as 
the encapsulation. If the Router B to Router C circuit is ATM, specify atm-tcc-vc-mux. 


[edit interfaces interface-name] 
user@host# set encapsulation encapsulation-type 


. Specify the IP address or MAC address of the remote router to provide address resolution protocol 
(ARP) for the TCC router's Ethernet-based neighbor using the remote statement. You must specify the 
statement at the [edit interfaces interface-name unit unit-number family tcc] hierarchy level. You can 
a specify the MAC address of the remote router instead of the IP address. The MAC address is the 
physical Layer 2 address of the Ethernet neighbor. 


[edit interfaces interface-name] 
user@host# set unit O family family remote inet-address ip-address 
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8. Specify the IP address of the non-Ethernet TCC neighbor for which the TCC router is acting as a proxy 
using the proxy statement. You must specify the statement at the [edit interfaces interface-name unit 
unit-number family tcc] hierarchy level. 


[edit interfaces interface-name] 
user@host# set unit O family family proxy inet-address ip-address 


To verify the TCC connection, use the show connections command on TCC router. 


CCC Overview 


Circuit cross-connect (CCC) allows you to configure transparent connections between two circuits, where 
a circuit can be a Frame Relay data-link connection identifier (DLCI), an Asynchronous Transfer Mode 
(ATM) virtual circuit (VC), a Point-to-Point Protocol (PPP) interface, a Cisco High-Level Data Link Control 
(HDLC) interface, or an MPLS label-switched path (LSP). Using CCC, packets from the source circuit are 
delivered to the destination circuit with, at most, the Layer 2 address being changed. No other 
processing—such as header checksums, time-to-live (TTL) decrementing, or protocol processing—is done. 


NOTE: The QFX10000 Series switches do not support ATM virtual circuits. 


CCC circuits fall into two categories: logical interfaces, which include DLCls, VCs, virtual local area network 
(VLAN) IDs, PPP and Cisco HDLC interfaces, and LSPs. The two circuit categories provide three types of 
cross-connect: 


e Layer 2 switching—Cross-connects between logical interfaces provide what is essentially Layer 2 switching. 
The interfaces that you connect must be of the same type. 


e MPLS tunneling—Cross-connects between interfaces and LSPs allow you to connect two distant interface 
circuits of the same type by creating MPLS tunnels that use LSPs as the conduit. 


e LSP stitching—Cross-connects between LSPs provide a way to “stitch” together two label-switched 
paths, including paths that fall in two different traffic engineering database areas. 


For Layer 2 switching and MPLS tunneling, the cross-connect is bidirectional, so packets received on the 
first interface are transmitted out the second interface, and those received on the second interface are 
transmitted out the first. For LSP stitching, the cross-connect is unidirectional. 
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Understanding Carrier-of-Carriers VPNs 


IN THIS SECTION 


@ = Internet Service Provider as the Customer | 1312 


@ VPN Service Provider as the Customer | 1312 


The customer of a VPN service provider might be a service provider for the end customer. The following 
are the two main types of carrier-of-carriers VPNs (as described in RFC 4364: 


e “Internet Service Provider as the Customer” on page 1312—The VPN customer is an ISP that uses the VPN 
service provider's network to connect its geographically disparate regional networks. The customer does 
not have to configure MPLS within its regional networks. 


e “VPN Service Provider as the Customer” on page 1312—The VPN customer is itself a VPN service provider 
offering VPN service to its customers. The carrier-of-carriers VPN service customer relies on the backbone 
VPN service provider for inter-site connectivity. The customer VPN service provider is required to run 
MPLS within its regional networks. 


Figure 106 on page 1311 illustrates the network architecture used for a carrier-of-carriers VPN service. 


Figure 106: Carrier-of-Carriers VPN Architecture 
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This topic covers the following: 
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Internet Service Provider as the Customer 


In this type of carrier-of-carriers VPN configuration, ISP A configures its network to provide Internet 
service to ISP B. ISP B provides the connection to the customer wanting Internet service, but the actual 
Internet service is provided by ISP A. 


This type of carrier-of-carriers VPN configuration has the following characteristics: 


e The carrier-of-carriers VPN service customer (ISP B) does not need to configure MPLS on its network. 
e The carrier-of-carriers VPN service provider (ISP A) must configure MPLS on its network. 


e MPLS must also be configured on the CE routers and PE routers connected together in the 
carrier-of-carriers VPN service customer's and carrier-of-carriers VPN service provider's networks. 


VPN Service Provider as the Customer 


A VPN service provider can have customers that are themselves VPN service providers. In this type of 
configuration, also called a hierarchical or recursive VPN, the customer VPN service provider's VPN-IPv4 
routes are considered external routes, and the backbone VPN service provider does not import them into 
its VRF table. The backbone VPN service provider imports only the customer VPN service provider's 
internal routes into its VRF table. 


The similarities and differences between interprovider and carrier-of-carriers VPNs are shown in 
Table 31 on page 1312. 


Table 31: Comparison of Interprovider and Carrier-of-Carriers VPNs 


VPN Service Provider 


Feature ISP Customer Customer 
Customer edge device AS border router PE router 
IBGP sessions Carry IPv4 routes Carry external VPN-IPv4 


routes with associated labels 


Forwarding within the MPLS is optional MPLS is required 
customer network 


Support for VPN service as the customer is supported on QFX10000 switches starting with Junos OS 
Release 17.1R1. 


Understanding Interprovider and Carrier-of-Carriers VPNs 


All interprovider and carrier-of-carriers VPNs share the following characteristics: 


e Each interprovider or carrier-of-carriers VPN customer must distinguish between internal and external 
customer routes. 
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e Internal customer routes must be maintained by the VPN service provider in its PE routers. 


e External customer routes are carried only by the customer's routing platforms, not by the VPN service 
provider's routing platforms. 


The key difference between interprovider and carrier-of-carriers VPNs is whether the customer sites 
belong to the same AS or to separate ASs: 


e Interprovider VPNs—The customer sites belong to different ASs. You need to configure EBGP to exchange 
the customer’s external routes. 


e “Understanding Carrier-of-Carriers VPNs” on page 1310—The customer sites belong to the same AS. You 
need to configure IBGP to exchange the customer's external routes. 


In general, each service provider in a VPN hierarchy is required to maintain its own internal routes in its 
P routers, and the internal routes of its customers in its PE routers. By recursively applying this rule, it is 
possible to create a hierarchy of VPNs. 


The following are definitions of the types of PE routers specific to interprovider and carrier-of-carriers 
VPNs: 


e The AS border router is located at the AS border and handles traffic leaving and entering the AS. 


e The end PE router is the PE router in the customer VPN; it is connected to the CE router at the end 
customer’s site. 
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Configuring an MPLS-Based VLAN CCC Using a Layer 2 Circuit 


You can configure an 802.1Q VLAN as an MPLS-based Layer 2 circuit on the switch to interconnect 


multiple customer sites with Layer 2 technology. 


This topic describes configuring provider edge (PE) switches in an MPLS network using a circuit 
cross-connect (CCC) on a tagged VLAN interface (802.1Q VLAN) rather than a simple interface. 


NOTE: You do not need to make any changes to existing provider switches in your MPLS network 
to support this type of configuration. For information on configuring provider switches, see 
“Configuring MPLS on Provider Switches” on page 63. 


NOTE: You can send any kind of traffic over a CCC, including nonstandard bridge protocol data 
units (BPDUs) generated by other vendors’ equipment. 


NOTE: If you configure a physical interface as VLAN-tagged and with the vlan-ccc encapsulation, 


you cannot configure the associated logical interfaces with the inet family. Doing so could cause 
the logical interfaces to drop packets. 


To configure a PE switch with a VLAN CCC and an MPLS-based Layer 2 circuit: 


1. Configure OSPF (or IS-IS) on the loopback (or switch address) and core interfaces: 


[edit protocols] 


user@switch# 


user@switch# 


user@switch# 





user@switch# 


set ospf area 0.0.0.0 interface lo0.0 
set ospf area 0.0.0.0 interface interface-name 
set ospf area 0.0.0.0 interface interface-name 


set ospf area 0.0.0.0 interface interface-name 


2. Enable traffic engineering for the routing protocol: 


[edit protocols] 


user@switch# set ospf traffic-engineering 


3. Configure an IP address for the loopback interface and for the core interfaces: 


[edit] 


user@switch# set interfaces loO unit logical-unit-number family inet address address 
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user@switch# set interfaces interface-name unit logical-unit-number family inet address address 





user@switch# set interfaces interface-name unit logical-unit-number family inet address address 











user@switch# set interfaces interface-name unit logical-unit-number family inet address address 


. Enable the MPLS protocol with CSPF disabled: 


NOTE: CSPF is a shortest-path-first algorithm that has been modified to take into account 
specific restrictions when the shortest path across the network is calculated. You need to 
disable CSPF for link protection to function properly on interarea paths. 


[edit protocols] 


user@switch# set mpls no-cspf 


. Configure the customer edge interface as a Layer 2 circuit from the local PE switch to the other PE 
switch: 


[edit protocols] 
user@switch# set |2circuit neighbor address interface interface-name virtual-circuit-id identifier 


TIP: Use the switch address of the other switch as the neighbor address. 


. Configure MPLS on the core interfaces: 


[edit protocols] 
user@switch# set mpls interface interface-name 
user@switch# set mpls interface interface-name 


user@switch# set mpls interface interface-name 
. Configure LDP on the loopback interface and the core interfaces: 


[edit protocols] 


user@switch# set ldp interface lo0.0 





user@switch# set Idp interface interface-name 








user@switch# set Idp interface interface-name 





user@switch# set Idp interface interface-name 
. Configure family mpls on the logical units of the core interfaces: 


[edit] 
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user@switch# set interfaces interface-name unit logical-unit-number family mpls 





user@switch# set interfaces interface-name unit logical-unit-number family mpls 











user@switch# set interfaces interface-name unit logical-unit-number family mpls 


NOTE: You can enable family mpls on either individual interfaces or aggregated Ethernet 
interfaces. You cannot enable it on tagged VLAN interfaces. 


9. Enable VLAN tagging on the customer edge interface of the local PE switch: 


[edit] 


user@switch# set interfaces interface-name vian-tagging 


10. Configure the customer edge interface to use VLAN CCC encapsulation: 


[edit] 


user@switch# set interfaces interface-name encapsulation vilan-ccc 


11. Configure the logical unit of the customer edge interface with a VLAN ID: 


NOTE: The VLAN ID cannot be configured on logical interface unit 0. The logical unit number 
must be 1 or higher. 


The same VLAN ID must be used when configuring the customer edge interface on the other 
PE switch. 


[edit ] 


user@switch# set interfaces interface-name logical-unit-number vlan-idvlan-id 


When you have completed configuring one PE switch, follow the same procedures to configure the other 
PE switch. 


NOTE: For EX Series switches, you must use the same type of switch for the other PE switch. 


VLAN CCC Encapsulation on Transport Side of Pseudowire Client Logical Interfaces Overview 


Currently, Junos OS does not allow the same VLAN ID to be configured on more than one logical interface 
under the same pseudowire client physical interface. To support vlan-ccc encapsulation on transport 
pseudowire service (PS) interface on the provider edge (PE) device, this restriction is removed and you 
can configure the same VLAN ID on more than one logical interface. 


The primary reason to configure vlan-ccc on the transport PS interface is interoperability with the existing 
access and aggregate devices in the network. Currently, Junos OS supports ethernet-ccc encapsulation 
on the transport PS interface. Typically, while establishing a pseudowire connection, the access device 
initiates a VLAN-based pseudowire (also known as VLAN-tagged mode), and a PE router signals the Ethernet 
mode VLAN back to the access device. For this type of pseudowire connection to be established, you can 
use the ignore-encapsulation-mismatch statement. However, the Junos OS device (access device) might 
not support the ignore-encapsulation-mismatch statement and, as a result, the pseudowire connection is 
not formed. When the ignore-encapsulation-mismatch statement is not supported on the access device, 
you can configure vlan-ccc between the nodes to form a pseudowire connection. 


The forwarding data path is not changed with the new vlan-ccc encapsulation on the transport PS interface 
and the behavior similar to that when the ethernet-ccc encapsulation is configured on the transport PS 
interface. The transport PS interface either encapsulates or de-encapsulate the outer Layer 2 header and 
MPLS headers on the transmitted or received packets on the WAN port. Inner Ethernet or VLAN headers 
of the packet are handled on pseudowire client service logical interfaces. You must configure pseudowire 
client service logical interfaces with appropriate VLAN IDs or VLAN tags. 


The following sections provides details, along with a sample configuration, about pseudowire configuration 
from both access and aggregation nodes. 


Pseudowire Configuration from Access Node 


These pseudowires are set up using VLANs from the access node for customer devices attached to the 
Layer 2 circuit configured on access and PE routers with customer VLANs (C-VLANs). The ingress traffic 
(from the access node side) on the PE router is single VLAN tagged (inner Ethernet header), and thus the 
service logical interfaces must be configured with the same VLAN IDs corresponding to the C-VLAN IDs 
attached to the access node. 


Figure 107 on page 1318 provides the details of a transport PS interface from an access node (access node). 
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Figure 107: Pseudowire Client Transport Logical Interface from Access Node 
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The following example shows the configuration of a pseudowire client logical interface configuration on 


a PE router from an access node: 


interfaces { 
ps0 { 


anchor-point It-3; 


unit O { 
encapsulation VLAN-ccc; 


VLAN ID 100; 


} 


unit 1 { 


VLAN ID 100; 


family inet; 


Pseudowire Configuration from Aggregation Node 


In this case, the aggregation node processes a stacked VLAN (also known as Q-in-Q). The pseudowire 
originates from aggregation node and terminates on a PE router. The aggregation node pushes the service 
VLAN (S-VLAN) tag, and the PE router is expected to operate on two VLAN tags—the outer VLAN tag 


corresponds to an S-VLAN and the inner VLAN tag corresponds to a C-VLAN. The VLAN ID configured 


on the transport PS interface at the PE router must match the VLAN tag of the S-VLAN. On the pseudowire 
client service logical interface, the outer VLAN tag must be configured to match the S-VLAN and the inner 


VLAN tag must be configured to match the C-VLAN. 


Figure 108 on page 1319 provides the details of a transport PS interface from an aggregation node. 
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Figure 108: Pseudowire Client Transport Logical Interface from Aggregation Node 
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Packets 


The following example shows the configuration of a pseudowire client logical interface configuration on 
a PE router from an aggregation node: 


interfaces { 
ps0 { 
anchor-point It-3; 
unit O { 
encapsulation VLAN-ccc; 
VLAN ID 500; 
} 
unit 1 { 
VLAN tags { 
outer 500; 
inner 100; 


} 
unit 2 { 
VLAN tags { 
outer 500; 
inner 200; 
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Transmitting Nonstandard BPDUs 


CCC protocol (and Layer 2 Circuit and Layer 2 VPN) configurations can transmit nonstandard bridge 
protocol data units (BPDUs) generated by other vendors’ equipment. This is the default behavior on all 
supported PICs and requires no additional configuration. 


The following PICs are supported on M320 and T Series routers: 
e 1-port Gigabit Ethernet PIC 
e 2-port Gigabit Ethernet PIC 
e 4-port Gigabit Ethernet PIC 


e 10-port Gigabit Ethernet PIC 


TCC Overview 


Translational cross-connect (TCC) is a switching concept that enables you to establish interconnections 
between a variety of Layer 2 protocols or circuits. It is similar to CCC. However, whereas CCC requires 
the same Layer 2 encapsulations on each side of a Juniper Networks router (such as PPP-to-PPP or Frame 
Relay-to-Frame Relay), TCC enables you to connect different types of Layer 2 protocols interchangeably. 
When you use TCC, combinations such as PPP-to-ATM (see Figure 109 on page 1320) and Ethernet-to-Frame 
Relay connections are possible. 


Figure 109: TCC Example 
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The Layer 2 circuits and encapsulation types that can be interconnected by TCC are: 
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e Ethernet 

e Extended VLANs 
e PPP 

e HDLC 

e ATM 


e Frame Relay 


TCC works by removing the Layer 2 header when frames enter the router and adding a different Layer 2 
header on the frames before they leave the router. In Figure 109 on page 1320, the PPP encapsulation is 
stripped from the frames arriving at Router B, and the ATM encapsulation is added before the frames are 
sent to Router C. 
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Note that all control traffic is terminated at the interconnecting router (Router B). Examples of traffic 
controllers include the Link Control Protocol (LCP) and the Network Control Protocol (NCP) for PPP, 
keepalives for HDLC, and Local Management Interface (LMI) for Frame Relay. 


TCC functionality is different from standard Layer 2 switching. TCC only swaps Layer 2 headers. No other 
processing, such as header checksums, TTL decrementing, or protocol handling is performed. TCC is 
supported for IPv4 only. 


Address Resolution Protocol (APR) packet policing on TCC Ethernet interfaces is effective for releases 


10.4 and onwards. 


You can configure TCC for interface switching and for Layer 2 VPNs. For more information about using 
TCC for virtual private networks (VPNs), see the Junos OS VPNs Library for Routing Devices. 


Configuring Layer 2 Switching Cross-Connects Using CCC 


IN THIS SECTION 


Configuring the CCC Encapsulation for Layer 2 Switching Cross-Connects | 1322 
Configuring the CCC Connection for Layer 2 Switching Cross-Connects | 1327 
Configuring MPLS for Layer 2 Switching Cross-Connects | 1327 

Example: Configuring a Layer 2 Switching Cross-Connect | 1328 


Configuring Layer 2 Switching Cross-Connect on ACX5440 | 1330 


Layer 2 switching cross-connects join logical interfaces to form what is essentially Layer 2 switching. The 


interfaces that you connect must be of the same type. 


Figure 110 on page 1322 illustrates a Layer 2 switching cross-connect. In this topology, Router A and Router C 
have Frame Relay connections to Router B, which is a Juniper Networks router. Circuit cross-connect 
(CCC) allows you to configure Router B to act as a Frame Relay (Layer 2) switch. 


To configure Router B to act as a Frame Relay switch, you configure a circuit from Router A to Router C 
that passes through Router B, effectively configuring Router B as a Frame Relay switch with respect to 
these routers. This configuration allows Router B to transparently switch packets (frames) between Router A 
and Router C without regard to the packets’ contents or the Layer 3 protocols. The only processing that 
Router B performs is to translate DLCI 600 to 750. 
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Figure 110: Layer 2 Switching Cross-Connect 
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If the Router A-to-Router B and Router B-to-Router C circuits were PPP, for example, the Link Control 
Protocol and Network Control Protocol exchanges occur between Router A and Router C. These messages 
are handled transparently by Router B, allowing Router A and Router C to use various PPP options (such 
as header or address compression and authentication) that Router B might not support. Similarly, Router A 
and Router C exchange keepalives, providing circuit-to-circuit connectivity status. 


You can configure Layer 2 switching cross-connects on PPP, Cisco HDLC, Frame Relay, Ethernet, and ATM 
circuits. In a single cross-connect, only like interfaces can be connected. 


To configure Layer 2 switching cross-connects, you must configure the following on the router that is 
acting as the switch (Router B in Figure 110 on page 1322): 


Configuring the CCC Encapsulation for Layer 2 Switching Cross-Connects 


IN THIS SECTION 


Configuring ATM Encapsulation for Layer 2 Switching Cross-Connects | 1323 

Configuring Ethernet Encapsulation for Layer 2 Switching Cross-Connects | 1323 
Configuring Ethernet VLAN Encapsulation for Layer 2 Switching Cross-Connects | 1324 
Configuring Aggregated Ethernet Encapsulation for Layer 2 Switching Cross-Connects | 1325 


Configuring Frame Relay Encapsulation for Layer 2 Switching Cross-Connects | 1326 


Configuring PPP and Cisco HDLC Encapsulation for Layer 2 Switching Cross-Connects | 1326 


To configure Layer 2 switching cross-connects, configure the CCC encapsulation on the router that is 
acting as the switch (Router B in Figure 110 on page 1322). 


NOTE: You cannot configure families on CCC interfaces; that is, you cannot include the family 
statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level. 


For instructions for configuring the encapsulation for Layer 2 switching cross-connects, see the following 
sections: 
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Configuring ATM Encapsulation for Layer 2 Switching Cross-Connects 


For ATM circuits, specify the encapsulation when configuring the virtual circuit (VC). Configure each VC 
as a circuit or a regular logical interface by including the following statements: 


at-fpc/pic/port { 
atm-options { 
vpi vpi-identifier maximum-vcs maximum-vcs; 
} 
unit logical-unit-number { 
encapsulation encapsulation-type; 
point-to-point; # Default interface type 
vci vpi-identifier.vci-identifier, 


You can include these statements at the following hierarchy levels: 


e [edit interfaces] 


e [edit logical-systems logical-system-name interfaces] 


Configuring Ethernet Encapsulation for Layer 2 Switching Cross-Connects 


For Ethernet circuits, specify ethernet-ccc in the encapsulation statement. This statement configures the 
entire physical device. For these circuits to work, you must also configure a logical interface (unit 0). 


Ethernet interfaces with standard Tag Protocol Identifier (TPID) tagging can use Ethernet CCC encapsulation. 
On M Series Multiservice Edge Routers, except the M320, one-port Gigabit Ethernet, two-port Gigabit 
Ethernet, four-port Gigabit Ethernet, and four-port Fast Ethernet PICs can use Ethernet CCC encapsulation. 
On T Series Core Routers and M320 routers, one-port Gigabit Ethernet and two-port Gigabit Ethernet 
PICs installed in FPC2 can use Ethernet CCC encapsulation. When you use this encapsulation type, you 
can configure the ccc family only. 


fe-fpc/pic/port { 
encapsulation ethernet-ccc; 
unit O; 


You can include these statements at the following hierarchy levels: 


e [edit interfaces] 


e [edit logical-systems logical-system-name interfaces] 
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Configuring Ethernet VLAN Encapsulation for Layer 2 Switching Cross-Connects 


An Ethernet virtual LAN (VLAN) circuit can be configured using either the vlan-ccc or extended-vlan-ccc 
encapsulation. If you configure the extended-vlan-ccc encapsulation on the physical interface, you cannot 
configure the inet family on the logical interfaces. Only the ccc family is allowed. If you configure the 
vlan-ccc encapsulation on the physical interface, both the inet and ccc families are supported on the logical 
interfaces. Ethernet interfaces in VLAN mode can have multiple logical interfaces. 


For encapsulation type vlan-ccc, VLAN IDs from 512 through 4094 are reserved for CCC VLANs. For the 
extended-vlan-ccc encapsulation type, all VLAN IDs 1 and higher are valid. VLAN ID O is reserved for 
tagging the priority of frames. 


NOTE: Some vendors use the proprietary TPIDs 0x9100 and 0x9901 to encapsulate a 
VLAN-tagged packet into a VLAN-CCC tunnel to interconnect a geographically separated metro 
Ethernet network. By configuring the extended-vlan-ccc encapsulation type, a Juniper Networks 
router can accept all three TPIDs (0x8100, 0x9100, and 0x9901). 


Configure an Ethernet VLAN circuit with the vlan-ccc encapsulation as follows: 


interfaces { 
type-fpc/pic/port { 
vian-tagging; 
encapsulation vian-ccc; 
unit logical-unit-number { 
encapsulation vlan-ccc; 
vlan-id vlan-id; 


You can configure these statements at the following hierarchy levels: 


e [edit interfaces] 


e [edit logical-systems logical-system-name interfaces] 


Configure an Ethernet VLAN circuit with the extended-vlan-ccc encapsulation statement as follows: 


interfaces { 
type-fpc/pic/port { 
vian-tagging; 
encapsulation extended-vlan-ccc; 
unit logical-unit-number { 
vilan-id vlan-id; 
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family ccc; 


You can configure these statements at the following hierarchy levels: 


e [edit interfaces] 


e [edit logical-systems logical-system-name interfaces] 


Whether you configure the encapsulation as vlan-ccc or extended-vlan-ccc, you must enable VLAN tagging 
by including the vlan-tagging statement. 


Configuring Aggregated Ethernet Encapsulation for Layer 2 Switching Cross-Connects 


You can configure aggregated Ethernet interfaces for CCC connections and for Layer 2 virtual private 
networks (VPNs). 


Aggregated Ethernet interfaces configured with VLAN tagging can be configured with multiple logical 
interfaces. The only encapsulation available for aggregated Ethernet logical interfaces is vian-ccc. When 
you configure the vlan-id statement, you are limited to VLAN IDs 512 through 4094. 


Aggregated Ethernet interfaces configured without VLAN tagging can be configured only with the 
ethernet-ccc encapsulation. All untagged Ethernet packets received are forwarded based on the CCC 
parameters. 


To configure aggregated Ethernet interfaces for CCC connections, include the aeO statement at the [edit 
interfaces] hierarchy level: 


[edit interfaces] 
aeO { 
encapsulation (ethernet-ccc | extended-vlan-ccc | vlan-ccc); 
vian-tagging; 
aggregated-ether-options { 
minimum-links links; 
link-speed speed; 
} 
unit logical-unit-number { 
encapsulation vlan-ccc; 
vlan-id identifier; 


family ccc; 


Be aware of the following limitations when configuring CCC connections over aggregated Ethernet 
interfaces: 
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If you configured load balancing between child links, be aware that a different hash key is used to 
distribute packets among the child links. Standard aggregated interfaces have family inet configured. An 
IP version 4 (IPv4) hash key (based on the Layer 3 information) is used to distribute packets among the 
child links. A CCC connection over an aggregated Ethernet interface has family ccc configured instead. 
Instead of an IPv4 hash key, an MPLS hash key (based on the destination media access control [MAC] 
address) is used to distributed packets among the child links. 


The extended-vlan-ccc encapsulation is not supported on the 12-port Fast Ethernet PIC and the 48-port 
Fast Ethernet PIC. 


The Junos OS does not support the Link Aggregation Control Protocol (LACP) when an aggregated 


interface is configured as a VLAN (with vlan-ccc encapsulation). LACP can be configured only when the 
aggregated interface is configured with the ethernet-ccc encapsulation. 


For more information about how to configure aggregated Ethernet interfaces, see the Junos OS Network 
Interfaces Library for Routing Devices. 


Configuring Frame Relay Encapsulation for Layer 2 Switching Cross-Connects 


For Frame Relay circuits, specify the encapsulation when configuring the DLCI. Configure each DLCI as a 
circuit or a regular logical interface. The DLCI for regular interfaces must be from 1 through 511. For CCC 
interfaces, it must be from 512 through 4094. 


interfaces { 
type-fpc/pic/port { 
unit logical-unit-number { 
dici dici-identifier; 
encapsulation encapsulation-type; 
point-to-point; # Default interface type 


You can configure these statements at the following hierarchy levels: 


e [edit interfaces] 


e [edit logical-systems logical-system-name interfaces] 


Configuring PPP and Cisco HDLC Encapsulation for Layer 2 Switching Cross-Connects 


For PPP and Cisco HDLC circuits, specify the encapsulation in the encapsulation statement. This statement 
configures the entire physical device. For these circuits to work, you must configure a logical interface 
(unit O). 


interfaces type-fpc/pic/port { 
encapsulation encapsulation-type; 
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unit O; 


You can configure these statements at the following hierarchy levels: 


e [edit interfaces type-fpc/pic/port] 


e [edit logical-systems logical-system-name interfaces type-fpc/pic/port] 


Configuring the CCC Connection for Layer 2 Switching Cross-Connects 


To configure Layer 2 switching cross-connects, define the connection between the two circuits by including 
the interface-switch statement. You configure this connection on the router that is acting as the switch 
(Router B in Figure 110 on page 1322). The connection joins the interface that comes from the circuit's source 
to the interface that leads to the circuit's destination. When you specify the interface names, include the 
logical portion of the name, which corresponds to the logical unit number. The cross-connect is bidirectional, 
so packets received on the first interface are transmitted out the second interface, and those received on 
the second interface are transmitted out the first. 


interface-switch connection-name { 
interface interface-name.unit-number,; 
interface interface-name.unit-number,; 


You can include this statement at the following hierarchy levels: 
e [edit protocols connections] 


e [edit logical-systems logical-system-name protocols connections] 


Configuring MPLS for Layer 2 Switching Cross-Connects 


For Layer 2 switching cross-connects to work, you must enable MPLS on the router by including at least 
the following statements. This minimum configuration enables MPLS on a logical interface for the switching 
cross-connect. 


Include the family mpls statement: 


family mpls; 


You can configure this statement at the following hierarchy levels: 


e [edit interfaces interface-name unit logical-unit-number] 


e [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number] 


You can then specify this logical interface in the MPLS protocol configuration: 
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mpls { 
interface interface-name; # Required to enable MPLS on the interface 


You can configure these statements at the following hierarchy levels: 


e [edit protocols] 


e [edit logical-systems logical-system-name protocols] 


Example: Configuring a Layer 2 Switching Cross-Connect 


Configure a full-duplex Layer 2 switching cross-connect between Router A and Router C, using a Juniper 
Networks router, Router B, as the virtual switch. See the topology in Figure 111 on page 1328 and 
Figure 112 on page 1329. 


Figure 111: Topology of a Frame Relay Layer 2 Switching Cross-Connect 
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so-1/0/0 s0-2/0/0 
[edit] 
interfaces { 
so-1/0/0 { 
encapsulation frame-relay-ccc; 
unit 1 { 


point-to-point; 
encapsulation frame-relay-ccc; 
dici 600; 


} 
so-2/0/0 { 
encapsulation frame-relay-ccc; 
unit 2 { 
point-to-point; 
encapsulation frame-relay-ccc; 
dici 750; 


} 
protocols { 
connections { 
interface-switch router-a-to-router-c { 


interface so-1/0/0.1; 
interface so-2/0/0.2; 


} 


mpls { 
interface all; 


Figure 112: Sample Topology of a VLAN Layer 2 Switching Cross-Connect 
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ge-2/1/0.0 ge-2/2/0.0 


[edit] 
interfaces { 
ge-2/1/0 { 
vian-tagging; 
encapsulation vian-ccc; 
unit O { 
encapsulation vian-ccc; 
vlan-id 600; 


} 
ge-2/2/0 { 
vian-tagging; 
encapsulation vian-ccc; 
unit O { 
encapsulation vian-ccc; 
vlan-id 600; 
} 
unit 1 { 
family inet { 
vian-id 1; 
address 10.9.200.1/24; 


} 
protocols { 
mopls { 
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interface all; 
} 
connections { 
interface-switch layer2-sw { 
interface ge-2/1/0.0; 
interface ge-2/2/0.0; 


Configuring Layer 2 Switching Cross-Connect on ACX5440 


Starting in Junos OS Release 19.3R1, you can leverage the hardware support available for cross-connects 
on the ACX5448 device with the Layer 2 local switching functionality using certain models. With this 
support, you can provide the EVP and Ethernet Virtual Private Line (EVPL) services.. 


Local-switching with the following forwarding models are supported: 


e VLAN-CCC (logical interface-level local-switching) without any map. 

e VLAN-CCC (logical interface-level local-switching) with the following vilan-maps: 
e Push 0x8100.pushVLAN (QinQ type) 
e Swap 0x8100.swapVLAN 


e Aggregated Ethernet (AE) static interfaces. 
e AE interfaces with LACP, load-balance all active mode. 


e Local-switching end-interface support for AE or LAG interface (one non-AE interface and other AE 
interface). 


e Local-switching both interface as AE or LAG interfaces. 


To enable Layer 2 local switching on the ACX5448 device, you can use the existing configuration statements 
for Layer 2 circuits. For example, 


[edit protocols |2circuit] 
local-switching { 
interface interface { 
end-interface interface3; 
ignore-encapsulation-mismatch; 
ignore-mtu-mismatch; 
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Configuring MPLS LSP Tunnel Cross-Connects Using CCC 


IN THIS SECTION 


@ = Configuring the CCC Encapsulation for LSP Tunnel Cross-Connects | 1332 
® = Configuring the CCC Connection for LSP Tunnel Cross-Connects | 1334 


@ Example: Configuring an LSP Tunnel Cross-Connect | 1334 


MPLS tunnel cross-connects between interfaces and LSPs allow you to connect two distant interface 
circuits of the same type by creating MPLS tunnels that use LSPs as the conduit. The topology in 

Figure 113 on page 1331 illustrates an MPLS LSP tunnel cross-connect. In this topology, two separate 
networks, in this case ATM access networks, are connected through an IP backbone. CCC allows you to 
establish an LSP tunnel between the two domains. With LSP tunneling, you tunnel the ATM traffic from 
one network across a SONET backbone to the second network by using an MPLS LSP. 


Figure 113: MPLS Tunnel Cross-Connect 
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When traffic from Router A (VC 234) reaches Router B, it is encapsulated and placed into an LSP, which 
is sent through the backbone to Router C. At Router C, the label is removed, and the packets are placed 
onto the ATM permanent virtual circuit (PVC) (VC 591) and sent to Router D. Similarly, traffic from Router 
D (VC 591) is sent over an LSP to Router B, then placed on VC 234 to Router A. 


You can configure LSP tunnel cross-connect on PPP, Cisco HDLC, Frame Relay, and ATM circuits. Ina 
single cross-connect, only like interfaces can be connected. 


When you use MPLS tunnel cross-connects to support IS-IS, you must ensure that the LSP’s maximum 
transmission unit (MTU) can, at a minimum, accommodate a 1492-octet IS-IS protocol data unit (PDU) in 
addition to the link-level overhead associated with the technology being connected. 


For the tunnel cross-connects to work, the IS-IS frame size on the edge routers (Routers A and D in 
Figure 114 on page 1334) must be smaller than the LSP’s MTU. 


NOTE: Frame size values do not include the frame check sequence (FCS) or delimiting flags. 


To determine the LSP MTU required to support IS-IS, use the following calculation: 


IS-IS MTU (minimum 1492, default 1497) + frame overhead + 4 (MPLS shim header) = Minimum LSP MTU 


The framing overhead varies based on the encapsulation being used. The following lists the IS-IS 
encapsulation overhead values for various encapsulations: 


e ATM 
e AAL5 multiplex—8 bytes (RFC 1483) 


e VC multiplex—O bytes 


e Frame Relay 
e Multiprotocol—2 bytes (RFCs 1490 and 2427) 


e VC multiplex—O bytes 


e HDLC—4 bytes 
e PPP—4 bytes 
e VLAN—21 bytes (802.3/LLC) 


For IS-IS to work over VLAN-CCC, the LSP’s MTU must be at least 1513 bytes (or 1518 for 1497-byte 
PDUs). If you increase the size of a Fast Ethernet MTU above the default of 1500 bytes, you might need 
to explicitly configure jumbo frames on intervening equipment. 


To modify the MTU, include the mtu statement when configuring the logical interface family at the [edit 
interfaces interface-name unit logical-unit-number encapsulation family] hierarchy level. For more information 
about setting the MTU, see the Junos OS Network Interfaces Library for Routing Devices. 


To configure an LSP tunnel cross-connect, you must configure the following on the interdomain router 
(Router B in Figure 114 on page 1334): 
Configuring the CCC Encapsulation for LSP Tunnel Cross-Connects 


To configure LSP tunnel cross-connects, you must configure the CCC encapsulation on the ingress and 
egress routers (Router B and Router C, respectively, in Figure 114 on page 1334). 


NOTE: You cannot configure families on CCC interfaces; that is, you cannot include the family 
statement at the [edit interfaces interface-name unit logical-unit-number] hierarchy level. 


For PPP or Cisco HDLC circuits, include the encapsulation statement to configure the entire physical 
device. For these circuits to work, you must configure logical unit O on the interface. 
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type-fpc/pic/port { 
encapsulation (ppp-ccc | cisco-hdlc-ccc); 
unit O; 


You can include these statements at the following hierarchy levels: 
e [edit interfaces] 


e [edit logical-systems logical-system-name interfaces] 


For ATM circuits, specify the encapsulation when configuring the VC by including the following statements. 
For each VC, you configure whether it is a circuit or a regular logical interface. 


at-fpc/pic/port { 
atm-options { 
vpi vpi-identifier maximum-vcs maximum-vcs; 
} 
unit logical-unit-number { 
point-to-point; # Default interface type 
encapsulation atm-ccc-vc-mux; 
vci vpi-identifier.vci-identifier, 


You can include these statements at the following hierarchy levels: 


e [edit interfaces] 


e [edit logical-systems logical-system-name interfaces] 


For Frame Relay circuits, include the following statements to specify the encapsulation when configuring 
the DLCI. For each DLCI, you configure whether it is a circuit or a regular logical interface. The DLCI for 


regular interfaces must be in the range 1 through 511. For CCC interfaces, it must be in the range 512 
through 1022. 


type-fpc/pic/port { 
encapsulation frame-relay-ccc; 
unit logical-unit-number { 
point-to-point; # default interface type 
encapsulation frame-relay-ccc; 
dlci dlci-identifier; 


You can include these statements at the following hierarchy levels: 


e [edit interfaces] 


e [edit logical-systems logical-system-name interfaces] 


For more information about the encapsulation statement, see the Junos OS Network Interfaces Library for 
Routing Devices. 


Configuring the CCC Connection for LSP Tunnel Cross-Connects 


To configure LSP tunnel cross-connects, include the remote-interface-switch statement to define the 
connection between the two circuits on the ingress and egress routers (Router B and Router C, respectively, 
in Figure 114 on page 1334). The connection joins the interface or LSP that comes from the circuit's source 
to the interface or LSP that leads to the circuit’s destination. When you specify the interface name, include 
the logical portion of the name, which corresponds to the logical unit number. For the cross-connect to 
be bidirectional, you must configure cross-connects on two routers. 


remote-interface-switch connection-name { 
interface interface-name.unit-number,; 
transmit-Isp label-switched-path; 
receive-Isp label-switched-path; 


You can include these statements at the following hierarchy levels: 
e [edit protocols connections] 


e [edit logical-systems logical-system-name protocols connections] 


Example: Configuring an LSP Tunnel Cross-Connect 


Configure a full-duplex MPLS LSP tunnel cross-connect from Router A to Router D, passing through 
Router B and Router C. See the topology in Figure 114 on page 1334. 
Figure 114: Example Topology of MPLS LSP Tunnel Cross-Connect 
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On Router B: 


[edit] 
interfaces { 
at-7/1/1 { 
atm-options { 
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vpi 1 maximum-vcs 600; 
} 
unit 1 { 
point-to-point; # default interface type 
encapsulation atm-ccc-vc-mux; 
vei 1.234; 


} 
protocols { 
connections { 
remote-interface-switch router-b-to-router-c { 
interface at-7/1/1.1; 
transmit-Isp Isp1; 
receive-lsp Isp2; 


On Router C: 


[edit] 
interfaces { 
at-3/0/0 { 
atm-options { 
vpi 2 maximum-vcs 600; 
} 
unit 2 { 
point-to-point; # default interface type 
encapsulation atm-ccc-vc-mux; 
vei 2.591; 


} 
protocols { 
connections { 
remote-interface-switch router-b-to-router-c { 
interface at-3/0/0.2; 
transmit-Isp Isp2; 
receive-lsp Isp1; 
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Configuring TCC 


IN THIS SECTION 


@ = Configuring the Encapsulation for Layer 2 Switching TCCs | 1336 
® Configuring the Connection for Layer 2 Switching TCCs | 1340 
@ Configuring MPLS for Layer 2 Switching TCCs | 1341 


This section describes how to configure translational cross-connect (TCC). 


To configure TCC, you must perform the following tasks on the router that is acting as the switch: 


Configuring the Encapsulation for Layer 2 Switching TCCs 


IN THIS SECTION 


Configuring PPP and Cisco HDLC Encapsulation for Layer 2 Switching TCCs | 1337 
Configuring ATM Encapsulation for Layer 2 Switching TCCs | 1337 

Configuring Frame Relay Encapsulation for Layer 2 Switching TCCs | 1337 

Configuring Ethernet Encapsulation for Layer 2 Switching TCCs | 1338 

Configuring Ethernet Extended VLAN Encapsulation for Layer 2 Switching TCCs | 1339 


Configuring ARP for Ethernet and Ethernet Extended VLAN Encapsulations | 1340 


To configure a Layer 2 switching TCC, specify the TCC encapsulation on the desired interfaces of the 
router that is acting as the switch. 


NOTE: You cannot configure standard protocol families on TCC or CCC interfaces. Only the 
CCC family is allowed on CCC interfaces, and only the TCC family is allowed on TCC interfaces. 


For Ethernet circuits and Ethernet extended VLAN circuits, you must also configure the Address 
Resolution Protocol (ARP). See “Configuring ARP for Ethernet and Ethernet Extended VLAN 
Encapsulations” on page 1340. 
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Configuring PPP and Cisco HDLC Encapsulation for Layer 2 Switching TCCs 


For PPP and Cisco HDLC circuits, configure the encapsulation type for the entire physical device by 
specifying the appropriate value for the encapsulation statement. For these circuits to work, you must 
also configure the logical interface unit 0. 


encapsulation (ppp-tcc | cisco-hdlc-tcc); 
unit Of...} 


You can include these statements at the following hierarchy levels: 


e [edit interfaces interface-name] 


e [edit logical-systems logical-system-name interfaces interface-name] 


Configuring ATM Encapsulation for Layer 2 Switching TCCs 


For ATM circuits, configure the encapsulation type by specifying the appropriate value for the encapsulation 
statement in the virtual circuit (VC) configuration. Specify whether each VC is a circuit or a regular logical 
interface. 


atm-options { 
vpi vpi-identifier maximum-vcs maximum-vcs; 

} 

unit logical-unit-number { 
encapsulation (atm-tcc-vc-mux | atm-tcc-snap); 
point-to-point; 


vci vpi-identifier.vci-identifier; 


You can include these statements at the following hierarchy levels: 


e [edit interfaces at-fpc/pic/port] 


e [edit logical-systems logical-system-name interfaces at-fpc/pic/port] 


Configuring Frame Relay Encapsulation for Layer 2 Switching TCCs 


For Frame Relay circuits, configure the encapsulation type by specifying the value frame-relay-tcc for the 
encapsulation statement when configuring the data-link connection identifier (DLCI). You configure each 
DLCI as a circuit or a regular logical interface. The DLCI for regular interfaces must be in the range from 
1 through 511, but for TCC and CCC interfaces it must be in the range from 512 through 1022. 


encapsulation frame-relay-tcc; 
unit logical-unit-number { 
dlci dici-identifier,; 


encapsulation frame-relay-tcc; 
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point-to-point; 


You can include these statements at the following hierarchy levels: 


e [edit interfaces interface-name] 


e [edit logical-systems logical-system-name interfaces interface-name] 


Configuring Ethernet Encapsulation for Layer 2 Switching TCCs 


For Ethernet TCC circuits, configuring the encapsulation type for the entire physical device by specifying 
the value ethernet-tcc for the encapsulation statement. 


You must also specify static values for a remote address and a proxy address at the [edit interfaces 
interface-name unit unit-number family tcc] or [edit logical-systems logical-system-name interfaces 
interface-name unit unit-number family tcc] hierarchy level. 


The remote address is associated with the TCC switching router’s Ethernet neighbor; in the remote 
statement you must specify both the IP address and the media access control (MAC) address of the Ethernet 
neighbor. The proxy address is associated with the TCC router's other neighbor connected by the unlike 
link; in the proxy statement you must specify the IP address of the non-Ethernet neighbor. 


You can configure Ethernet TCC encapsulation for the interfaces on 1-port Gigabit Ethernet, 2-port Gigabit 
Ethernet, 4-port Fast Ethernet, and 4-port Gigabit Ethernet PICs. 


encapsulation ethernet-tcc; 
unit logical-unit-number { 
family tcc { 
proxy { 
inet-address ip-address; 


} 

remote { 
inet-address ip-address; 
mac-address mac-address; 


You can include these statements at the following hierarchy levels: 
e [edit interfaces (fe | ge)-fpc/pic/port] 


e [edit logical-systems logical-system-name interfaces (fe | ge)-fpc/pic/port] 
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NOTE: For Ethernet circuits, you must also configure the Address Resolution Protocol (ARP). 
See “Configuring ARP for Ethernet and Ethernet Extended VLAN Encapsulations” on page 1340. 


Configuring Ethernet Extended VLAN Encapsulation for Layer 2 Switching TCCs 


For Ethernet extended VLAN circuits, configure the encapsulation type for the entire physical device by 
specifying the value extended-vlan-tcc for the encapsulation statement. 


You must also enable VLAN tagging. Ethernet interfaces in VLAN mode can have multiple logical interfaces. 
With encapsulation type extended-vlan-tcc, all VLAN IDs from O through 4094 are valid, up to a maximum 
of 1024 VLANs. As with Ethernet circuits, you must also specify a proxy address and a remote address at 
the [edit interfaces interface-name unit logical-unit-number family tcc] or [edit logical-systems 
logical-system-name interfaces interface-name unit unit-number family tcc] hierarchy level (see “Configuring 
Ethernet Encapsulation for Layer 2 Switching TCCs” on page 1338). 


encapsulation extended-vlan-tcc; 
vian-tagging; 
unit logical-unit-number { 
vlan-id identifier; 
family tcc; 
proxy { 
inet-address ip-address; 
} 
remote { 
inet-address ip-address; 
mac-address mac-address; 


You can configure these statements at the following hierarchy levels: 


e [edit interfaces interface-name] 


e [edit logical-systems logical-system-name interfaces interface-name] 


NOTE: For Ethernet extended VLAN circuits, you must also configure the Address Resolution 
Protocol (ARP). See “Configuring ARP for Ethernet and Ethernet Extended VLAN Encapsulations” 
on page 1340. 
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Configuring ARP for Ethernet and Ethernet Extended VLAN Encapsulations 


For Ethernet and Ethernet extended VLAN circuits with TCC encapsulation, you must also configure ARP. 
Because TCC simply removes one Layer 2 header and adds another, the default form of dynamic ARP is 
not supported; you must configure static ARP. 


Because remote and proxy addresses are specified on the router performing TCC switching, you must 
apply the static ARP statement to the Ethernet-type interfaces of the routers that connect to the 
TCC-switched router. The arp statement must specify the IP address and the MAC address of the remotely 
connected neighbor by use of the unlike Layer 2 protocol on the far side of the TCC switching router. 


arp ip-address mac mac-address; 


You can include this statement at the following hierarchy levels: 


e [edit interfaces interface-name unit logical-unit-number family inet address ip-address] 


e [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family inet 
address ip-address] 


Configuring the Connection for Layer 2 Switching TCCs 


You must configure the connection between the two circuits of the Layer 2 switching TCC on the router 
acting as the switch. The connection joins the interface coming from the circuit's source to the interface 
leading to the circuit’s destination. When you specify the interface names, include the logical portion of 
the name, which corresponds to the logical unit number. The cross-connect is bidirectional, so packets 
received on the first interface are transmitted from the second interface, and those received on the second 
interface are transmitted from the first. 


To configure a connection for a local interface switch, include the following statements: 


interface-switch connection-name { 
interface interface-name.unit-number,; 


} 

Isp-switch connection-name { 
transmit-Isp Isp-number; 
receive-Isp Isp-number; 


You can include these statements at the following hierarchy levels: 


e [edit protocols connections] 
e [edit logical-systems logical-system-name protocols connections] 


To configure a connection for a remote interface switch, include the following statements: 
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remote-interface-switch connection-name { 
interface interface-name.unit-number,; 
interface interface-name.unit-number,; 
transmit-lsp Isp-number; 
receive-lsp Isp-number; 


You can include these statements at the following hierarchy levels: 
e [edit protocols connections] 


e [edit logical-systems logical-system-name protocols connections] 


Configuring MPLS for Layer 2 Switching TCCs 


For a Layer 2 switching TCC to work, you must enable MPLS on the router by including at least the following 
statements. This minimum configuration enables MPLS on a logical interface for the switching cross-connect. 


Include the family mpls statement: 


family mpls; 


You can configure this statement at the following hierarchy levels: 


e [edit interfaces interface-name unit logical-unit-number] 
e [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number] 
You can then specify this logical interface in the MPLS protocol configuration: 


mopls { 


interface interface-name; # Required to enable MPLS on the interface 


You can configure these statements at the following hierarchy levels: 


e [edit protocols] 


e [edit logical-systems logical-system-name protocols] 


NOTE: MPLS LSP link protection does not support TCC. 
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CCC and TCC Graceful Restart 


CCC and TCC graceful restart allows Layer 2 connections between customer edge (CE) routers to restart 
gracefully. These Layer 2 connections are configured with the remote-interface-switch or Isp-switch 
statements. Because these CCC and TCC connections have an implicit dependency on RSVP LSPs, graceful 
restart for CCC and TCC uses the RSVP graceful restart capabilities. 


RSVP graceful restart must be enabled on the PE routers and P routers to enable graceful restart for CCC 
and TCC. Also, because RSVP is used as the signaling protocol for signaling label information, the neighboring 
router must use helper mode to assist with the RSVP restart procedures. 


Figure 115 on page 1342 illustrates how graceful restart might work on a CCC connection between two CE 
routers. 


Figure 115: Remote Interface Switch Connecting Two CE Routers Using CCC 
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PE Router A is the ingress for the transmit LSP from PE Router A to PE Router B and the egress for the 
receive LSP from PE Router B to PE Router A. With RSVP graceful restart enabled on all the PE and P 
routers, the following occurs when PE router A restarts: 
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e PE Router A preserves the forwarding state associated with the CCC routes (those from CCC to MPLS 
and from MPLS to CCC). 


e Traffic flows without disruption from CE router to CE router. 


e After the restart, PE Router A preserves the label for the LSP for which PE Router A is the egress (the 
receive LSP, for example). The transmit LSP from PE Router A to PE Router B can derive new label 
mappings, but should not cause any traffic disruption. 


Configuring CCC and TCC Graceful Restart 


To enable CCC and TCC graceful restart, include the graceful-restart statement: 


graceful-restart; 
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You can include this statement at the following hierarchy levels: 
e [edit routing-options] 


e [edit logical-systems logical-system-name routing-options] 


Configuring an MPLS-Based VLAN CCC Using the Connection Method (CLI Procedure) 


You can configure an 802.1Q VLAN as an MPLS-based connection using EX8200 and EX4500 switches 
to interconnect multiple customer sites with Layer 2 technology. 


This topic describes configuring provider edge (PE) switches in an MPLS network using a circuit 
cross-connect (CCC) on a tagged VLAN interface (802.1Q VLAN) rather than a simple interface. 


NOTE: You do not need to make any changes to existing provider switches in your MPLS network 
to support this type of configuration. For information on configuring provider switches, see 
“Configuring MPLS on EX8200 and EX4500 Provider Switches” on page 78. 


NOTE: You can send any kind of traffic over a CCC, including nonstandard bridge protocol data 
units (BPDUs) generated by other vendors’ equipment. 


NOTE: If you configure a physical interface as VLAN-tagged and with the vlan-ccc encapsulation, 
you cannot configure the associated logical interfaces with the inet family. Doing so could cause 
the logical interfaces to drop packets. 


To configure a PE switch with a VLAN CCC and an MPLS-based connections: 
1. Configure OSPF (or IS-IS) on the loopback (or switch address) and core interfaces: 


[edit protocols] 





user@switch# set ospf area 0.0.0.0 interface lo0.0 


user@switch# set ospf area 0.0.0.0 interface interface-name 





user@switch# set ospf area 0.0.0.0 interface interface-name 











user@switch# set ospf area 0.0.0.0 interface interface-name 
2. Enable traffic engineering for the routing protocol: 


[edit protocols] 


1344 


user@switch# set ospf traffic-engineering 
3. Configure an IP address for the loopback interface and for the core interfaces: 


[edit] 
user@switch# set interfaces loO unit logical-unit-number family inet address address 


user@switch# set interfaces interface-name unit logical-unit-number family inet address address 








user@switch# set interfaces interface-name unit logical-unit-number family inet address address 








user@switch# set interfaces interface-name unit logical-unit-number family inet address address 


4. Enable the MPLS protocol with cspf disabled: 


NOTE: CSPF is a shortest-path-first algorithm that has been modified to take into account 
specific restrictions when the shortest path across the network is calculated. You need to 
disable CSPF for link protection to function properly on interarea paths. 


[edit protocols] 
user@switch# set mpls no-cspf 


5. Enable VLAN tagging on the customer edge interface of the local PE switch: 


[edit] 
user@switch# set interfaces interface-name vlan-tagging 


6. Configure the customer edge interface to use encapsulation vlan-ccc: 


[edit] 
user@switch# set interfaces interface-name encapsulation vlan-ccc 


7. Configure the logical unit of the customer edge interface with a VLAN ID: 


NOTE: The VLAN ID cannot be configured on logical interface unit 0. 


The same VLAN ID must be used when configuring the customer edge interface on the other 
PE switch. 


[edit ] 
user@switch# set interfaces interface-name logical-unit-numberrbhadran vian-id 


8. Define the label switched path (LSP): 
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[edit protocols] 
user@switch# set mpls label-switched-path Isp-name from address 


user@switch# set mpls label-switched-path Isp-name to address 


TIP: You will need to use the specified LSP name again when configuring the CCC. 


9. Configure the connection between the two circuits in the CCC connection 


[edit protocols] 
user@switch# set connections remote-interface-switch interface-switch interface local-interface 
user@switch# set connections remote-interface-switch interface-switch transmit-Isp destination-Isp 


user@switch# set connections remote-interface-switch interface-switch receive-Isp source-Isp 


Configuring CCC Switching for Point-to-Multipoint LSPs 


IN THIS SECTION 


@ = Configuring the Point-to-Multipoint LSP Switch on Ingress PE Routers | 1346 
@ Configuring Local Receivers on a Point-to-Multipoint CCC LSP Switch on Ingress PE Routers | 1346 
® Configuring the Point-to-Multipoint LSP Switch on Egress PE Routers | 1346 


You can configure circuit cross-connect (CCC) between two circuits to switch traffic from interfaces to 
point-to-multipoint LSPs. This feature is useful for handling multicast or broadcast traffic (for example, a 
digital video stream). 


To configure CCC switching for point-to-multipoint LSPs, you do the following: 


e On the ingress provider edge (PE) router, you configure CCC to switch traffic from an incoming interface 


to a point-to-multipoint LSP. 


e On the egress PE, you configure CCC to switch traffic from an incoming point-to-multipoint LSP to an 


outgoing interface. 
The CCC connection for point-to-multipoint LSPs is unidirectional. 
For more information about point-to-multipoint LSPs, see “Point-to-Multipoint LSPs Overview” on page 657. 


To configure a CCC connection for a point-to-multipoint LSP, complete the steps in the following sections: 
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Configuring the Point-to-Multipoint LSP Switch on Ingress PE Routers 


To configure the ingress PE router with a CCC switch for a point-to-multipoint LSP, include the 
p2mp-transmit-switch statement: 


p2mp-transmit-switch switch-name { 
input-interface input-interface-name.unit-number; 
transmit-p2mp-lsp transmitting-Isp; 


You can include the p2mp-transmit-switch statement at the following hierarchy levels: 

e [edit protocols connections] 

e [edit logical-systems logical-system-name protocols connections] 

switch-name specifies the name of the ingress CCC switch. 

input-interface input-interface-name.unit-number specifies the name of the ingress interface. 


transmit-p2mp-lsp transmitting-Isp specifies the name of the transmitting point-to-multipoint LSP. 


Configuring Local Receivers on a Point-to-Multipoint CCC LSP Switch on Ingress PE Routers 


In addition to configuring an incoming CCC interface to a point-to-multipoint LSP on an ingress PE router, 
you can also configure CCC to switch traffic on an incoming CCC interface to one or more outgoing CCC 
interfaces by configuring output interfaces as local receivers. 


To configure output interfaces, include the output-interface statement at the [edit protocols connections 
p2mp-transmit-switch p2mp-transmit-switch-name] hierarchy level. 


[edit protocols connections] 

p2mp-transmit-switch pc-ccc { 
input-interface fe-1/3/1.0; 
transmit-p2mp-Isp myp2mp; 
output-interface [fe-1/3/2.0 fe-1/3/3.0]; 


You can configure one or more output interfaces as local receivers on the ingress PE router using this 
statement. 


Use the show connections p2mp-transmit-switch (extensive | history | status), show route ccc 
<interface-name> (detail | extensive), and show route forwarding-table ccc <interface-name> (detail | 
extensive) commands to view details of the local receiving interfaces on the ingress PE router. 


Configuring the Point-to-Multipoint LSP Switch on Egress PE Routers 


To configure the CCC switch for a point-to-multipoint LSP on the egress PE router, include the 
p2mp-receive-switch statement. 
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p2mp-receive-switch switch-name { 
output-interface [ output-interface-name.unit-number ]; 
receive-p2mp-lIsp receptive-Isp; 


You can include this statement at the following hierarchy levels: 


e [edit protocols connections] 


e [edit logical-systems logical-system-name protocols connections] 
switch-name specifies the name of the egress CCC switch. 
output-interface [ output-interface-name.unit-number | specifies the name of one or more egress interfaces. 


receive-p2mp-Isp receptive-Isp specifies the name of the receptive point-to-multipoint LSP. 


Configuring an MPLS-Based VLAN CCC Using a Layer 2 VPN (CLI Procedure) 


You can configure an 802.1Q VLAN as an MPLS-based Layer 2 virtual private network (VPN) using EX8200 
and EX4500 switches to interconnect multiple customer sites with Layer 2 technology. 


This topic describes configuring provider edge (PE) switches in an MPLS network using a circuit 
cross-connect (CCC) on a tagged VLAN interface (802.1Q VLAN) rather than a simple interface. 


NOTE: You do not need to make any changes to existing provider switches in your MPLS network 
to support this type of configuration. For information on configuring provider switches, see 
“Configuring MPLS on EX8200 and EX4500 Provider Switches” on page 78. 


NOTE: You can send any kind of traffic over a CCC, including nonstandard bridge protocol data 
units (BPDUs) generated by other vendors’ equipment. 


NOTE: If you configure a physical interface as VLAN-tagged and with the vlan-ccc encapsulation, 
you cannot configure the associated logical interfaces with the inet family. Doing so could cause 
the logical interfaces to drop packets. 


To configure a PE switch with a VLAN CCC and an MPLS-based Layer 2 VPN: 
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. Configure OSPF (or IS-IS) on the loopback (or switch address) and core interfaces: 


[edit protocols] 
user@switch# set ospf area 0.0.0.0 interface lo0.0 
user@switch# set ospf area 0.0.0.0 interface interface-name 


user@switch# set ospf area 0.0.0.0 interface interface-name 





user@switch# set ospf area 0.0.0.0 interface interface-name 


. Enable traffic engineering for the routing protocol: 


[edit protocols] 


user@switch# set ospf traffic-engineering 
. Configure an IP address for the loopback interface and for the core interfaces: 


[edit] 





user@switch# set interfaces loO unit logical-unit-number family inet address address 





user@switch# set interfaces interface-name unit logical-unit-number family inet address address 


user@switch# set interfaces interface-name unit logical-unit-number family inet address address 











user@switch# set interfaces interface-name unit logical-unit-number family inet address address 


. Enable the MPLS protocol with cspf disabled: 


NOTE: CSPF is a shortest-path-first algorithm that has been modified to take into account 
specific restrictions when the shortest path across the network is calculated. You need to 
disable CSPF for link protection to function properly on interarea paths. 


[edit protocols] 


user@switch# set mpls no-cspf 
. Define the label switched path (LSP): 


[edit protocols] 


user@switch# set mpls label-switched-path Isp_name to address 


TIP: You will need to use the specified LSP name again when configuring the CCC. 


. Configure MPLS on the core interfaces: 
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[edit protocols] 
user@switch# set mpls interface interface-name 
user@switch# set mpls interface interface-name 


user@switch# set mpls interface interface-name 
7. Configure RSVP on the loopback interface and the core interfaces: 


[edit protocols] 





user@switch# set rsvp interface lo0.0 





user@switch# set rsvp interface interface-name 


user@switch# set rsvp interface interface-name 








user@switch# set rsvp interface interface-name 
8. Configure family mpls on the logical units of the core interfaces: 


[edit] 


user@switch# set interfaces interface-name unit logical-unit-number family mpls 





user@switch# set interfaces interface-name unit logical-unit-number family mpls 











user@switch# set interfaces interface-name unit logical-unit-number family mpls 


NOTE: You can enable family mpls on either individual interfaces or aggregated Ethernet 
interfaces. You cannot enable it on tagged VLAN interfaces. 


9. Enable VLAN tagging on the customer edge interface of the local PE switch: 


[edit] 


user@switch# set interfaces interface-name vlan-tagging 
10. Configure the customer edge interface to use encapsulation vlan-ccc: 


[edit] 


user@switch# set interfaces interface-name encapsulation vlan-ccc 


11. Configure the logical unit of the customer edge interface with a VLAN ID: 
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NOTE: The VLAN ID cannot be configured on logical interface unit 0. The logical unit number 
must be 1 or higher. 


The same VLAN ID must be used when configuring the customer edge interface on the other 
PE switch. 


[edit ] 
user@switch# set interfaces interface-name logical-unit-numbervlan-id vlan-id 


12. Configure BGP, specifying the loopback address as the local address and enabling family I2vpn signaling: 


[edit protocols bgp] 
user@switchPE1 # set local-address address family I2vpn signaling 





13. Configure the BGP group, specifying the group name and type: 


[edit protocols bgp] 





user@switchPE1# set group ibgp type internal 


14. Configure the BGP neighbor, specifying the loopback address of the remote PE switch as the neighbor's 


address: 


[edit protocols bgp] 
user@switchPE1# set neighbor address 





15. Configure the routing instance, specifying the routing-instance name and using I2vpn as the instance 


type: 


[edit routing-instances] 


user@switchPE1# set routing-instance-name instance-type I2vpn 





16. Configure the routing instance to apply to the customer edge interface: 


[edit routing-instances] 


user@switchPE]1 # set routing-instance-name interface interface-name 





17. Configure the routing instance to use a route distinguisher: 


[edit routing-instances] 


user@switchPE1 # set routing-instance-name route-distinguisher address 





18. Configure the VPN routing and forwarding (VRF) target of the routing instance: 
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[edit routing-instances] 
E1# set routing-instance-name vrf-target community 





user@switchP 


NOTE: You can create more complex policies by explicitly configuring VRF import and export 
policies using the import and export options. See the Junos OS VPNs Configuration Guide. 


19. Configure the protocols and encapsulation type used by the routing instance: 


[edit routing-instances] 
E.1# set routing-instance-name protocols |2vpn encapsulation-type ethernet-vlan 





user@switchP 


20. Apply the routing instance to a customer edge interface and specify a description for it: 


[edit routing-instances] 
set routing-instance-name protocols interface interface-name description description 

















user@switchPE1 
21. Configure the routing-instance protocols site: 


[edit routing-instances] 
E.1# set routing-instance-name protocols |2vpn site site-name site-identifier identifier 





user@switchP 


remote-site-id identifier 


NOTE: The remote site ID (configured with the remote-site-id statement) corresponds to 
the site ID (configured with the site-identifier statement) configured on the other PE switch. 


When you have completed configuring one PE switch, follow the same procedures to configure the other 


PE switch. 


NOTE: You must use the same type of switch for the other PE switch. You cannot use an EX8200 
as one PE switch and use an EX3200 or EX4200 as the other PE switch. 
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Release History Table 


Release Description 


20.1R1 Starting in Junos OS Release 20.1R1, aggregated Ethernet interfaces support VLAN translational 
cross-connect (TCC) encapsulation. 


19.3R1 Starting in Junos OS Release 19.3R1, you can leverage the hardware support available for 
cross-connects on the ACX5448 device with the Layer 2 local switching functionality using 
certain models. With this support, you can provide the EVP and Ethernet Virtual Private Line 
(EVPL) services. 


17.1R1 Support for VPN service as the customer is supported on QFX10000 switches starting with 
Junos OS Release 17.1R1. 
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PCEP Overview 


A Path Computation Element (PCE) is an entity (component, application, or network node) that is capable 
of computing a network path or route based on a network graph and applying computational constraints. 
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A Path Computation Client (PCC) is any client application requesting a path computation to be performed 
by a PCE. The Path Computation Element Protocol (PCEP) enables communications between a PCC and 
a PCE, or between two PCEs (defined in RFC 5440). 


PCEP is a TCP-based protocol defined by the IETF PCE Working Group, and defines a set of messages 
and objects used to manage PCEP sessions and to request and send paths for multidomain traffic engineered 
LSPs (TE LSPs). It provides a mechanism for a PCE to perform path computation for a PCC’s external LSPs. 
The PCEP interactions include LSP status reports sent by the PCC to the PCE, and PCE updates for the 
external LSPs. 


Figure 116 on page 1355 illustrates the role of PCEP in the client-side implementation of a stateful PCE 
architecture in an MPLS RSVP-TE enabled network. 


Figure 116: PCEP Session 
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A TCP-based PCEP session connects a PCC to an external PCE. The PCC initiates the PCEP session and 
stays connected to the PCE for the duration of the PCEP session. During the PCEP session, the PCC 
requests LSP parameters from the stateful PCE. On receiving one or more LSP parameters from the PCE, 
the PCC re-signals the TE LSP. When the PCEP session is terminated, the underlying TCP connection is 
closed immediately, and the PCC attempts to re-establish the PCEP session. 


Thus, the PCEP functions include: 


e LSP tunnel state synchronization between a PCC and a stateful PCE—When an active stateful PCE 
connection is detected, a PCC tries to delegate all LSPs to this PCE in a procedure called LSP state 
synchronization. PCEP enables synchronization of the PCC LSP state to the PCE. 


e Delegation of control over LSP tunnels to a stateful PCE—An active stateful PCE controls one or more 
LSP attributes for computing paths, such as bandwidth, path (ERO), and priority (setup and hold). PCEP 
enables such delegation of LSPs for path computation. 


e Stateful PCE control of timing and sequence of path computations within and across PCEP sessions-An 
active stateful PCE modifies one or more LSP attributes, such as bandwidth, path (ERO), and priority 
(setup and hold). PCEP communicates these new LSP attributes from the PCE to the PCC, after which 
the PCC re-signals the LSP in the specified path. 
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Understanding MPLS RSVP-TE 


Traffic engineering (TE) deals with performance optimization of operational networks, mainly mapping 


traffic flows onto an existing physical topology. Traffic engineering provides the ability to move traffic 


flow away from the shortest path selected by the interior gateway protocol (IGP) and onto a potentially 


less congested physical path across a network. 


For traffic engineering in large, dense networks, MPLS capabilities can be implemented because they 


potentially provide most of the functionality available from an overlay model, in an integrated manner, 


and at a lower cost than the currently competing alternatives. The primary reason for implementing MPLS 


traffic engineering is to control paths along which traffic flows through a network. The main advantage of 


implementing MPLS traffic engineering is that it provides a combination of the traffic engineering capabilities 
of ATM, along with the class-of-service (CoS) differentiation of IP. 


In an MPLS network, data plane information is forwarded using label switching. A packet arriving ona 
provider edge (PE) router from the customer edge (CE) router has labels applied to it, and it is then forwarded 


to the egress PE router. The labels are removed at the egress router and it is then forwarded out to the 


appropriate destination as an IP packet. The label-switching routers (LSRs) in the MPLS domain use label 
distribution protocols to communicate the meaning of labels used to forward traffic between and through 
the LSRs. RSVP-TE is one such label distribution protocol that enables an LSR peer to learn about the label 
mappings of other peers. 


When both MPLS and RSVP are enabled on a router, MPLS becomes a client of RSVP. The primary purpose 
of the Junos OS RSVP software is to support dynamic signaling within label-switched paths (LSPs). RSVP 
reserves resources, such as for IP unicast and multicast flows, and requests quality-of-service (QoS) 
parameters for applications. The protocol is extended in MPLS traffic engineering to enable RSVP to set 
up LSPs that can be used for traffic engineering in MPLS networks. 


When MPLS and RSVP are combined, labels are associated with RSVP flows. Once an LSP is established, 
the traffic through the path is defined by the label applied at the ingress node of the LSP. The mapping of 
label to traffic is accomplished using different criteria. The set of packets that are assigned the same label 
value by a specific node belong to the same forwarding equivalence class (FEC), and effectively define the 
RSVP flow. When traffic is mapped onto an LSP in this way, the LSP is called an LSP tunnel. 


LSP tunnels are a way to establish unidirectional label-switched paths. RSVP-TE builds on the RSVP core 
protocol by defining new objects and modifying existing objects used in the PATH and RESV objects for 
LSP establishment. The new objects—LABEL-REQUEST object (LRO), RECORD-ROUTE object (RRO), 
LABEL object, and EXPLICIT-ROUTE object (ERO)—are optional with respect to the RSVP protocol, except 
for the LRO and LABEL objects, which are both mandatory for establishing LSP tunnels. 


In general, RSVP-TE establishes a label-switched path that ensures frame delivery from ingress to egress 
router. However, with the new traffic engineering capabilities, the following functions are supported in 
an MPLS domain: 


Possibility to establish a label-switched path using either a full or partial explicit route (RFC 3209). 


Constraint-based LSP establishment over links that fulfill requirements, such as bandwidth and link 


properties. 


Endpoint control, which is associated with establishing and managing LSP tunnels at the ingress and 


egress routers. 


Link management, which manages link resources to do resource-aware routing of traffic engineering 
LSPs and to program MPLS labels. 


e MPLS fast reroute (FRR), which manages the LSPs that need protection and assigns backup tunnel 
information to these LSPs. 
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Current MPLS RSVP-TE Limitations 


Although the RSVP extensions for traffic engineering enable better network utilization and meet 


requirements of classes of traffic, today’s MPLS RSVP-TE protocol suite has several issues inherent to its 


distributed nature. This causes a number of issues during contention for bisection capacity, especially 


within an LSP priority class where a subset of LSPs share common setup and hold priority values. The 
limitations of RSVP-TE include: 


Lack of visibility of individual per-LSP, per-device bandwidth demands—The ingress routers in an MPLS 
RSVP-TE network establish LSPs without having a global view of the bandwidth demand on the network. 
Information about network resource utilization is only available as total reserved capacity by traffic class 
on a per interface basis. Individual LSP state is available locally on each label edge router (LER) for its 
own LSPs only. As a result, a number of issues related to demand pattern arise, particularly within a 
common setup and hold priority. 


Asynchronous and independent nature of RSVP signaling—In RSVP-TE, the constraints for path 
establishment are controlled by an administrator. As such, bandwidth reserved for an LSP tunnel is set 
by the administrator and does not automatically imply any limit on the traffic sent over the tunnel. 
Therefore, bandwidth available on a traffic engineering link is the bandwidth configured for the link, 
excluding the sum of all reservations made on the link. Thus, the unsignaled demands on an LSP tunnel 
lead to service degradation of the LSP requiring excess bandwidth, as well as the other LSPs that comply 
with the bandwidth requirements of the traffic engineering link. 


LSPs established based on dynamic or explicit path options in the order of preference—The ingress 
routers inan MPLS RSVP-TE network establish LSPs for demands based on the order of arrival. Because 
the ingress routers do not have a global view of the bandwidth demand on the network, using the order 
of preference to establish LSPs can cause traffic to be dropped or LSPs not being established at all when 
there is an excess of bandwidth demand. 


As an example, Figure 117 on page 1359 is configured with MPLS RSVP-TE, in which A and G are the label 
edge routers (LERs). These ingress routers establish LSPs independently based on the order of demands 


and have no knowledge or control over each other’s LSPs. Routers B, C, and D are intermediate or transit 


routers that connect to the egress routers E and F. 
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Figure 117: Example MPLS Traffic Engineering 
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The ingress routers establish LSPs based on the order in which the demands arrive. If Router G receives 
two demands of capacity 5 each for G-F, then G signals two LSPs - LSP1 and LSP2 - through G-B-D-F. 
In the same way, when Router A receives the third demand of capacity 10 for A-E, then it signals an LSP, 
LSP3, through A-B-C-E. However, if the demand on the A-E LSP increases from 10 to 15, Router A cannot 
signal LSP3 using the same (A-B-C-E) path, because the B-C link has a lower capacity. 


Router A should have signaled the increased demand on LSP3 using the A-B-D-C-E path. Since LSP1 and 
LSP2 have utilized the B-D link based on the order of demands received, LSP3 is not signaled. 


Thus, although adequate max-flow bandwidth is available for all the LSPs, LSP3 is subject to potentially 
prolonged service degradation. This is due to Router A’s lack of global demand visibility and the lack of 
systemic coordination in demand placement by the ingress routers A and G. 


Use of an External Path Computing Entity 


As a solution to the current limitations found in the MPLS RSVP-TE path computation, an external path 
computing entity with a global view of per-LSP, per-device demand in the network independent of available 
capacity is required. 


Currently, only online and real-time constraint-based routing path computation is provided in an MPLS 
RSVP-TE network. Each router performs constraint-based routing calculations independent of the other 
routers in the network. These calculations are based on currently available topology information—information 
that is usually recent, but not completely accurate. LSP placements are locally optimized, based on current 
network status. The MPLS RSVP-TE tunnels are set up using the CLI. An operator configures the TE LSP, 
which is then signaled by the ingress router. 


In addition to the existing traffic engineering capabilities, the MPLS RSVP-TE functionality is extended to 
include an external path computing entity, called the Path Computation Element (PCE). The PCE computes 
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the path for the TE LSPs of ingress routers that have been configured for external control. The ingress 
router that connects to a PCE is called a Path Computation Client (PCC). The PCC is configured with the 
Path Computation Client Protocol (PCEP) to facilitate external path computing by a PCE. 


For more information, see “Components of External Path Computing” on page 1360. 


To enable external path computing for a PCC’s TE LSPs, include the Isp-external-controller pccd statement 
at the [edit mpls] and [edit mpls Isp Isp-name] hierarchy levels. 


Components of External Path Computing 


IN THIS SECTION 


@ ~=Path Computation Element | 1360 
@ Path Computation Client | 1361 


@ Path Computation Element Protocol | 1362 


The components that make up an external path computing system are: 


Path Computation Element 


A Path Computation Element (PCE) can be any entity (component, application, or network node) that is 
capable of computing a network path or route based on a network graph and applying computational 
constraints. However, a PCE can compute the path for only those TE LSPs of a PCC that have been 
configured for external control. 


A PCE can either be stateful or stateless. 


e Stateful PCE—A stateful PCE maintains strict synchronization between the PCE and network states (in 
terms of topology and resource information), along with the set of computed paths and reserved resources 
in use in the network. In other words, a stateful PCE utilizes information from the traffic engineering 
database as well as information about existing paths (for example, TE LSPs) in the network when 
processing new requests from the PCC. 


A stateful PCE is of two types: 


e Passive stateful PCE—Maintains synchronization with the PCC and learns the PCC LSP states to better 
optimize path calculations, but does not have control over them. 


e Active stateful PCE—Actively modifies the PCC LSPs, in addition to learning about the PCC LSP states. 
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NOTE: Ina redundant configuration with main and backup active stateful PCEs, the backup 
active stateful PCE cannot modify the attributes of delegated LSPs until it becomes the main 
PCE at the time of a failover. There is no preempting of PCEs in the case of a switchover. 
The main PCE is backed by a backup PCE, and when the main PCE goes down, the backup 
PCE assumes the role of the main PCE and remains the main PCE even after the PCE that 
was previously the main PCE is operational again. 


A stateful PCE provides the following functions: 


e Offers offline LSP path computation. 
e Triggers LSP re-route when there is a need to re-optimize the network. 
e Changes LSP bandwidth when there is an increase in bandwidth demand from an application. 


e Modifies other LSP attributes on the router, such as ERO, setup priority, and hold priority. 


A PCE has a global view of the bandwidth demand in the network and maintains a traffic-engineered 
database to perform path computations. It performs statistics collection from all the routers in the MPLS 
domain using SNMP and NETCOMF. This provides a mechanism for offline control of the PCC’s TE LSPs. 
Although an offline LSP path computation system can be embedded in a network controller, the PCE 
acts like a full-fledged network controller that provides control over the PCC’s TE LSPs, in addition to 
computing paths. 


Although a stateful PCE allows for optimal path computation and increased path computation success, 
it requires reliable state synchronization mechanisms, with potentially significant control plane overhead 
and the maintenance of a large amount of data in terms of states, as in the case of a full mesh of TE 
LSPs. 


e Stateless PCE—A stateless PCE does not remember any computed path, and each set of requests is 
processed independently of each other (RFC 5440). 


Path Computation Client 


A Path Computation Client (PCC) is any client application requesting a path computation to be performed 
by a PCE. 


A PCC can connect to a maximum of 10 PCEs at one time. The PCC to PCE connection can be a configured 
static route or a TCP connection that establishes reachability. The PCC assigns each connected PCE a 
priority number. It sends a message to all the connected PCEs with information about its current LSPs, in 
a process called LSP state synchronization. For the TE LSPs that have external control enabled, the PCC 
delegates those LSPs to the main PCE. The PCC elects, as the main PCE, a PCE with the lowest priority 
number, or the PCE that it connects to first in the absence of a priority number. 
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The PCC re-signals an LSP based on the computed path it receives from a PCE. When the PCEP session 
with the main PCE is terminated, the PCC elects a new main PCE, and all delegated LSPs to the previously 
main PCE are delegated to the newly available main PCE. 


Path Computation Element Protocol 


The Path Computation Element Protocol (PCEP) is used for communication between PCC and PCE (as 
well as between two PCEs) (RFC 5440). PCEP is a TCP-based protocol defined by the IETF PCE Working 
Group, and defines a set of messages and objects used to manage PCEP sessions and to request and send 
paths for multidomain TE LSPs. The PCEP interactions include PCC messages, as well as notifications of 
specific states related to the use of a PCE in the context of MPLS RSVP-TE. When PCEP is used for 
PCE-to-PCE communication, the requesting PCE assumes the role of a PCC. 


Thus, the PCEP functions include: 
e LSP tunnel state synchronization between PCC and a stateful PCE. 


e Delegation of control over LSP tunnels to a stateful PCE. 


Interaction Between a PCE and a PCC Using PCEP 


Figure 118 on page 1362 illustrates the relationship between a PCE, PCC, and the role of PCEP in the context 
of MPLS RSVP-TE. 


Figure 118: PCC and RSVP-TE 
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The PCE to PCC communication is enabled by the TCP-based PCEP. The PCC initiates the PCEP session 
and stays connected to a PCE for the duration of the PCEP session. 
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NOTE: Starting with Junos OS Release 16.1, you can secure a PCEP session using TCP-MD5 
authentication as per RFC 5440. To enable the MD5 security mechanism for a PCEP session, it 
is recommended that you define and bind the MD5 authentication key at the [edit protocols 
pcep pce pce-id] hierarchy level for a PCEP session. You can, however, also use a predefined 
keychain from the [edit security authentication-key-chains key-chain] hierarchy level to secure 
a PCEP session. In this case, you should bind the predefined keychain into the PCEP session at 
the [edit protocols pcep pce pce-id] hierarchy level. 


The PCE and PCC use the same key to verify the authenticity of each segment sent on the TCP 
connection of the PCEP session, thereby securing the PCEP communication between the devices, 
which might be subject to attacks and can disrupt services on the network. 


For more information on securing PCEP sessions using MD5 authentication, see “TCP-MD5 
Authentication for PCEP Sessions” on page 1371. 


Once the PCEP session is established, the PCC performs the following tasks: 


1. LSP state synchronization—The PCC sends information about all the LSPs (local and external) to all 
connected PCEs. For external LSPs, the PCC sends information about any configuration change, RRO 
change, state change, and so on, to the PCE. 


For PCE-initiated LSPs, there is no LSP configuration present on the PCC. The PCE initiating the LSP 
sends the LSP parameters to the PCC that has indicated its capability of supporting PCE-initiated LSPs. 


NOTE: Support for PCE-initiated LSPs is provided in Junos OS Release 13.3 and later releases. 


2. LSP delegation—After the LSP state information is synchronized, the PCC then delegates the external 
LSPs to one PCE, which is the main active stateful PCE. Only the main PCE can set parameters for the 
external LSP. The parameters that the main PCE modifies include bandwidth, path (ERO), and priority 
(setup and hold). The parameters specified in the local configuration are overridden by the parameters 
that are set by the main PCE. 


NOTE: When the PCEP session with the main PCE is terminated, the PCC elects a new main 
PCE, and all delegated LSPs to the previously main PCE are delegated to the newly available 
main PCE. 


In the case of PCE-initiated LSPs, the PCC creates the LSP using the parameters received from the 
PCE. The PCC assigns the PCE-initiated LSP a unique LSP-ID, and automatically delegates the LSP to 
the PCE. A PCC cannot revoke the delegation for the PCE-initiated LSPs for an active PCEP session. 


When a PCEP session terminates, the PCC starts two timers without immediately deleting the 
PCE-initiated LSPs - delegation cleanup timeout and Isp cleanup timer - to avoid disruption of services. 
During this time, an active stateful PCE can acquire control of the LSPs provisioned by the failed PCE, 
by sending a create request for the LSP. 


Control over PCE-initiated LSPs reverts to the PCC at the expiration of the delegation cleanup timeout. 
When the delegation cleanup timeout expires, and no other PCE has acquired control over the LSP 
from the failed PCE, the PCC takes local control of the non-delegated PCE-initiated LSP. Later, when 
the original or a new active stateful PCE wishes to acquire control of the locally controlled PCE-initiated 
LSPs, the PCC delegates these LSPs to the PCE and the Isp cleanup timer timer is stopped. 


A PCE may return the delegation of the PCE-initiated LSP to the PCC to allow LSP transfer between 
PCEs. This triggers the Isp cleanup timer for the PCE-initiated LSP. The PCC waits for the LSP cleanup 
timer to expire before removing the non-delegated PCE-initiated LSPs from the failed PCE. 


When the Isp cleanup timer expires, and no other PCE has acquired control over the LSPs from the 
failed PCE, the PCC deletes all the LSPs provisioned by the failed PCE. 


NOTE: In compliance with draft-ietf-pce-stateful-pce-09, revoking of PCE-initiated LSP 
delegations by a PCC happens in a make-before-break fashion before the LSPs are redelegated 
to an alternate PCE. Starting in Junos OS Release 18.1R1, the Isp-cleanup-timer must be 
greater than or equal to the delegation-cleanup-timeout for the PCC to revoke the LSP 
delegations. If not, the redelegation timeout interval for the PCC can be set to infinity, where 
the LSP delegations to that PCE remain intact until specific action is taken by the PCC to 
change the parameters set by the PCE. 


3. LSP signaling—On receiving one or more LSP parameters from the main active stateful PCE, the PCC 
re-signals the TE LSP based on the PCE provided path. If the PCC fails to set up the LSP, it notifies the 
PCE of the setup failure and waits for the main PCE to provide new parameters for that LSP, and then 
re-signals it. 


When the PCE specifies a path that is incomplete or has loose hops where only the path endpoints are 
specified, the PCC does not perform local constraint-based routing to find out the complete set of 
hops. Instead, the PCC provides RSVP with the PCE provided path, as it is, for signaling, and the path 
gets set up using IGP hop-by-hop routing. 


Considering the topology used in Figure 117 on page 1359, Figure 119 on page 1365 illustrates the partial 
client-side PCE implementation in the MPLS RSVP-TE enabled network. The ingress routers A and G are 
the PCCs that are configured to connect to the external stateful PCE through a TCP connection. 


The PCE has a global view of the bandwidth demand in the network and performs external path 
computations after looking up the traffic engineering database. The active stateful PCE then modifies one 
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or more LSP attributes and sends an update to the PCC. The PCC uses the parameters it receives from 
the PCE to re-signal the LSP. 


Figure 119: Example PCE for MPLS RSVP-TE 
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This way, the stateful PCE provides a cooperative operation of distributed functionality used to address 
specific challenges of a shortest interdomain constrained path computation. It eliminates congestion 
scenarios in which traffic streams are inefficiently mapped onto available resources, causing overutilization 
of some subsets of network resources, while other resources remain underutilized. 


LSP Behavior with External Computing 


IN THIS SECTION 


@ LSP Types | 1365 
@ LSP Control Mode | 1366 


LSP Types 


In a client-side PCE implementation, there are three types of TE LSPs: 


e CLI-controlled LSPs—The LSPs that do not have the Isp-external-controller pccd statement configured 
are called CLI-controlled LSPs. Although these LSPs are under local control, the PCC updates the 
connected PCEs with information about the CLI-controlled LSPs during the initial LSP synchronization 
process. After the initial LSP synchronization, the PCC informs the PCE of any new and deleted LSPs as 
well. 
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e PCE-controlled LSPs—The LSPs that have the Isp-external-controller pccd statement configured are 
called PCE-controlled LSPs. The PCC delegates the PCC-initiated LSPs to the main PCE for external path 
computation. 


The PCC informs the PCE about the configured parameters of a PCE-controlled LSP, such as bandwidth, 
ERO, and priorities. It also informs the PCE about the actual values used for these parameters to set up 
the LSP including the RRO, when available. 


The PCC sends such LSP status reports to the PCE only when a reconfiguration has occurred or when 
there is a change in the ERO, RRO, or status of the PCE-controlled LSPs under external control. 


There are two types of parameters that come from the CLI configuration of an LSP for a PCE: 


e Parameters that are not overridden by a PCE, and that are applied immediately. 


e Parameters that are overridden by a PCE. These parameters include bandwidth, path, and priority 
(setup and hold values). When the control mode switches from external to local, the CLI-configured 
values for these parameters are applied at the next opportunity to re-signal the LSP. The values are 
not applied immediately. 


Externally-provisioned LSPs (or PCE-initiated LSPs)—The LSPs that have the Isp-provisioning statement 
configured are called PCE-initiated LSPs. A PCE-initiated LSP is dynamically created by an external PCE; 
as a result, there is no LSP configuration present on the PCC. The PCC creates the PCE-initiated LSP 
using the parameters provided by the PCE, and automatically delegates the LSP to the PCE. 


NOTE: Support for PCE-initiated LSPs is provided in Junos OS Release 13.3 and later releases. 


The CLI-controlled LSPs, PCE-controlled LSPs, and PCE-initiated LSPs can coexist on a PCC. 


The CLI-controlled LSPs and PCE-controlled LSPs can coexist on a PCC. 


LSP Control Mode 


In a client-side PCE implementation, there are two types of control modes for a PCC-controlled LSP: 


e External—By default, all PCE-controlled LSPs are under external control. When an LSP is under external 
control, the PCC uses the PCE-provided parameters to set up the LSP. 


e Local—A PCE-controlled LSP can come under local control. When the LSP switches from external control 
to local control, path computation is done using the CLI-configured parameters and constraint-based 
routing. Such a switchover happens only when there is a trigger to re-signal the LSP. Until then, the PCC 
uses the PCE-provided parameters to signal the PCE-controlled LSP, although the LSP remains under 
local control. 


A PCE-controlled LSP switches to local control from its default external control mode in cases such as no 
connectivity to a PCE or when a PCE returns delegation of LSPs back to the PCC. 


For more information about CLI-controlled LSPs and PCE-controlled LSPs, see “LSP Types” on page 1365. 
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Configuration Statements Supported for External Computing 


Table 32 on page 1367 lists the MPLS and existing LSP configuration statements that apply to a PCE-controlled 
LSP. 


Table 32: Applicability of MPLS and Existing LSP Configurations to a PCE-Controlled LSP 


Applicable LSP Applicable MPLS 
Configuration Configuration 
Support for PCE-Controlled LSP Statements Statements 
These configuration statements can be configured along = e admin-group e admin-group 
with the PCE configuration. However, they take effect only | ¢ auto-bandwidth e admin-groups 
when the peal Fentleuraten is in USE Brine PCE control, = hoplinik » sdminwrousexeniea 
these configuration statements remain inactive. 
e least-fill e hop-limit 
e most-fill e no-cspf 
e random e smart-optimize-timer 
These configuration statements can be configured along |= e bandwidth e priority 
with the PCE configuration, but are overridden by the e primary 
PCE-controlled LSP attributes. However, when the local + Bricns) 
configuration is in use, the configured values for these 
configuration statements are applied. 
NOTE: Changes to the local configuration using the CLI 
while the LSP is under the control of a stateful PCE do not 
have any effect on the LSP. These changes come into effect 
only when the local configuration is applied. 
These configuration statements cannot be configured along | e p2mp e p2mp-lsp-next-hop 
with the PCE configuration. e template 


The rest of the LSP configuration statements are applicable in the same way as for existing LSPs. On 
configuring any of the above configuration statements for a PCE-controlled LSP, an MPLS log message is 
generated to indicate when the configured parameters take effect. 


PCE-Controlled LSP Protection 


The protection paths, including fast reroute and bypass LSPs, are locally computed by the PCC using 
constraint-based routing. A stateful PCE specifies the primary path (ERO) only. A PCE can also trigger a 
non-standby secondary path, even if the local configuration does not have a non-standby secondary path 
for LSP protection. 


PCE-Controlled LSP ERO 


For PCE-controlled LSPs (PCC-delegated LSPs and PCE-initated LSPs), only a full-blown Explicit Route 
Object (ERO) object has to be sent from the PCE to the PCC; otherwise the PCC rejects the PCUpdate or 
PCCreate message for that PCEP session. 


Starting in Junos OS Release 17.2, in addition to external cspf, two new path computation types are 
introduced for the PCE-controlled LSPs: local cspf and no cspf. 


e local cspf—A PCC uses the local cspf computation type only when the PCE sends in a Juniper Vendor 
TLV (enterprise number: OxOa4c) of type 5. 


e no cspf—Neither the PCE nor the PCC performs a constrained path calculation. The endpoints and 
constraints are given to the RSVP module for setting up the LSP with the IGP path. 


A PCC uses no cspf computation type in the following cases: 


e When the PCE sends local cspf TLV, and when the Junos OS configuration or matching template for 
this LSP included no-cspf in the PCC-delegated LSP. 


e When the PCE sends local cspf TLV, and when the Junos OS configuration template for this LSP 
included no-cspf in the PCE-initiated LSP. 


e When the PCE does not send local cspf TLV with an empty ERO or loose ERO (with loose bit set in 
the ERO object). 


With these new computation types, a PCC can accept an ERO object either as a loose ERO, or as an empty 
ERO. An external path computing entity that is not capable of computing a path can modify parameters 
such as bandwidth and color, based on the analytics. In such cases, an empty ERO object or loose ERO is 
used and the path to be taken is decided by the PCC. 


PCE-Controlled Point-to-Multipoint RSVP-TE LSPs 


After a PCEP session is established between a PCE and a PCC, the PCC reports all the LSPs in the system 
to the PCE for LSP state synchronization. This includes PCC-controlled, PCE-delegated, and PCE-initiated 
point-to-point LSPs. Starting with Junos OS Release 15.1F6 and 16.1R1, this capability is extended to 
report point-to-multipoint LSPs as well. For a PCE, the point-to-multipoint LSP is similar to that of RSVP 
point-to-multipoint LSP, where the point-to-multipoint LSP is treated as collection of point-to-point LSPs 
grouped under a point-to-multipoint identifier. 


By default, PCE control of point-to-multipoint LSPs is not supported on a PCC. To add this capability, 
include the p2mp-Isp-report-capability statement at the [edit protocols pcep pce pce-name] or [edit 
protocols pcep pce-group group-id] hierarchy levels. After the point-to-multipoint report capability is 
configured on a PCC, the PCC advertises this capability to the PCE. If the PCE advertises the same 
point-to-multipoint report capability in return, then the PCC reports the complete point-to-multipoint LSP 
tree to the PCE for LSP state synchronization. 


A PCC with the point-to-multipoint TE LSP capability supports reporting of point-to-multipoint TE LSPs 
for stateful PCEs, point-to-multipoint update, and LSP database supporting point-to-multipoint LSP name 
as key. However, the following features and functions are not supported for Junos OS Release 15.1F6 
and 16.1: 


e Static point-to-multipoint LSPs 


e PCE-delegated and PCE-initiated point-to-multipoint LSPs 
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e Auto-bandwidth 

e TE++ 

e PCE request and reply message 

e Creation of point-to-multipoint LSPs using templates 

e Configuring forward entry on the PCE-initiated point-to-multipoint LSPs 


e Configuring forward entry on the router pointing to a provisioned LSP. 


PCE-Initiated Point-to-Point LSPs 


Starting with Junos OS Release 16.1, the PCEP functionality is extended to allow a stateful PCE to initiate 
and provision traffic engineering LSPs through a PCC. Earlier, the LSPs were configured on the PCC and 
the PCC delegated control over the external LSPs to a PCE. The ownership of the LSP state was maintained 
by the PCC. With the introduction of the PCE-initiated LSPs, a PCE can initiate and provision a traffic 
engineering point-to-point LSP dynamically without the need for a locally configured LSP on the PCC. On 
receiving a PCCreate message from a PCE, the PCC creates the PCE-initiated LSP and automatically 
delegates the LSP to the PCE. 


By default, a PCC rejects the request for provisioning PCE-initiated point-to-point LSPs from a PCE. To 
enable support of PCE-initated LSPs on the PCC, include the Isp-provisioning statement at the [edit protocols 
pcep pce pce-id] or [edit protocols pcep pce-group group-id] hierarchy levels. 


A PCC indicates its capability of supporting PCE-initiated point-to-point LSPs while establishing the Path 
Computation Element Protocol (PCEP) session with the PCE. A PCE selects a PCC with this capability to 
initiate an LSP. The PCE provides the PCC with the PCE-initiated LSP parameters. On receiving the 
PCE-initiated point-to-point LSP parameters, the PCC sets up the LSP, assigns an LSP ID, and automatically 
delegates the LSP to the PCE. 


When the PCE initiating the LSP does not provide the PCE-initiated point-to-point LSP parameters, the 
PCC uses the default parameters. An optional LSP template may also be configured to specify values for 
the PCE-initiated point-to-point LSP when the LSP parameters are not provided by the PCE. To configure 
an LSP template for PCE-initiated point-to-point LSPs on the PCC, include the label-switched-path-template 
statement at the [edit protocols mpls Isp-external-controller Isp-external-controller] hierarchy level. 


When a PCEP session terminates, the PCC starts two timers without immediately deleting the 
PCE-initiatedLSPs—delegation cleanup timeout and Isp cleanup timer—to avoid disruption of services. 
During this time, an active stateful PCE can acquire control of the LSPs provisioned by the failed PCE. 


A PCE may return the delegation of the PCE-initiated point-to-point LSP to the PCC to allow LSP transfer 
between PCEs. Control over PCE-initiated LSPs reverts to the PCC at the expiration of the delegation 
cleanup timeout. When the delegation cleanup timeout expires, and no other PCE has acquired control 
over the LSP from the failed PCE, the PCC takes local control of the non-delegated PCE-initiated LSP. 
Later, when the original or a new active stateful PCE wishes to acquire control of the locally controlled 
PCE-initiated point-to-point LSPs, the PCC delegates these LSPs to the PCE and the LSP cleanup timer is 
stopped. 
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The PCC waits for the LSP cleanup timer to expire before deleting the non-delegated PCE-initiated 
point-to-point LSPs from the failed PCE. When the LSP cleanup timer expires, and no other PCE has 
acquired control over the LSPs from the failed PCE, the PCC deletes all the LSPs provisioned by the failed 
PCE. 


PCE-Initiated Bypass LSP 


IN THIS SECTION 


@ ~~ Understanding PCE-Initiated Bypass LSPs | 1370 
@ Benefits of PCE-Initiated Bypass LSP | 1371 
@ Behavior of PCE-Initiated Bypass LSPs During PCEP Session Failure | 1371 


Understanding PCE-Initiated Bypass LSPs 


There can be traffic outages at the time of a link or node failure because the backup protection paths in 
the network do not have sufficient bandwidth to handle traffic. In such networks, although a PCE may be 
used to compute all the paths, to optimize network performance, the local protection paths also need to 
be controlled through the PCE. 


Junos OS Release 19.2R1 and later releases provide partial support for the Internet draft 
draft-cbrt-pce-stateful-local-protection-01 (expires December 2018), PCEP Extensions for RSVP-TE 
Local-Protection with PCE-Stateful, where the PCEP functionality is extended to allow a stateful PCE to 
initiate, provision, and manage bypass LSPs for a protected interface. Multiple bypass LSPs with bandwidth 
reservation can be initiated by the PCE to protect a link or node. The bandwidth on the bypass LSP is 
expected to be smaller than the total bandwidth of the primary LSPs that it might protect. 


The existing bypass selection mechanism, that prefers manual bypass LSPs (if available) over dynamic 
bypass LSPs, is extended to prefer PCE-provisioned bypass LSPs (if available) over dynamic bypass LSPs. 
The PCE-provisioned bypass LSPs have a higher preference over dynamic bypass LSPs, but are less preferred 
over manual bypass LSPs. 


The set of operations that are used to perform on any operational bypass LSPs, such as clear rsvp session, 
can also be performed on the PCE-initiated bypass LSPs. You can use commands, such as show 
path-computation-client status extensive and show path-computation-client Isp to view PCE-initiated 
bypass LSP statistics. 


With the support of PCE-initiated bypass LSP, you can: 


e Create a RSVP bypass LSP through PCEP from an external controller, where the bypass LSP: 
e can be for link or node protection. 


e must have a non-zero bandwidth. 
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e must have a specified strict ERO. 


e Update the bandwidth and ERO for an existing PCE-created bypass LSP. 


e Oversubscribe the bypass LSP bandwidth for admission control of primary LSPs. This must be a per-bypass 
parameter, and should allow updating the subscription per bypass LSP. 


Benefits of PCE-Initiated Bypass LSP 
The PCE-initiated bypass LSPs provide the following benefits: 


e Better control over traffic after a failure and more deterministic path computation of protection paths. 


e Meet complex constraints and diversity requirements, such as maintaining diverse paths for LSPs, as 
well as their local protection paths. 


e Ensure links are not overloaded during failure events. 


Behavior of PCE-Initiated Bypass LSPs During PCEP Session Failure 


At the time of a PCEP session failure, the PCE-initiated bypass LSPs become orphan until the expiration 
of the state timeout timer. The PCE-initiated bypass LSPs get cleaned up on the expiration of the state 
timeout timer. To obtain control of a PCE-initiated bypass LSP (after PCEP session fails), a PCE (either the 
primary PCE, or any secondary PCE) sends a PCInitiate message before the expiration of the state timeout 
timer. 


PCE-Initiated Point-to-Multipoint LSPs 


With the introduction of point-to-multipoint PCE-initiated LSPs, a PCE can initiate and provision a 
point-to-multipoint LSP dynamically without the need for local LSP configuration on the PCC. This enables 
the PCE to control the timing and sequence of the point-to-multipoint path computations within and across 
Path Computation Element Protocol (PCEP) sessions, thereby creating a dynamic network that is centrally 
controlled and deployed. 


For more information, see “Understanding Path Computation Element Protocol for MPLS RSVP-TE with 
Support for PCE-Initiated Point-to-Multipoint LSPs” on page 1427. 


Auto-Bandwidth and PCE-Controlled LSP 


Starting in Junos OS Release 14.2R4, support of auto-bandwidth is provided for PCE-controlled LSPs. In 
earlier releases, the auto-bandwidth option did not apply to PCE-controlled LSPs, although LSPs under 
the control of auto-bandwdith and constraint-based routing could coexist with PCE-controlled LSPs. The 
statistics collection for auto-bandwidth was taking effect only when the control mode of a PCE-controlled 
LSP changes from external to local. This was happening in cases such as no connectivity to a PCE or when 
a PCE returns delegation of LSPs back to the PCC. 


TCP-MD5 Authentication for PCEP Sessions 


A stateful PCE server automates the creation of traffic engineering paths across the network, increasing 
network utilization and enabling a customized programmable networking experience with the use of PCEP 
communication with a PCC. A PCC sends LSP reports to a PCE server, and the PCE updates or provisions 
LSPs back to the PCC. The data sent over a PCEP session is crucial for a PCE server to perform external 
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path computing. As a result, an attack on the PCEP communication can disrupt network services. If altered 
PCEP messages are sent to a PCC, inappropriate LSPs can be set up. Similarly, if altered PCEP messages 
are sent to a PCE, an incorrect view of the network is learned by the PCE. 


Considering the significance of the PCEP communication between a PCE and PCC in executing the PCE 
functionalities effectively, Junos OS Release 16.1 introduces the feature of securing a PCEP session using 
TCP-MD5 authentication as per RFC 5440. This feature protects the communication between a PCE and 
PCC over a PCEP session, which might be subject to an attack, and can disrupt network services. 


To enable the MD5 security mechanism for a PCEP session, it is recommended that you define and bind 
the MD5 authentication key at the [edit protocols pcep pce pce-id] hierarchy level for a PCEP session. 
You can, however, also use a predefined keychain from the [edit security authentication-key-chains 
key-chain] hierarchy level to secure a PCEP session. In this case, you should bind the predefined keychain 
into the PCEP session at the [edit protocols pcep pce pce-id] hierarchy level. 


The following configuration is executed on the PCC to establish a secure PCEP session with a PCE: 


e Using MD5 authentication key: 


[edit protocols pcep pce pce-id] 
user@PCC# set authentication-key key 


e Using predefined authentication keychain: 


[edit protocols pcep pce pce-id] 
user@PCC# set authentication-key-chain key-chain 
user@PCC# set authentication-algorithm md5 


For secure PCEP sessions to be established successfully, the MD5 authentication should be configured 
with the pre-shared authentication key on both the PCE server and the PCC. The PCE and PCC use the 
same key to verify the authenticity of each segment sent on the TCP connection of the PCEP session. 


NOTE: 

e Junos OS Release 16.1 supports only TCP-MD5 authentication for PCEP sessions, without 
extending support for TLS and TCP-AO, such as protection against eavesdropping, tampering, 
and message forgery. 


e Initial application of security mechanism to a PCEP session causes the session to reset. 


e If MD5 is misconfigured or not configured on one side of the PCEP session, the session does 
not get established. Verify that the configurations on the PCC and PCE are matching. 


e This feature does not provide support for any session authentication mechanism. 


e To view the authentication keychain used by the PCEP session, use the show 
path-computation-client status and show protocols pcep command outputs. 


e Use the show system statistics tcp | match auth command to view the number of packets that 
get dropped by TCP because of authentication errors. 


e Operation of the keychain can be verified by using the show security keychain detail command 
output. 


Impact of Client-Side PCE Implementation on Network Performance 


The maintenance of a stateful database can be non-trivial. In a single centralized PCE environment, a 


stateful PCE simply needs to remember all the TE LSPs that the PCE has computed, the TE LSPs that were 
actually set up (if this can be known), and when the TE LSPs were torn down. However, these requirements 
cause substantial control protocol overhead in terms of state, network usage and processing, and optimizing 


links globally across the network. Thus, the concerns of a stateful PCE implementation include: 


e Any reliable synchronization mechanism results in significant control plane overhead. PCEs might 


synchronize state by communicating with each other, but when TE LSPs are set up using distributed 
computation performed among several PCEs, the problems of synchronization and race condition 
avoidance become larger and more complex. 


Out-of-band traffic engineering database synchronization can be complex with multiple PCEs set up in 
a distributed PCE computation model, and can be prone to race conditions, scalability concerns, and so 


Path calculations incorporating total network state is highly complex, even if the PCE has detailed 
information on all paths, priorities, and layers. 


In spite of the above concerns, the partial client-side implementation of the stateful PCE is extremely 


effective in large traffic engineering systems. It provides rapid convergence and significant benefits in 


terms of optimal resource usage, by providing the requirement for global visibility of a TE LSP state and 


for ordered control of path reservations across devices within the system being controlled. 
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Example: Configuring the Path Computation Element Protocol for MPLS RSVP-TE 


IN THIS SECTION 


@ Requirements | 1374 
@ Overview | 1374 
@ = Configuration | 1377 
t 


Verification | 1384 


This example shows how to enable external path computing by a Path Computation Element (PCE) for 
traffic engineered label-switched paths (TE LSPs) on a Path Computation Client (PCC). It also shows how 
to configure the Path Computation Element Protocol (PCEP) on the PCC to enable PCE to PCC 
communication. 


Requirements 


This example uses the following hardware and software components: 


e Three routers that can be a combination of ACX Series routers, M Series Multiservice Edge Routers, MX 
Series 5G Universal Routing Platforms, T Series Core Routers, or PTX Series Transport Router, one of 
which is configured as a PCC. 


e A TCP connection to an external stateful PCE from the PCC. 


e Junos OS Release 12.3 or later running on the PCC along with the JSDN add-on package. 


NOTE: The JSDN add-on package is required to be installed along with the core Junos OS 
installation package. 


Before you begin: 

1. Configure the device interfaces. 

2. Configure MPLS and RSVP-TE. 

3. Configure IS-IS or any other IGP protocol. 


Overview 


Starting with Junos OS Release 12.3, the MPLS RSVP-TE functionality is extended to provide a partial 
client-side implementation of the stateful PCE architecture (draft-ietf-pce-stateful-pce) on a PCC. 
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NOTE: The partial client-side implementation of the stateful PCE architecture is based on version 
2 of Internet draft draft-ietf-pce-stateful-pce. Starting with Junos OS Release 16.1, this 
implementation is upgraded to support version 7, as defined in Internet draft 
draft-ietf-pce-stateful-pce-07. Releases prior to 16.1 support the older version of the PCE draft, 
causing interoperability issues between a PCC running a previous release and a stateful PCE 
server that adheres to Internet draft draft-ietf-pce-stateful-pce-07. 


To enable external path computing by a PCE, include the Isp-external-controller statement on the PCC 
at the [edit mpls] and [edit mpls Isp Isp-name] hierarchy levels. 


Isp-external-controller pccd; 


An LSP configured with the Isp-external-controller statement is referred to as a PCE-controlled LSP and 
is under the external control of a PCE by default. An active stateful PCE can override the parameters set 
from the CLI, such as bandwidth, path (ERO), and priority, for such PCE-controlled LSPs of the PCC. 


To enable PCE to PCC communication, configure PCEP on the PCC at the [edit protocols] hierarchy level. 


pcep {...} 


When configuring PCEP on a PCC, be aware of the following considerations: 
e The JSDN add-on package is required to be installed along with the core Junos OS installation package. 


e Junos OS Release 12.3 supports only stateful PCEs. 


e APCC can connect to a maximum of 10 stateful PCEs. At any given point in time, there can be only one 
main PCE (the PCE with the lowest priority value, or the PCE that connects to the PCC first in the absence 
of a PCE priority) to which the PCC delegates LSPs for path computation. 


For Junos OS Release 12.3, the PCC always initiates the PCEP sessions. PCEP sessions initiated by 
remote PCEs are not accepted by the PCC. 


Existing LSP features, such as LSP protection and make-before-break, work for PCE-controlled LSPs. 


The auto-bandwidth option is turned off for PCE-controlled LSPs, although LSPs under the control of 
auto-bandwdith and constraint-based routing can coexist with PCE-controlled LSPs. 


PCE-controlled LSPs can be referred to by other CLI configurations, such as Isp-nexthop to routes, 
forwarding adjacencies, CCC connections, and logical tunnels. 


PCE-controlled LSPs do not support GRES. 


PCE-controlled LSPs under logical-systems are not supported. 


PCE-controlled LSPs cannot be point-to-multipoint LSPs. 
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Bidirectional LSPs are not supported. 


PCE-controlled LSPs cannot have secondary paths without a primary path. 


PCE-controlled LSPs depend on external path computation, which impacts overall setup time, reroutes, 


and make-before-break features. 


Setup time and convergence time (reroute, MBB) for exisiting LSPs is the same as in previous releases, 
in the absence of PCE-controlled LSPs. However, a small impact is seen in the presence of PCE-controlled 
LSPs. 


e ERO computation time is expected to be significantly higher than local-CSPF. 


Topology 


Figure 120: Configuring PCEP for MPLS RSVP-TE 
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In this example, PCC is the ingress router that connects to the external active stateful PCE. 
The external LSPs of Router PCC are computed as follows: 


1. Router PCC receives the LSP tunnel configuration that was set up using the CLI. Assuming that the 
received configuration is enabled with external path computing, Router PCC becomes aware that some 
of the LSP attributes - bandwidth, path, and priority - are under the control of the stateful PCE and 
delegates the LSP to the PCE. 


In this example, the external LSP is called PCC-to-R2 and it is being set up from Router PCC to Router 
R2 . The CLI-configured ERO for PCC-to-R2 is PCC-RO-R1-R2. The bandwidth for PCC-to-R2 is 10m, 
and both the setup and hold priority values are 4. 


2. Router PCC tries to retrieve the PCE-controlled LSP attributes. To do this, Router PCC sends out a 
PCRpt message to the stateful PCE stating that the LSP has been configured. The PCRpt message 
communicates the status of the LSP and contains the local configuration parameters of the LSP. 
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3. The stateful PCE modifies one or more of the delegated LSP attributes and sends the new LSP parameters 
to Router PCC through the PCUpd message. 


4. On receiving the new LSP parameters, Router PCC sets up a new LSP and re-signals it using the 
PCE-provided path. 


In this example, the PCE-provided ERO for PCC-to-R2 is PCC-R3-R2. The bandwidth for PCC-to-R2 
is 8m, and both the setup and hold priority values are 3. 


5. Router PCC sends a PCRpt with the new RRO to the stateful PCE. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


PCC 


set interfaces ge-1/0/1 unit 0 family inet address 20.31.4.1/24 

set interfaces ge-1/0/1 unit 0 family iso 

set interfaces ge-1/0/1 unit 0 family mpls 

set interfaces ge-1/1/1 unit 0 family inet address 20.31.1.1/24 

set interfaces ge-1/1/1 unit 0 family iso 

set interfaces ge-1/1/1 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.179.95/32 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls Isp-external-controller pccd 

set protocols mpls label-switched-path PCC-to-R2 to 10.255.179.98 
set protocols mpls label-switched-path PCC-to-R2 bandwidth 10m 
set protocols mpls label-switched-path PCC-to-R2 priority 4 4 

set protocols mpls label-switched-path PCC-to-R2 primary to-R2-path 
set protocols mpls label-switched-path PCC-to-R2 Isp-external-controller pccd 
set protocols mpls path to-R2-path 20.31.1.2 strict 

set protocols mpls path to-R2-path 20.31.2.2 strict 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols isis level 1 disable 

set protocols isis interface all 

set protocols isis interface fxp0.0 disable 


RO 


R1 


set protocols isis interface lo0.0 

set protocols pcep pce pcel destination-ipv4-address 10.209.57.166 
set protocols pcep pce pcel destination-port 4189 

set protocols pcep pce pcei pce-type active 

set protocols pcep pce pce1 pce-type stateful 


set interfaces ge-1/0/6 unit 0 family inet address 20.31.1.2/24 
set interfaces ge-1/0/6 unit 0 family iso 

set interfaces ge-1/0/6 unit 0 family mpls 

set interfaces ge-1/0/7 unit 0 family inet address 20.31.2.1/24 
set interfaces ge-1/0/7 unit 0 family iso 

set interfaces ge-1/0/7 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.179.96/32 
set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols isis level 1 disable 

set protocols isis interface all 

set protocols isis interface fxp0.0 disable 

set protocols isis interface lo0.0 


set system ports console log-out-on-disconnect 

set interfaces ge-2/0/3 unit 0 family inet address 20.31.2.2/24 
set interfaces ge-2/0/3 unit 0 family iso 

set interfaces ge-2/0/3 unit 0 family mpls 

set interfaces ge-2/0/4 unit 0 family inet address 20.31.8.1/24 
set interfaces ge-2/0/4 unit 0 family iso 

set interfaces ge-2/0/4 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.179.97/32 
set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 
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R2 


R3 


set protocols mpls interface fxp0.0 disable 
set protocols isis level 1 disable 

set protocols isis interface all 

set protocols isis interface fxp0.0 disable 
set protocols isis interface lo0.0 


set interfaces ge-1/0/2 unit 0 family inet address 20.31.8.2/24 
set interfaces ge-1/0/2 unit 0 family iso 

set interfaces ge-1/0/2 unit 0 family mpls 

set interfaces ge-1/0/3 unit 0 family inet address 20.31.5.2/24 
set interfaces ge-1/0/3 unit 0 family iso 

set interfaces ge-1/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.179.98/32 
set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols isis level 1 disable 

set protocols isis interface all 

set protocols isis interface fxp0.0 disable 

set protocols isis interface lo0.0 


set interfaces ge-2/0/1 unit 0 family inet address 20.31.4.2/24 
set interfaces ge-2/0/1 unit 0 family iso 

set interfaces ge-2/0/1 unit 0 family mpls 

set interfaces ge-2/0/3 unit 0 family inet address 20.31.5.1/24 
set interfaces ge-2/0/3 unit 0 family iso 

set interfaces ge-2/0/3 unit 0 family mpls 

set interfaces loO unit O family inet address 10.255.179.99/32 
set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 
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set protocols isis level 1 disable 

set protocols isis interface all 

set protocols isis interface fxp0.0 disable 
set protocols isis interface lo0.0 


Step-by-Step Procedure 
The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode. 


To configure Router PCC: 


NOTE: Repeat this procedure for every Juniper Networks ingress router in the MPLS domain, 
after modifying the appropriate interface names, addresses, and any other parameters for each 
router. 


1. Configure the interfaces. 


To enable MPLS, include the protocol family on the interface so that the interface does not discard 
incoming MPLS traffic. 


[edit interfaces] 

user@PCC# set ge-1/0/1 unit 0 family inet address 20.31.4.1/24 
user@PCC# set ge-1/0/1 unit 0 family iso 

user@PCC# set ge-1/0/1 unit 0 family mpls 

user@PCC# set ge-1/1/1 unit O family inet address 20.31.1.1/24 
user@PCC# set ge-1/1/1 unit 0 family iso 

user@PCC# set ge-1/1/1 unit 0 family mpls 

user@PCC# set loO unit 0 family inet address 10.255.179.95/32 


2. Enable RSVP on all interfaces of Router PCC, excluding the management interface. 


[edit protocols] 
user@PCC# set rsvp interface all 
user@PCC# set rsvp interface fxp0.0 disable 


3. Configure the label-switched path (LSP) from Router PCC to Router R2 and enable external control of 
LSPs by the PCE. 
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[edit protocols] 

user@PCC# set mpls Isp-external-controller pccd 

user@PCC# set mpls label-switched-path PCC-to-R2 to 10.255.179.98/32 

user@PCC# set mpls label-switched-path PCC-to-R2 bandwidth 10m 

user@PCC# set protocols mpls label-switched-path PCC-to-R2 priority 4 4 

user@PCC# set protocols mpls label-switched-path PCC-to-R2 primary to-R2-path 
user@PCC# set protocols mpls label-switched-path PCC-to-R2 Isp-external-controller pccd 


4. Configure the LSP from Router PCC to Router R2, which has local control and is overridden by the 
PCE-provided LSP parameters. 


[edit protocols] 
user@PCC# set mpls path to-R2-path 20.31.1.2/30 strict 
user@PCC# set mpls path to-R2-path 20.31.2.2/30 strict 


5. Enable MPLS on all interfaces of Router PCC, excluding the management interface. 


[edit protocols] 
user@PCC# set mpls interface all 
user@PCC# set mpls interface fxp0.0 disable 


6. Configure IS-IS on all interfaces of Router PCC, excluding the management interface. 


[edit protocols] 

user@PCC# set isis level 1 disable 
user@PCC# set isis interface all 
user@PCCz# set isis interface fxp0.0 disable 
user@PCC# set isis interface lo0.0 


7. Define the PCE that Router PCC connects to, and configure the IP address of the PCE. 


[edit protocols] 
user@PCC# set pcep pce pcel destination-ipv4-address 10.209.57.166 


8. Configure the destination port for Router PCC that connects to a PCE using the TCP-based PCEP. 


[edit protocols] 
user@PCC# set pcep pce pce1 destination-port 4189 


9. Configure the PCE type. 


[edit protocols] 


user@PCC# set pcep pce pce1 pce-type active 
user@PCC# set pcep pce pce1 pce-type stateful 


Results 


From configuration mode, confirm your configuration by entering the show interfaces and show protocols 
commands. If the output does not display the intended configuration, repeat the instructions in this example 


to correct the configuration. 


user@PCC# show interfaces 
ge-1/0/1 { 
unit O { 
family inet { 
address 20.31.4.1/24, 

} 

family iso; 

family mpls; 


} 
ge-1/1/1 { 
unit O { 
family inet { 
address 20.31.1.1/24, 
} 
family iso; 
family mpls; 


} 
lo0 { 
unit O { 
family inet { 


address 10.255.179.95/32; 


user@PCC# show protocols 
rsvp { 

interface all; 

interface fxp0.0 { 
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disable; 


} 
mpls { 
Isp-external-controller pccd; 
label-switched-path PCC-to-R2 { 
to 10.255.179.98; 
bandwidth 10m; 
priority 4 4, 
primary to-R2-path; 
Isp-external-controller pccd; 
} 
path to-R2-path { 
20.31.1.2 strict; 
20.31.2.2 strict; 
} 
interface all; 
interface fxp0.0 { 
disable; 


} 
isis { 
level 1 disable; 
interface all; 
interface fxp0.0 { 
disable; 
} 
interface 100.0; 
} 
pcep { 
pce pcel { 
destination-ipv4-address 10.209.57.166; 
destination-port 4189; 


pce-type active stateful; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


Verifying the PCEP Session Status | 1384 


@ Verifying the PCE-Controlled LSP Status When LSP Control Is External | 1385 


Verifying the PCE-Controlled LSP Status When LSP Control Is Local | 1387 


Confirm that the configuration is working properly. 


Verifying the PCEP Session Status 


Purpos 


e 


Verify the PCEP session status between the PCE and Router PCC when the PCE status is up. 


Action 


From operational mode, run the show path-computation-client active-pce command. 


user@PCC> show path-computation-client active-pce 
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Meaning 

The output displays information about the current active stateful PCE that Router PCC is connected to. 
The PCE status output field indicates the current status of the PCEP session between the PCE and Router 
PCC. 


For pce1, the status of the PCEP session is PCE_STATE_UP, which indicates that the PCEP session has 
been established between the PCEP peers. 


The statistics of PCRpts indicate the number of messages sent by Router PCC to the PCE to report the 
current status of LSPs. The PCUpdates statistics indicate the number of messages received by Router PCC 
from the PCE. The PCUpdates messages include the PCE modified parameters for the PCE-controlled 
LSPs. 


Verifying the PCE-Controlled LSP Status When LSP Control Is External 


Purpose 
Verify the status of the PCE-controlled LSP from Router PCC to Router R2 when the LSP is under external 
control. 


Action 


From operational mode, run the show mpls Isp name PCC-to-R2 extensive command. 


user@PCC> show mpls Isp name PCC-to-R2 extensive 


Ingress LSP: 1 sessions 


10.255.179). 98 
From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-—to-R2 
ActivePath: to-R2-path (primary) 
LSPtype: Externally controlled, Penultimate hop popping 
LSP Control Status: Externally controlled 
LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





*Primary to-R2-path Stace: Up 
irises 3 3 
Bandwidth: 8Mbps 
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SmartOptimizeTimer: 180 


No computed ERO. 








Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 


20=Node-ID): 


20,31 o4,% A0s3ils, 557 


All Weve iil OS300g So. 7a6 


AQ Wace Lil OSs00e 560.736 





EXTCTRL LSP: Sent Path computation request and LSP status 





EXTCTRL_LSP: Computation request/lsp status contains: 


liACKTClElN IOOOOWOO jseiornicy — seu 4 inoilel 4 incjsss 20 .31.1.2 20.31,2.2 
19 Mar 11 05:00:56.735 Selected as active path 


iis) Mee ili MSsWO ea. 734 


Ly Mene dil WOSs00s 56.734 





EXTCTRL LSP: Sent Path computation request and LSP status 





EXTCTRL_LSP: Computation request/lsp status contains: 


loaiachiLCheln LOOOOOOO jowiorniey — seu 4 imoilel 4 Incjoss 20.31,.1.2 20.31.2.2 


16 Wee iit OS200s56., 7/54 
15 Wee il OSs 00s S56, 754 
1a Mew al WSsOOe 56. 7113 


LS Mewe Ii OSs 00s SG. 713) 
bandwidth 10000000 priori 

12 Wee i USsO0sS6, 712 

iil Weve iit WS, 00sS6, 712 
AQ. 31. Bs% 

TOP Mars AOS 100i Or2 333 


9 Mee i OssOOg49), 233 
bandwidth 10000000 priori 

ii Mee id WS sW0s 20. Sisal 
bandwidth 10000000 priori 

7 Meue iil WSsO0e 20. Soil 


inecomc Rewces 20.31 4.2 20,315,528 
Up 





EXTCTRL LSP: Sent Path computation request and LSP status 





EXTCTRL_LSP: Computation request/lsp status contains: 
iy = seco 4 Inollcl 4 Ingjoss 20.31.1162 20.3162,2 
Originate Call 





EXTCTRL_LSP: Received setup parameters : 20.31.4.2 





EXTCTRL LSP: Sent Path computation request and LSP status 





EXTCTRL_LSP: Computation request/lsp status contains: 
iy = secujo 4 inolcl 4 Inoeoss 20.31,.1.2 20.316252 




















EXTCTRL_LSP: Computation request/lsp status contains: 


icy = seicuje 4 Ineilcl 4 lagoses AO 31.1.2 20,3164 o2 











6 Mee dil OSs 00s 20, Heal 


EXTCTRL LSP: Sent Path computation request and LSP status 





EXTCTRL_LSP: Computation request/lsp status contains: 





lsiAcKVLCleln LOOOOOOO jseiornicy — seu 4) iInmoilcel 4 incjoss 20.31.12 20.31,2.2 


& Mee Li MObs00s 20,580 
AM Mare SSIS OS)10 ORO Sea 186 





EXTCTRL_LSP: Control status became external 























EXTCTRL_LSP: Control status became local 








3 Mar 11 05:00:03.714 EXTCTRL LSP: Sent Path computation request and LSP status 


2 Weve ii WssO0sos. 714 





EXTCTRL_LSP: Computation request/lsp status contains: 





lSaiachTtCheln, LOOOOOOO joriornicy — seu 4 Inoilcl 4 inciss3s 20.31.1,.2 20.31.2.2 


I Mew iil USsO0sO0,279) 











EXTCTRL LSP: Awaiting external controller connection 





Created: Mon Mar 11 05:00:00 2013 
Total 1 displayed, Up 1, Down 0 





Egress LSP: 0 sessions 
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Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 
In the output, the LSPtype and LSP Control Status output fields show that the LSP is externally controlled. 
The output also shows a log of the PCEP messages sent between Router PCC and the PCE. 


The PCEP session between the PCE and Router PCC is up, and Router PCC receives the following 
PCE-controlled LSP parameters: 


e ERO (path)—20.31.4.2 and 20.31.5.2 

e Bandwidth—8Mbps 

e Priorities—3 3 (setup and hold values) 

Verifying the PCE-Controlled LSP Status When LSP Control Is Local 


Purpose 
Verify the status of the PCE-controlled LSP from Router PCC to Router R2 when the LSP control becomes 
local. 


Action 


From operational mode, run the show mpls Isp name PCC-to-R2 extensive command. 


user@PCC> show mpls Isp name PCC-to-R2 extensive 


Ingress LSP: 1 sessions 


10.255 .179 98 
Bron mlOmZ bo lose o micicater MUD meACEINOROUEC HNO lice Manet Ce aoa Re 
ActivePath: to-R2-path (primary) 





LSPtype: Externally controlled, Penultimate hop popping 
LSP Control Status: Locally controlled 
LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





*Primary EO-RZ Spat m Seer Wie 
Priorities: 4 4 (ActualPriorities 3 3) 
Bandwidth: 10Mbps (ActualBandwidth: 8Mbps) 


SmartOptimizeTimer: 180 





No computed ERO. 





Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 


20=Node-ID) : 


1388 


ZQ 31.452 20,51,5.2 
22 Mar 11 05:02:09.618 EXTCTRL LSP: Control status became local 


AML Mee ii WSsWOs 56. 736 








EXTCTRL LSP: Sent Path computation request and LSP status 





20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains: 
lpaimchracheln LOOOOOOO priezicy — secu “4 inoilcl 4 Ineoess 20.31.162 20.3162 .2 
19 Mar 11 05:00:56.735 Selected as active path 


iis, Meuse 1 WS2008 56. 734 


Ly Meue iil OS 300s 56.734 





EXTCTRL LSP: Sent Path computation request and LSP status 





EXTCTRL_LSP: Computation request/lsp status contains: 


lKamchrachein IOOOOOOO prioricy — seus “) inoilcl 4 Ineoss 20.31.16.2 20.3162 .2 
16 Maz 11 05>: 00% 5627/34 Record Route: 20731422 20531 5-2 


15 Wee il WSs00ss6, 754 
14 Weve id OS2008 56.713 


3 Mewe LiL OSs O00 eS%S. 7iL3) 


Up 





EXTCTRL LSP: Sent Path computation request and LSP status 





EXTCTRL_LSP: Computation request/lsp status contains: 


lAiMNCKaCheln IOOOOOOO) jeezy — seus “4 ineilc! 4 inejoss 20,31.1.2 20.31.2.2 


14, Weve IL WS300e 56. 714 

di Weve It OSs00sS6, 712 
20 5.515562 

10) Mee id OSZO00s4) 293 


OE Mare ESO SiO ORI e ze Ss 
bandwidth 10000000 priori 

i} Mee Ii OSs 20. Sisi 
bandwidth 10000000 priori 

7 Meue i O52 00820. 581 


© Ma Ii WSs@0s 20. Sel 


bandwidth 10000000 priori 
& Wee Li O8s00s20. 580 
A Weve iL OSsOOs0S., Wil 
2 Meuse Ii OS2O0080s. 714 


Originate Call 





EXTCTRL_LSP: Received setup parameters : 20.31.4.2 





EXTCTRL LSP: Sent Path computation request and LSP status 





EXTCTRL_LSP: Computation request/lsp status contains: 
iy = seu 4 Inoikel 4 laciose Z20.3i1o1.2 20-3 c252 




















EXTCTRL_LSP: Computation request/lsp status contains: 
iy = secujo 4 Inoilcl 4 Ineoss 20.31.1628 20.316252 











EXTCTRL LSP: Sent Path computation request and LSP status 





EXTCTRL_LSP: Computation request/lsp status contains: 





iy = secu 4 Inoilcl 4 lagoss 20.31.12 20.316 452 





EXTCTRL_LSP: Control status became external 























EXTCTRL_LSP: Control status became local 











Ze Mare SES OS OOO S rayne 


EXTCTRL LSP: Sent Path computation request and LSP status 


EXTCTRL_LSP: Computation request/lsp status contains: 


IAMCKAChEl IOOOOOOO priority = seus “4 Iineilc! 4 Ineoss 20.31.1522 20.31.2.2 


i Meg iil USsOUsOO.279) 





Created: Mon Mar 11 05: 








EXTCTRL LSP: Awaiting external controller connection 
OOOO RZ Oks 





Total 1 displayed, Up 1, Down 0 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 
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Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 

In the output, the LSP Control Status output field shows that the LSP is under local control. Although the 
PCE-controlled LSP is under local control, Router PCC continues to use the PCE-provided parameters, 
until the next opportunity to re-signal the LSP. 


The output now displays the LSP parameters that were configured using the CLI along with the PCE-provided 
parameters used to establish the LSP as the actual values in use. 


e Bandwidth—10Mbps (ActualBandwidth: 8Mbps) 
e Priorities—4 4 (ActualPriorities 3 3) 


On the trigger to re-signal the LSP, Router PCC uses the local configuration parameters to establish the 
PCE-controlled LSP. 


user@PCC> show mpls Isp name PCC-to-R2 extensive externally-controlled 


Ingress LSP: 1 sessions 


10 255.4179, 33 
From: 10.255.183.59, State: Up, ActiveRoute: 0, LSPname: PCC-to-R2 
ActivePath: to-R2-path (primary) 

LSPtype: Externally controlled, Penultimate hop popping 





LSP Control Status: Locally controlled 
LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


— 


Primary EO>R2 [parm Siaces Up 





Priorities: 4 4 
Bandwidth: 10Mbps 
SmartOptimizeTimer: 180 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 
20 .3Lo1 2 S 2Z0s31.2.2 S 20.31.8.2 § 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20 Nodes ip) ie: 
20,3 .152 20.31.4562 20.31.9528 
As Weve lil OSs02essil, ye? Recor Rewres 20 .3ilcio2 2Q,30c2c4 2UcS oad 
Al Mee iil Obs02sSi 737 Wie 
26 Mar 11 05:02:51.697 EXTCTRL_LSP: Applying local parameters with this 











signalling attempt 
As Mew iil OSs02s 5,697 OxsicilinaieS Callil 
ZAM Mane aah 0 2 olllnG SiGe CillcaremG alll 
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23) Mew iil OS202e51.695 CSPiFs Comeuicaiciem mesullt acegecec] 20.3i1,1,.2 20,.5152,2 


AQ o Sis 8ok 





22 Mar 11 05:02:09.618 EXTCTRL LSP: Control status became local 


AML Mew ii WSsgWls 56. 736 





EXTCTRL LSP: Sent Path computation request and LSP status 





20 Mar 11 05:00:56.736 EXTCTRL_LSP: Computation request/lsp status contains: 
lpaimchracheln LOOOOOOO priezicy — secu “4 inoilcl 4 Ineoess 20.31.162 20.3162 .2 
19 Mar 11 05:00:56.735 Selected as active path 


iis, Meuse 1 WS2008 56. 734 


Ly Meue iil OS 300s 56.734 





EXTCTRL LSP: Sent Path computation request and LSP status 





EXTCTRL_LSP: Computation request/lsp status contains: 


lKamchrachein IOOOOOOO prioricy — seus “) inoilcl 4 Ineoss 20.31.16.2 20.3162 .2 
16 Maz 11 05>: 00% 5627/34 Record Route: 20731422 20531 5-2 


15 Wee il WSs00ss6, 754 
14 Weve id OS2008 56.713 


3 Mewe LiL OSs O00 eS%S. 7iL3) 


Up 
EXTCTRL LSP: Sent Path computation request and LSP status 








EXTCTRL_LSP: Computation request/lsp status contains: 


lAiMNCKaCheln IOOOOOOO) jeezy — seus “4 ineilc! 4 inejoss 20,31.1.2 20.31.2.2 


14, Weve IL WS300e 56. 714 

di Weve It OSs00sS6, 712 
20 5.515562 

10) Mee id OSZO00s4) 293 


OE Mare ESO SiO ORI e ze Ss 
bandwidth 10000000 priori 

i} Mee Ii OSs 20. Sisi 
bandwidth 10000000 priori 

7 Meue i O52 00820. 581 


© Ma Ii WSs@0s 20. Sel 


bandwidth 10000000 priori 
& Wee Li O8s00s20. 580 
A Weve iL OSsOOs0S., Wil 
2 Meuse Ii OS2O0080s. 714 


Originate Call 





EXTCTRL_LSP: Received setup parameters : 20.31.4.2 





EXTCTRL LSP: Sent Path computation request and LSP status 





EXTCTRL_LSP: Computation request/lsp status contains: 
iy = seu 4 Inoikel 4 laciose Z20.3i1o1.2 20-3 c252 




















EXTCTRL_LSP: Computation request/lsp status contains: 
iy = secujo 4 Inoilcl 4 Ineoss 20.31.1628 20.316252 











EXTCTRL LSP: Sent Path computation request and LSP status 





EXTCTRL_LSP: Computation request/lsp status contains: 





iy = secu 4 Inoilcl 4 lagoss 20.31.12 20.316 452 





EXTCTRL_LSP: Control status became external 























EXTCTRL_LSP: Control status became local 











Ze Mare SES OS OOO S rayne 


EXTCTRL LSP: Sent Path computation request and LSP status 


EXTCTRL_LSP: Computation request/lsp status contains: 


IAMCKAChEl IOOOOOOO priority = seus “4 Iineilc! 4 Ineoss 20.31.1522 20.31.2.2 


i Meg iil USsOUsOO.279) 





Created: Mon Mar 11 05: 








EXTCTRL LSP: Awaiting external controller connection 
OOOO RZ Oks 





Total 1 displayed, Up 1, Down 0 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 
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Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


The Computed ERO is 20.31.1.2, 20.31.2.2, and 20.31.8.2. The PCE-controlled LSP is established using 
the local configuration parameters. 


Example: Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support of 
PCE-Initiated Point-to-Point LSPs 


IN THIS SECTION 


Requirements | 1391 
Overview | 1391 
Configuration | 1393 


Verification | 1398 


This example shows how to configure the Path Computation Client (PCC) with the capability of supporting 
Path Computation Element (PCE)-initiated traffic-engineered point-to-point label-switched paths (LSPs). 


Requirements 

This example uses the following hardware and software components: 

e Three routers that can be a combination of ACX Series, M Series, MX Series, or T Series routers. 
e A TCP connection to two external stateful PCEs from the ingress router (PCC). 

e Junos OS Release 16.1 or later running on the PCC. 


Before you begin: 


e Configure the device interfaces. 
e Configure MPLS and RSVP-TE (RSVP-Traffic Engineering). 


e Configure OSPF or any other IGP protocol. 


Overview 


Starting with Junos OS Release 16.1, the PCEP functionality is extended to allow a stateful PCE to initiate 
and provision traffic engineering LSPs through a PCC. Earlier, the LSPs were configured on the PCC and 

the PCC delegated control over the external LSPs to a PCE. The ownership of the LSP state was maintained 
by the PCC. With the introduction of the PCE-initiated LSPs, a PCE can initiate and provision a traffic 
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engineering point-to-point LSP dynamically without the need for a locally configured LSP on the PCC. On 
receiving a PCCreate message from a PCE, the PCC creates the PCE-initiated LSP and automatically 
delegates the LSP to the PCE. 


When configuring the support of PCE-initiated point-to-point LSPs for a PCC, be aware of the following 


considerations: 


Junos OS Release 13.3 supports only stateful PCEs. 


For Junos OS Release 13.3, the PCC always initiates the PCEP sessions. PCEP sessions initiated by 
remote PCEs are not accepted by the PCC. 


Existing LSP features, such as LSP protection and make-before-break, work for PCE-initiated LSPs. 
PCE-initiated LSPs do not support graceful Routing Engine switchover (GRES). 

PCE-initiated LSPs under logical systems are not supported. 

PCE-initiated LSPs cannot be point-to-multipoint LSPs. 

Bidirectional LSPs are not supported. 

RSVP-TE for unnumbered links is not supported. PCE-initiated LSPs support only numbered links. 


The PCE initiating a segment routing LSP can use the binding segment ID (SID) labels associated with 
non-colored segment routing LSPs to provision the PCE-initiated segment routing LSP paths. 


Starting in Junos OS Release 18.2R1, statically configured non-colored segment routing LSPs on the 
ingress device are reported to a PCE through a PCEP session. These non-colored segment routing LSPs 
may have binding SID labels associated with them. With this feature, the PCE can use this binding SID 
label in the label stack to provision PCE-initiated segment routing LSP paths. 


Topology 


Figure 121: Example PCE-Initated Point-to-Point LSP for MPLS RSVP-TE 


lo0=192.168.69.58 


CE1 
| lo0=192.168.12.1 lo0=192.168.10.1 lo0=192.168.11.1 
PCC 10.0.102.10 R1 10.0.101.9 R2 
ge-3/ 1/1 ge-3/ 1/2 
ge-0/1/1 ge-0/ 1/2 
ge-0/1/3 10.0.102.9 10.0.101.10 ge-0/1/3 

[| 10.0.112.14 10.0.112.13 
8 

PCE2 g 
S 


lo0=192.168.70.65 


In this example, PCC is the ingress router that connects to two external stateful PCEs: PCE1 and PCE2. 
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When there is a new demand, the active stateful PCE dynamically initiates an LSP to meet the requirement. 
Since PCC is configured with the capability of supporting the PCE-initiated LSP, path computation on PCC 
is performed as follows: 


1. A PCE sends a PCCreate message to the PCC to initiate and provision an LSP. The PCC sets up the 
PCE-initiated LSP using the parameters received from the PCE, and automatically delegates the 
PCE-initiated LSP to the PCE that initiated it. 


In this example, PCE1 is the active stateful PCE that initiates and provisions the PCE-initiated LSP on 
PCC. On receiving the PCE-initiated LSP parameters, PCC sets up the LSP and automatically delegates 
the PCE-initiated LSP to PCE1. 


2. When the PCEP session between PCC and PCE1 is terminated, PCC starts two timers for the 
PCE1-initiated LSP: delgation cleanup timeout and the LSP cleanup timer. During this time, PCE1 or 
PCE2 can acquire control of the PCE-initiated LSP. 


3. If PCE2 acquires control over the PCE-initiated LSP before the expiration of the LSP cleanup timer, 
PCC delegates the PCE-initiated LSP to PCE2, and the LSP cleanup timer and the delegation cleanup 
timeout are stopped. 


4. If the delegation cleanup timeout expired, and neither PCE1 nor PCE2 acquired control over the 
PCE-initiated LSP, PCC takes local control of the non-delegated PCE-initiated LSP until the expiration 
of the LSP cleanup timer. 


5. After the expiration of the LSP cleanup timer, PCC deletes the PCE-initiated LSP provisioned by PCE1. 


Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


PCC 


set interfaces ge-0/1/1 unit 0 family inet address 10.0.102.9/24 
set interfaces ge-0/1/1 unit 0 family iso 

set interfaces ge-0/1/1 unit 0 family mpls 

set interfaces ge-0/1/3 unit 0 family inet address 10.0.112.14/24 
set interfaces ge-0/1/3 unit 0 family iso 

set interfaces ge-0/1/3 unit 0 family mpls 


R1 


R2 


set interfaces loO unit O family inet address 192.168.12.1/32 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls Isp-external-controller ppcd 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 

set protocols pcep pce-group PCEGROUP pce-type active 

set protocols pcep pce-group PCEGROUP pce-type stateful 

set protocols pcep pce-group PCEGROUP Isp-provisioning 

set protocols pcep pce-group PCEGROUP Isp-cleanup-timer 30 

set protocols pcep pce PCE1 destination-ipv4-address 192.168.69.58 
set protocols pcep pce PCE1 destination-port 4189 

set protocols pcep pce PCE1 pce-group PCEGROUP 

set protocols pcep pce PCE2 destination-ipv4-address 192.168.70.65 
set protocols pcep pce PCE2 destination-port 4189 

set protocols pcep pce PCE2 pce-group PCEGROUP 


set interfaces ge-3/1/1 unit 0 family inet address 10.0.102.10/24 
set interfaces ge-3/1/1 unit 0 family iso 

set interfaces ge-3/1/1 unit 0 family mpls 

set interfaces ge-3/1/2 unit 0 family inet address 10.0.101.9/24 
set interfaces ge-3/1/2 unit 0 family iso 

set interfaces ge-3/1/2 unit 0 family mpls 

set interfaces loO unit O family inet address 192.168.10.1/32 
set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 
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set interfaces ge-0/1/1 unit 0 family inet address 10.0.101.10/24 
set interfaces ge-0/1/1 unit 0 family iso 

set interfaces ge-0/1/1 unit 0 family mpls 

set interfaces ge-0/1/3 unit 0 family inet address 10.0.112.13/24 
set interfaces ge-0/1/3 unit 0 family iso 

set interfaces ge-0/1/3 unit 0 family mpls 

set interfaces loO unit O family inet address 192.168.11.1/32 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface all 

set protocols ospf area 0.0.0.0 interface fxp0.0 disable 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode. 


To configure the PCC router: 


NOTE: Repeat this procedure for every Juniper Networks ingress router in the MPLS domain, 
after modifying the appropriate interface names, addresses, and any other parameters for each 
router. 


1. Configure the interfaces. 


To enable MPLS, include the protocol family on the interface so that the interface does not discard 
incoming MPLS traffic. 


[edit interfaces] 

user@PCC# set ge-0/1/1 unit 0 family inet address 10.0.102.9/24 
user@PCC# set ge-0/1/1 unit 0 family iso 

user@PCC# set ge-0/1/1 unit 0 family mpls 

user@PCC# set ge-0/1/3 unit O family inet address 10.0.112.14/24 
user@PCC# set ge-0/1/3 unit 0 family iso 

user@PCC# set ge-0/1/3 unit 0 family mpls 

user@PCC# set loO unit O family inet address 192.168.12.1/32 


1395 


1396 


2. Enable RSVP on all interfaces of the PCC, excluding the management interface. 


[edit protocols] 
user@PCC# set rsvp interface all 
user@PCC# set rsvp interface fxp0.0 disable 


3. Enable external control of LSPs by the PCEs. 


[edit protocols] 
user@PCC# set mpls Isp-external-controller pccd 


4. Enable MPLS on all interfaces of the PCC, excluding the management interface. 


[edit protocols] 
user@PCC# set mpls interface all 
user@PCC# set mpls interface fxp0.0 disable 


5. Configure OSPF on all interfaces of the PCC, excluding the management interface. 


[edit protocols] 

user@PCC# set ospf traffic-engineering 

user@PCC# set ospf area 0.0.0.0 interface all 
user@PCC# set ospf area 0.0.0.0 interface fxp0.0 disable 
user@PCC# set ospf interface lo0.0 


6. Define the PCE group and enable support of PCE-initiated LSPs for the PCE group. 


[edit protocols] 

user@PCC# set protocols pcep pce-group PCEGROUP pce-type active 
user@PCC# set protocols pcep pce-group PCEGROUP pce-type stateful 
user@PCC# set protocols pcep pce-group PCEGROUP Isp-provisioning 
user@PCC# set protocols pcep pce-group PCEGROUP Isp-cleanup-timer 30 


7. Define the PCEs that connect to the PCC. 


[edit protocols] 

user@PCC# set pcep pce PCE1 destination-ipv4-address 192.168.69.58 
user@PCC# set pcep pce PCE1 destination-port 4189 

user@PCC# set pcep pce PCE1 pce-group PCEGROUP 


user@PCC# set pcep pce PCE2 destination-ipv4-address 192.168.70.65 
user@PCC# set pcep pce PCE2 destination-port 4189 
user@PCC# set pcep pce PCE2 pce-group PCEGROUP 


Results 


From configuration mode, confirm your configuration by entering the show interfaces and show protocols 
commands. If the output does not display the intended configuration, repeat the instructions in this example 
to correct the configuration. 


user@PCC# show interfaces 
ge-0/1/1 { 
unit O { 
family inet { 
address 10.0.102.9/24; 

} 

family iso; 

family mpls; 


} 
ge-0/1/3 { 
unit O { 
family inet { 
address 10.0.112.14/24; 
} 
family iso; 
family mpls; 


} 
loO { 
unit O { 
family inet { 
address 192.168.12.1/32; 


user@PCC# show protocols 
rsvp { 

interface all; 

} 

interface fxp0.0 { 
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disable; 


} 
mpls { 
Isp-external-controller pccd; 
interface all; 
interface fxp0.0 { 
disable; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface all; 
interface fxp0.0 { 
disable; 


} 

pce-group PCEGROUP { 
pce-type active stateful; 
Isp-provisioning; 
Isp-cleanup-timer 30; 

} 

pce PCE1 { 
destination-ipv4-address 192.168.69.58; 
destination-port 4189; 
pce-group PCEGROUP; 

} 

pce PCE2 { 
destination-ipv4-address 192.168.70.65; 
destination-port 4189; 
pce-group PCEGROUP; 


If you are done configuring the device, enter commit from configuration mode. 


Verification 


IN THIS SECTION 


@ = Verifying PCC Status | 1399 
@ Verifying PCE1 Status | 1399 
@ Verifying the PCE-Initiated LSP Status When the LSP Is Externally Provisioned | 1401 
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Confirm that the configuration is working properly. 


Verifying PCC Status 


Purpose 


Verify the PCEP session status and LSP summary between the PCC and the connected PCEs. 


Action 


From operational mode, run the show path-computation-client status command. 


user@PCC# show path-computation-client status 





Session Type Provisioning Status 
Peni Stateful Active On Up 
PCE2 Stateful Active On Up 


LSP Summary 


Total number of LSPs Bal 
Static LSPs g 0) 
Externally controlled LSPs : 0 





Externally provisioned LSPs : 1/16000 (current/limit) 
Orphaned LSPs 2 0) 


PCE1 (main) 


Delegated cael 

Externally provisioned : 1 
PEn2 

Delegated sO) 





Externally provisioned : 0 


Meaning 


The output displays the status of the PCEP session between the active stateful PCEs and the PCC. It also 
displays information about the different types of LSPs on the PCC, and the number of LSPs provisioned 
by the connected PCEs and delegated to them. 


PCE1 is the main active PCE and has one PCE-initiated LSP that has been automatically delegated to it by 
the PCC. 


Verifying PCE1 Status 


Purpose 


Verify the status of the main active stateful PCE. 


Action 


From operational mode, run the show path-computation-client active-pce detail command. 


user@PCC# show path-computation-client active-pce 
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Meaning 


The output displays information about the current active stateful PCE to which the PCC is connected. The 
PCE status output field indicates the current status of the PCEP session between a PCE and PCC. 


For PCE1, the status of the PCEP session is PCE_STATE_UP, which indicates that the PCEP session has 
been established with the PCC. 


Verifying the PCE-Initiated LSP Status When the LSP Is Externally Provisioned 


Purpose 
Verify the status of the PCE-initiated LSP. 


Action 


From operational mode, run the show mpls Isp externally-provisioned detail command. 


user@PCC# show mplslIsp externally-provisioned detail 


Ingress LSP: 1 sessions 


10 -0.101. 10 
From: 10.0.102.9, State: Up, ActiveRoute: 0, LSPname: lsp15 
ActivePath: pathl (primary) 


Link protection desired 





LSPtype: Externally Provisioned, Penultimate hop popping 
LSP Control Status: Externally controlled 


LoadBalance: Random 





Encoding type: Packet, Switching type: Packet, GPID: IPv4 
Primary pathl Seaces Wo 


be 





Piriorciicless 7 0) 


Bandwidth: 8Mbps 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
10 .0,102.10 S 10.0,101,9 § 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Nod 








10=SoftPreempt 20=Node-ID): 
LO O.102.10 S 10,0,101.,9 § 


Meaning 


In the output, the LSPtype output field shows that the LSP is externally provisioned. 


The PCEP session between PCC and PCE1 is up, and the PCC receives the following PCE-initiated LSP 
parameters: 


e ERO (path)—10.0.102.10 and 10.0.101.9 
e Bandwidth—8 Mbps 


e Priority—7 O (setup and hold values) 


Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support of 
PCE-Initiated Point-to-Point LSPs 


You can configure a Path Computation Client (PCC) with the capability of supporting dynamically created 
label switched paths (LSPs) from a centralized external path computing entity. A stateful Path Computaiton 
Element (PCE) can be used to perform external path computation and generate dynamic LSPs when there 
is an increase in demand. 


A PCC creates the PCE-initiated point-to-point LSP using the PCE-provided LSP parameters, or parameters 
from a pre-configured LSP template when the PCE does not provision the LSP, and automatically delegates 
the PCE-initiated point-to-point LSP to the respective PCE. As a result, for PCE-initiated LSPs, there is no 
need for a locally configured LSP on the PCC. 


A CLIl-controlled LSP, PCE-controlled LSP, and PCE-initiated LSP can coexist with each other on a PCC. 
Before you begin: 


e Configure the device interfaces. 
e Configure MPLS and RSVP-TE. 


e Configure OSPF or any other IGP protocol. 
To configure PCC to support PCE-initiated point-to-point LSPs, complete the following tasks: 


1. In configuration mode, go to the following hierarchy level: 


[edit] 
user@PCC# edit protocols pcep 
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. Specify the number of messages per minute that the PCC can receive at maximum. 


[edit protocols pcep] 
user@PCC# set message-rate-limit messages-per-minute 


. Specify the number of externally provisioned label switched paths (LSPs) over all connected PCEs that 
the PCC can accept at maximum. 


[edit protocols pcep] 
user@PCC# set max-provisioned-Isps max-count 


. Specify the unique user defined ID for the connected PCE to configure the PCE parameters. 


[edit protocols pcep] 
user@PCC# edit pce pce-id 


. Specify the amount of time (in seconds) that the PCC must wait before returning control of LSPs to 
the routing protocol process after a PCEP session is disconnected. 


[edit protocols pcep pce pce-id] 
user@PCC# set delegation-cleanup-timeout seconds 


. Specify the IPv4 address of the PCE to connect with. 


[edit protocols pcep pce pce-id] 
user@PCC# set destination-ipv4-address ipv4-address 


. Specify the TCP port number that the PCE is using 


[edit protocols pcep pce pce-id] 
user@PCC# set destination-port port-number 


The value can range from 1 through 65535 and the default value is 4189. 


. Specify the amount of time (in seconds) that the PCC must wait before deleting any non-delegated 
PCE-initiated LSPs from the failed PCE after a PCEP session terminates. 


[edit protocols pcep pce pce-id] 
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user@PCC# set Isp-cleanup-timer seconds 


9. Configure the PCC to accept SPs that are externally provisioned by connected PCEs. By default, the 
PCC rejects PCE-initiated LSPs. 


[edit protocols pcep pce pce-id] 
user@PCC# set Isp-provisioning 


10. Specify the number of unknown messages per minute that the PCC can receive at maximum after which 
the PCEP session is closed. 


[edit protocols pcep pce pce-id] 
user@PCC# set max-unknown-messages messages-per-minute 


The value can range from 1 through 16384, and the default value is O (disabled or no limit). 


11. Specify the number of unknown requests per minute that the PCC can receive at maximum after which 
the PCEP session is terminated. 


[edit protocols pcep pce pce-id] 
user@PCC# set max-unknown-requests requests-per-minute 


The value can range from O through 16384, and the default value is 5. A value of O disables this 
statement. 


12. Configure the PCE type. 


[edit protocols pcep pce pce-id] 
user@PCC# set pce-type active stateful 


13. Specify the amount of time (in seconds) that the PCC must wait for a reply before resending a request. 


[edit protocols pcep pce pce-id] 
user@PCC# set request-timer seconds 


The value can range from O through 65535 seconds. 


14. Verify and commit the configuration. 
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user@PCC# show 
user@PCC# commit 


Sample Output 


[edit] 
user@PCC# edit protocols pcep 


[edit protocols pcep] 





user@PCC# set message-rate-limit 50 


[edit protocols pcep] 


user@PCC# set max—provisioned-lsps 16000 


[edit protocols pcep] 
user@PCC# edit pce PCE 








a 


[edit protocols pcep pce PCE 





user@PCC# set delegation-cleanup-timeout 20 





[edit protocols pcep pce PCE] 
user@PCC# set destination-ipv4-address 192.168.69.58 





jy 


[edit protocols pcep pce PCE 
user@PCC# set destination-port 4189 





ay 


[edit protocols pcep pce PCE 





user@PCC# set lsp-cleanup-timer 50 





[edit protocols pcep pce PCE] 


user@PCC# set lsp-provisioning 





py 


[edit protocols pcep pce PCE 


user@PCC# set max-unknown-messages 5 





(eh 


[edit protocols pcep pce PCE 


user@PCC# set max-unknown-requests 5 





[edit protocols pcep pce PCE] 


user@PCC# set request-timer 50 





Fl 
a 


[edit protocols pcep pce PC 
user@PCC# up 


[edit protocols pcep] 
user@PCC# show 
message-rate-limit 50; 


max-provisioned-lsps 16000; 





pce PCE { 
destination-ipv4-address 192.168.69.58; 
destination-port 4189; 
lsp-provisioning; 
lsp-cleanup-timer 50; 
request-timer 50; 
max-unknown-requests 5; 


max-unknown-messages 5; 





delegation-cleanup-timeout 20; 


[edit protocols pcep] 
user@PCC# commit 


commit complete 


Example: Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support for 
PCE-Controlled Point-to-Multipoint LSPs 


IN THIS SECTION 


Requirements | 1406 
Overview | 1407 
Configuration | 1408 


Verification | 1421 


This example shows how to configure the Path Computation Client (PCC) with the capability of reporting 
point-to-multipoint traffic engineered label-switched paths (TE LSPs) to a Path Computation Element 
(PCE). 


Requirements 


This example uses the following hardware and software components: 


e Three routers that can be a combination of ACX Series, M Series, MX Series, or T Series routers. 


e One virtual machine configured with Virtual Route Reflector (VRR) feature. 
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e A TCP connection to an external stateful PCE from the VRR. 


e Junos OS Release 16.1 or later running on the PCC. 
Before you begin: 


e Configure the device interfaces. 
e Configure MPLS and RSVP-TE. 


e Configure OSPF or any other IGP protocol. 


Overview 


After a PCEP session is established between a PCE and a PCC, the PCC reports all the LSPs in the system 
to the PCE for LSP state synchronization. This includes PCC-controlled, PCE-delegated, and PCE-initiated 
point-to-point LSPs. Starting with Junos OS Release 15.1F6 and 16.1R1, this capability is extended to 
report point-to-multipoint LSPs as well. 


By default, PCE control of point-to-multipoint LSPs is not supported on a PCC. To add this capability, 
include the p2mp-Isp-report-capability statement at the [edit protocols pcep pce pce-name] or [edit 
protocols pcep pce-group group-id] hierarchy levels. 


Topology 


Figure 122: Example PCE-Controlled Point-to-Multipoint LSPs 
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em2 ge-0/ 0/3 1.2.5.0/30 ge-0/ 0/6 ge-0/ 0/9 2.3.2.0/30 ge-0/ 0/4 
Rg. nees0 ge-0/ 0/5 1.2.1.0/30 ge-0/ 0/7 ge-0/ 1/0 2.3.3.0/30 ge-0/ 0/5 
(VAR) ge-0/ 0/6 1.2.0.0/30 ge-0/ 0/1 ge-0/ 1/1 2.3.0.0/30 ge-0/ 0/0 
128.102.180.228/32 128.102.180.202/32 128.102.177.16/32 & 


In this example, PCC is the ingress router, Router R1 is the transit router, and Router R2 is the egress 
router. PCC is connected to a Virtual Route Reflector (VRR) that is connected to a PCE. There are many 
point-to-multipoint interfaces between PCC, Router R1, and Router R2. 
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The reporting of point-to-multipoint LSPs is executed as follows: 


1. 


If Router PCC is configured with point-to-point and point-to-multipoint LSPs without the support for 
point-to-multipoint reporting capability, only the point-to-point LSPs are reported to the connected 
PCE. By default, a PCC does not support point-to-multipoint LSP reporting capability. 


2. When Router PCC is configured with point-to-multipoint LSP reporting capability, PCC first advertises 
this capability to PCE through a report message. 

3. By default, a PCE provides support for point-to-multipoint LSP capability. On receiving the PCC’s 
advertisement for point-to-multipoint LSP capability, the PCE in return advertises its capability to the 
PCC. 

4. On receiving the PCE’s advertisement of the point-to-multipoint capability, PCC reports all branches 
of point-to-multipoint LSPs to the PCE using the update message. 

5. Once all the LSPs are reported to the PCE, LSP state is synchronized between the PCE and PCC. 

Configuration 


CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 


line breaks, change any details necessary to match your network configuration, and then copy and paste 
the commands into the CLI at the [edit] hierarchy level. 


PCC 


set interfaces ge-0/0/0 unit 0 family inet address 1.2.4.1/30 
set interfaces ge-0/0/0 unit 0 family mpls 
set interfaces ge-0/0/1 unit 0 family inet address 1.2.3.1/30 
set interfaces ge-0/0/1 unit 0 family mpls 
set interfaces ge-0/0/2 unit 0 family inet address 1.2.2.1/30 
set interfaces ge-0/0/2 unit 0 family mpls 
set interfaces ge-0/0/3 unit 0 family inet address 1.2.5.1/30 
set interfaces ge-0/0/3 unit 0 family mpls 
set interfaces ge-0/0/4 unit 0 family inet address 1.4.0.1/30 
set interfaces ge-0/0/4 unit 0 family mpls 
set interfaces ge-0/0/5 unit 0 family inet address 1.2.1.1/30 
set interfaces ge-0/0/5 unit 0 family mpls 
set interfaces ge-0/0/6 unit 0 family inet address 1.2.0.1/30 
set interfaces ge-0/0/6 unit 0 family mpls 
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set routing-options autonomous-system 100 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls Isp-external-controller pccd pce-controlled-Isp pcc_delegated_no_cspf_* 
label-switched-path-template Isp_template_no_cspf 

set protocols mpls Isp-external-controller pccd pce-controlled-Isp pce_initiated_no_ero_no_cspf_* 
label-switched-path-template Isp_template_no_cspf 

set protocols mpls Isp-external-controller pccd pce-controlled-Isp pce_initiated_loose_ero_no_cspf_* 
label-switched-path-template Isp_template_no_cspf 

set protocols mpls traffic-engineering database import policy TE 

set protocols mpls admin-groups violet 1 

set protocols mpls admin-groups indigo 2 

set protocols mpls admin-groups blue 3 

set protocols mpls admin-groups green 4 

set protocols mpls admin-groups yellow 5 

set protocols mpls admin-groups orange 6 

set protocols mpls label-switched-path Isp_template_no_cspf template 

set protocols mpls label-switched-path Isp_template_no_cspf no-cspf 

set protocols mpls label-switched-path Isp1-pcc to 128.102.177.16 

set protocols mpls label-switched-path Isp2-pcc to 128.102.177.116 

set protocols mpls label-switched-path Isp2-pcc Isp-external-controller pccd 

set protocols mpls path loose-path 1.2.3.2 loose 

set protocols mpls path strict-path 1.2.3.2 strict 

set protocols mpls path strict-path 2.3.3.2 strict 

set protocols mpls path path-B 

set protocols mpls path path-C 

set protocols mpls interface all 

set protocols mpls interface ge-0/0/6.0 admin-group violet 

set protocols mpls interface ge-0/0/5.0 admin-group indigo 

set protocols mpls interface ge-0/0/2.0 admin-group blue 

set protocols mpls interface ge-0/0/1.0 admin-group green 

set protocols mpls interface ge-0/0/0.0 admin-group yellow 

set protocols mpls interface ge-0/0/3.0 admin-group orange 

set protocols mpls interface fxp0.0 disable 

set protocols bgp group northstar type internal 

set protocols bgp group northstar local-address 128.102.180.228 

set protocols bgp group northstar family traffic-engineering unicast 

set protocols bgp group northstar export TE 

set protocols bgp group northstar neighbor 128.102.180.215 

set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/6.0 
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set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p 
set protocols pcep pce pcel local-address 10.102.180.228 

set protocols pcep pce pcel destination-ipv4-address 100.102.180.246 
set protocols pcep pce pcel destination-port 4189 

set protocols pcep pce pcei pce-type active 

set protocols pcep pce pcel pce-type stateful 

set protocols pcep pce pce Isp-provisioning 

set protocols pcep pce pcel Isp-cleanup-timer 0 

set protocols pcep pce pce1 delegation-cleanup-timeout 60 

set protocols pcep pce pce1 p2mp-lsp-report-capability 

set policy-options policy-statement TE term 1 from family traffic-engineering 
set policy-options policy-statement TE term 1 then accept 


set interfaces ge-0/0/0 unit 0 family inet address 2.3.4.1/30 
set interfaces ge-0/0/0 unit 0 family mpls 
set interfaces ge-0/0/1 unit 0 family inet address 1.2.0.2/30 
set interfaces ge-0/0/1 unit 0 family mpls 
set interfaces ge-0/0/2 unit 0 family inet address 1.2.4.2/30 
set interfaces ge-0/0/2 unit 0 family mpls 
set interfaces ge-0/0/3 unit 0 family inet address 1.2.2.2/30 
set interfaces ge-0/0/3 unit 0 family mpls 
set interfaces ge-0/0/4 unit 0 family inet address 2.3.1.1/30 
set interfaces ge-0/0/4 unit 0 family mpls 
set interfaces ge-0/0/5 unit 0 family inet address 1.2.3.2/30 
set interfaces ge-0/0/5 unit 0 family mpls 
set interfaces ge-0/0/6 unit 0 family inet address 1.2.5.2/30 
set interfaces ge-0/0/6 unit 0 family mpls 
set interfaces ge-0/0/7 unit 0 family inet address 1.2.1.2/30 
set interfaces ge-0/0/7 unit 0 family mpls 
set interfaces ge-0/0/8 unit 0 family inet address 2.3.5.1/30 
set interfaces ge-0/0/8 unit 0 family mpls 
set interfaces ge-0/0/9 unit 0 family inet address 2.3.2.1/30 
set interfaces ge-0/0/9 unit 0 family mpls 
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set interfaces ge-0/1/0 unit 0 family inet address 2.3.3.1/30 
set interfaces ge-0/1/0 unit 0 family mpls 

set interfaces ge-0/1/1 unit 0 family inet address 2.3.0.1/30 
set interfaces ge-0/1/1 unit 0 family mpls 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls admin-groups violet 1 

set protocols mpls admin-groups indigo 2 

set protocols mpls admin-groups blue 3 

set protocols mpls admin-groups green 4 

set protocols mpls admin-groups yellow 5 

set protocols mpls admin-groups orange 6 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols mpls interface ge-0/0/1.0 admin-group violet 
set protocols mpls interface ge-0/0/7.0 admin-group indigo 
set protocols mpls interface ge-0/0/3.0 admin-group blue 
set protocols mpls interface ge-0/0/5.0 admin-group green 
set protocols mpls interface ge-0/0/2.0 admin-group yellow 
set protocols mpls interface ge-0/0/6.0 admin-group orange 
set protocols mpls interface ge-0/1/1.0 admin-group violet 
set protocols mpls interface ge-0/0/4.0 admin-group indigo 
set protocols mpls interface ge-0/0/9.0 admin-group blue 
set protocols mpls interface ge-0/1/0.0 admin-group green 
set protocols mpls interface ge-0/0/0.0 admin-group yellow 
set protocols mpls interface ge-0/0/8.0 admin-group orange 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/7.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/6.0 

set protocols ospf area 0.0.0.0 interface ge-0/1/1.0 


set interfaces ge-0/0/0 unit 0 family inet address 2.3.0.2/30 
set interfaces ge-0/0/0 unit 0 family mpls 
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set interfaces ge-0/0/1 unit 0 family inet address 2.3.1.2/30 
set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 2.3.5.2/30 
set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 2.3.4.2/30 
set interfaces ge-0/0/3 unit 0 family mpls 

set interfaces ge-0/0/4 unit 0 family inet address 2.3.2.2/30 
set interfaces ge-0/0/4 unit 0 family mpls 

set interfaces ge-0/0/5 unit 0 family inet address 2.3.3.2/30 
set interfaces ge-0/0/5 unit 0 family mpls 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls admin-groups violet 1 

set protocols mpls admin-groups indigo 2 

set protocols mpls admin-groups blue 3 

set protocols mpls admin-groups green 4 

set protocols mpls admin-groups yellow 5 

set protocols mpls admin-groups orange 6 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols mpls interface ge-0/0/0.0 admin-group violet 
set protocols mpls interface ge-0/0/1.0 admin-group indigo 
set protocols mpls interface ge-0/0/4.0 admin-group blue 
set protocols mpls interface ge-0/0/5.0 admin-group green 
set protocols mpls interface ge-0/0/3.0 admin-group yellow 
set protocols mpls interface ge-0/0/2.0 admin-group orange 
set protocols ospf traffic-engineering 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface lo0.0 passive 


set interfaces em0 unit O family inet address 10.102.180.215/19 


set interfaces em1 unit O family inet address 4.5.0.1/30 
set interfaces em2 unit O family inet address 1.4.0.2/30 
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set interfaces em2 unit O family mpls 

set routing-options router-id 128.102.180.215 

set routing-options autonomous-system 100 

set protocols topology-export 

set protocols rsvp interface all 

set protocols mpls Isp-external-controller pccd 

set protocols mpls traffic-engineering database import igp-topology 
set protocols mpls traffic-engineering database import policy TE 
set protocols mpls interface all 

set protocols bgp group northstar type internal 

set protocols bgp group northstar local-address 128.102.180.215 
set protocols bgp group northstar family traffic-engineering unicast 
set protocols bgp group northstar neighbor 128.102.180.228 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface em2.0 interface-type p2p 
set policy-options policy-statement TE from family traffic-engineering 
set policy-options policy-statement TE then accept 


Step-by-Step Procedure 


The following example requires you to navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode. 


To configure the PCC router: 


1. Configure the interfaces of Router PCC. To enable MPLS, include the protocol family on the interface 
so that the interface does not discard incoming MPLS traffic. 


[edit interfaces] 

user@PCC# set ge-0/0/0 unit 0 family inet address 1.2.4.1/30 
user@PCC# set ge-0/0/0 unit O family mpls 

user@PCC# set ge-0/0/1 unit 0 family inet address 1.2.3.1/30 
user@PCC# set ge-0/0/1 unit O family mpls 

user@PCC# set ge-0/0/2 unit O family inet address 1.2.2.1/30 
user@PCC# set ge-0/0/2 unit 0 family mpls 

user@PCC# set ge-0/0/3 unit O family inet address 1.2.5.1/30 
user@PCC# set ge-0/0/3 unit 0 family mpls 

user@PCC# set ge-0/0/4 unit 0 family inet address 1.4.0.1/30 
user@PCC# set ge-0/0/4 unit 0 family mpls 

user@PCC# set ge-0/0/5 unit O family inet address 1.2.1.1/30 
user@PCC# set ge-0/0/5 unit 0 family mpls 

user@PCC# set ge-0/0/6 unit 0 family inet address 1.2.0.1/30 
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user@PCC# set ge-0/0/6 unit O family mpls 


2. Configure the autonomous system number for Router PCC. 


[edit routing-options] 
user@PCC# set autonomous-system 100 


3. Enable RSVP on all interfaces of Router PCC, excluding the management interface. 


[edit protocols] 
user@PCC# set rsvp interface all 
user@PCC# set rsvp interface fxp0.0 disable 


4. Enable MPLS on all the interfaces of Router PCC, excluding the management interface. 


[edit protocols] 
user@PCC# set mpls interface all 
user@PCC# set mpls interface fxp0.0 disable 


5. Configure a dynamic LSP and disable automatic path computation for the LSP. 


[edit protocols] 
user@PCC# set mpls label-switched-path Isp_template_no_cspf template 
user@PCC# set mpls label-switched-path Isp_template_no_cspf no-cspf 


6. Configure point-to-multipoint LSPs and define external path computing entity for the LSP. 


[edit protocols] 

user@PCC# set mpls label-switched-path Isp1-pcc to 128.102.177.116 
user@PCC# set mpls label-switched-path Isp2-pcc to 128.102.177.116 
user@PCC# set mpls label-switched-path Isp2-pcc Isp-external-controller pccd 


7. Enable external path computing for the MPLS LSPs and assign a template for externally provisioned 
LSPs. 


[edit protocols] 
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user@PCC# set mpls Isp-external-controller pccd pce-controlled-Isp pcc_delegated_no_cspf_* 
label-switched-path-template Isp_template_no_cspf 

user@PCC# set mpls Isp-external-controller pccd pce-controlled-Isp pce_initiated_no_ero_no_cspf_* 
label-switched-path-template Isp_template_no_cspf 

user@PCC# set mpls Isp-external-controller pccd pce-controlled-Isp pce_initiated_loose_ero_no_cspf_* 
label-switched-path-template Isp_template_no_cspf 


8. Configure the LSPs that have local control and are overridden by the PCE-provided LSP parameters. 


[edit protocols] 

user@PCC# set mpls path loose-path 1.2.3.2 loose 
user@PCC# set mpls path strict-path 1.2.3.2 strict 
user@PCC# set mpls path strict-path 2.3.3.2 strict 
user@PCC# set mpls path path-B 

user@PCC# set mpls path path-C 


9. Configure MPLS administrative group policies for constrained-path LSP computation. 


[edit protocols] 

user@PCC# set mpls admin-groups violet 1 
user@PCC# set mpls admin-groups indigo 2 
user@PCC# set mpls admin-groups blue 3 
user@PCC# set mpls admin-groups green 4 
user@PCC# set mpls admin-groups yellow 5 
user@PCC# set mpls admin-groups orange 6 


10. Assign the configured administrative group policies to Router PCC interfaces. 


[edit protocols] 

user@PCC# set mpls interface ge-0/0/6.0 admin-group violet 
user@PCC# set mpls interface ge-0/0/5.0 admin-group indigo 
user@PCC# set mpls interface ge-0/0/2.0 admin-group blue 
user@PCC# set mpls interface ge-0/0/1.0 admin-group green 
user@PCC# set mpls interface ge-0/0/0.0 admin-group yellow 
user@PCC# set mpls interface ge-0/0/3.0 admin-group orange 


11. Configure a traffic engineering database (TED) import policy. 


[edit protocols] 
user@PCC# set mpls traffic-engineering database import policy TE 
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12. Configure a BGP internal group. 


[edit protocols] 

user@PCC# set bgp group northstar type internal 

user@PCC# set bgp group northstar local-address 128.102.180.228 
user@PCC# set bgp group northstar neighbor 128.102.180.215 


13. Configure traffic engineering for BGP and assign the export policy. 


[edit protocols] 
user@PCC# set bgp group northstar family traffic-engineering unicast 
user@PCC# set bgp group northstar export TE 


14. Configure OSPF area 0 on all the point-to-multipoint interfaces of Router PCC. 


[edit protocols] 

user@PCC# set ospf area 0.0.0.0 interface lo0.0 
user@PCC# set ospf area 0.0.0.0 interface ge-0/0/6.0 
user@PCC# set ospf area 0.0.0.0 interface ge-0/0/5.0 
user@PCC# set ospf area 0.0.0.0 interface ge-0/0/2.0 
user@PCC# set ospf area 0.0.0.0 interface ge-0/0/1.0 
user@PCC# set ospf area 0.0.0.0 interface ge-0/0/0.0 
user@PCC# set ospf area 0.0.0.0 interface ge-0/0/3.0 


15. Configure OSPF area O on the point-to-point interface of Router PCC. 


[edit protocols] 
user@PCC# set ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p 


16. Enable traffic engineering for OSPF. 


[edit protocols] 
user@PCC# set ospf traffic-engineering 


17. Define the PCE that Router PCC connects to, and configure the the PCE parameters. 


[edit protocols] 
user@PCC# set pcep pce pce! local-address 10.102.180.228 
user@PCC# set pcep pce pcel destination-ipv4-address 10.102.180.246 
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user@PCC# set pcep pce pce1 destination-port 4189 
user@PCC# set pcep pce pce1 pce-type active 

user@PCC# set pcep pce pce1 pce-type stateful 

user@PCC# set pcep pce pce1 Isp-provisioning 

user@PCC# set pcep pce pce1 Isp-cleanup-timer O 
user@PCC# set pcep pce pce1 delegation-cleanup-timeout 60 


18. Configure Router PCC to enable point-to-multipoint LSP capability for external path computing. 


[edit protocols] 
set pcep pce pce1 p2mp-Isp-report-capability 


19. Configure the traffic engineering policy. 


[edit policy-options] 
user@PCC# set policy-statement TE term 1 from family traffic-engineering 
user@PCC# set policy-statement TE term 1 then accept 


Results 


From configuration mode, confirm your configuration by entering the show interfaces and show protocols 
commands. If the output does not display the intended configuration, repeat the instructions in this example 
to correct the configuration. 


user@PCC# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 1.2.4.1/30; 
} 


family mpls; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 1.2.3.1/30; 
} 


family mpls; 


ge-0/0/2 { 
unit O { 
family inet { 
address 1.2.2.1/30; 
} 


family mpls; 


} 
ge-0/0/3 { 
unit O { 
family inet { 
address 1.2.5.1/30; 
} 


family mpls; 


} 
ge-0/0/4 { 
unit O { 
family inet { 
address 1.4.0.1/30; 
} 


family mpls; 


} 
ge-0/0/5 { 
unit O { 
family inet { 
address 1.2.1.1/30; 
} 


family mpls; 


} 
ge-0/0/6 { 
unit O { 
family inet { 
address 1.2.0.1/30; 
} 


family mpls; 


user@PCC# show protocols 
rsvp { 
interface all; 
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interface fxp0.0 { 
disable; 


} 
mpls { 
Isp-external-controller pccd { 
pce-controlled-Isp pcc_delegated_no_cspf_* { 
label-switched-path-template { 
Isp_template_no_cspf; 


} 
pce-controlled-Isp pce_initiated_no_ero_no_cspf_* { 
label-switched-path-template { 
Isp_template_no_cspf; 


} 
pce-controlled-Isp pce_initiated_loose_ero_no_cspf_* { 
label-switched-path-template { 
Isp_template_no_cspf; 


} 
traffic-engineering { 
database { 
import { 
policy TE; 


} 
admin-groups { 
violet 1; 
indigo 2; 
blue 3; 
green 4; 
yellow 5; 
orange 6; 
} 
label-switched-path Isp_template_no_cspf { 
template; 
no-cspf; 
} 
label-switched-path Isp1-pcc { 
to 128.102.177.16; 
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label-switched-path Isp2-pcc { 
to 128.102.177.16; 
Isp-external-controller pccd; 

} 

path loose-path { 
1.2.3.2 loose; 

} 

path strict-path { 
1.2.3.2 strict; 
2.3.3.2 strict; 

} 

path path-B; 

path path-C; 

interface all; 

interface ge-0/0/6.0 { 
admin-group violet; 

} 

interface ge-0/0/5.0 { 
admin-group indigo; 

} 

interface ge-0/0/2.0 { 
admin-group blue; 

} 

interface ge-0/0/1.0 { 
admin-group green; 

} 

interface ge-0/0/0.0 { 
admin-group yellow; 

} 

interface ge-0/0/3.0 { 
admin-group orange; 

} 

interface fxp0.0 { 
disable; 


} 
bgp { 
group northstar { 
type internal; 
local-address 128.102.180.228; 
family traffic-engineering { 
unicast; 

} 
export TE; 


neighbor 128.102.180.215; 


} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface 100.0; 
interface ge-0/0/6.0; 
interface ge-0/0/5.0; 
interface ge-0/0/2.0; 
interface ge-0/0/1.0; 
interface ge-0/0/0.0; 
interface ge-0/0/3.0; 
interface ge-0/0/4.0 { 
interface-type p2p; 


} 
pcep { 
pce pcel { 

local-address 10.102.180.228; 
destination-ipv4-address 10.102.180.246; 
destination-port 4189; 
pce-type active stateful; 
Isp-provisioning; 
Isp-cleanup-timer O; 
delegation-cleanup-timeout 60; 
p2mp-lsp-report-capability; 


Verification 


IN THIS SECTION 


@ Verifying LSP Configuration on the PCC | 1422 
@ Verifying PCE Configuration on the PCC | 1425 


Confirm that the configuration is working properly. 
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Verifying LSP Configuration on the PCC 


Purpose 


Verify the LSP type and running state of the point-to-multipoint LSP. 
Action 


From operational mode, run the show mpls Isp extensive command. 


user@PCC> show mpls lsp extensive 


Ingress LSP: 2 sessions 


128. 102 177 9 6 
From: 128.102.180.228, State: Up, ActiveRoute: 0, LSPname: lspl-pcc 
ActivePath: (primary) 

LSPtype: Static Configured, Penultimate hop popping 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


be 





Primary Seaces Wis 
Priorities: 7 0 
SmartOptimizeTimer: 180 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2) 
Loacloe S 2s3e0ce S 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
ZO Noce San): 
LeBsl ke 2o3s0.2 
Jul 12 14:44:1 
wiolil al Ikal gelato 
2 a aar 








0.620 Selected as active path 

O,617 Recor Rowces LoA2cle4 2o3.U62 
O56iLS Us 

Jul 12 14:44:10.175 Originate Call 
Jul 12 14:44:10 

AL opel 1h LA Sh ala 

2 


Created: Tue Jul 1 


ISy tes) Ss onl en 
aa) 
Ga 


,L74 CSBPs CGolniswitaiciom result acecsisc 1.2.1.2 2.3.0.2 
.442 CSPF failed: no route toward 128.102.177.16[2 times] 
14:42:43 2016 











LAS 61026177 1S 
From: 128.102.180.228, State: Up, ActiveRoute: 0, LSPname: Isp2-pcc 
ActivePath: (primary) 
LSPtype: Externally controlled - static configured, Penultimate hop popping 
LSP Control Status: Externally controlled 


LoadBalance: Random 





Encoding type: Packet, Switching type: Packet, GPID: IPv4 





+ 


Primary Staces Wis) 


Piewereicaess 7 (0) 





External Path CSPF Status: external 
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SmartOptimizeTimer: 180 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID): 
LoAste® BoSsOe2 
50 Jul 12 14:50:14.699 EXTCTRL LSP: Sent Path computation request and LSP status 








49 Jul 12 14:50:14.698 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
48 Jul 12 14:49:27.859 EXTCTRL LSP: Sent Path computation request and LSP status 





47 Jul 12 14:49:27.859 EXTCTRL_LSP: Computation request/lsp status contains: 
signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
46 Jul 12 14:49:27.858 EXTCTRL LSP: Sent Path computation request and LSP status 





ASS Ul ATAS Ove oOo <LOlR thor a Conpledeloneneqlest/ lSpestatusmeoneatmar 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
44 Jul 12 14:49:27.858 EXTCTRL_LSP: Control status became external 


43 Jul 12 14:49:03.746 EXTCTRL_LSP: Control status became local 
































42 Jul 12 14:46:52.367 EXTCTRL LSP: Sent Path computation request and LSP status 





41 Jul 12 14:46:52.367 EXTCTRL_LSP: Computation request/lsp status contains: 
signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
40 Jul 12 14:46:52.367 EXTCTRL LSP: Sent Path computation request and LSP status 





39 Jul 12 14:46:52.366 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
38 Jul 12 14:46:52.366 EXTCTRL_LSP: Control status became external 
37 Jul 12 14:46:41.584 Selected as active path 
S16 Wull 12 Iasaoedil S65 Recome Reoures boAs4o4% 2o5e0n% 
35 Jul 12 14:46:41.565 Up 
34 Jul 12 14:46:41.374 EXTCTRL_LSP: Applying local parameters with this 





signalling attempt 
33 Jul 12 14:46:41.374 Originate Call 
S52 sul 12 lagAoeail g74 Sirs Genismesiciem resume aeceocecl 1.2.4.2 2.3.0.2 
31 Jul 12 14:46:28.254 EXTCTRL LSP: Control status became local 
30 Jul 12 14:46:12.494 EXTCTRL LSP: Sent Path computation request and LSP status 




















Zo ol el AL Gen oA ch GLRimlGl Como lEdt onus qUesity/ sls pmsind EUISme Olnleaeninst 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 


setup 7 hold 0 
28 Jul 12 14:45:43.164 EXTCTRL LSP: Sent Path computation request and LSP status 





27 Jul 12 14:45:43.164 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
26 Jul 12 14:45:13.424 EXTCTRL LSP: Sent Path computation request and LSP status 





Cecile Zee hn om xe hms Sem COMmpltecitekOleeac CUcsity als pmciad llsme Olle alimnse: 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
24 Jul 12 14:44:44.774 EXTCTRL LSP: Sent Path computation request and LSP status 





23 Jul 12 14:44:44.773 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
22 Jul 12 14:44:15.053 EXTCTRL LSP: Sent Path computation request and LSP status 





21 Jul 12 14:44:15.053 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
20 Jul 12 14:43:45.705 EXTCTRL LSP: Sent Path computation request and LSP status 





19 Jul 12 14:43:45.705 EXTCTRL_LSP: Computation request/lsp status contains: 
signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
18 Jul 12 14:43:45.705 EXTCTRL LSP: Sent Path computation request and LSP status 





17 Jul 12 14:43:45.705 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
16 Jul 12 14:43:45.705 EXTCTRL_LSP: Control status became external 


15 gull 12 Ilaeascae 398 CSpw rasallecle me ours cowaiccl 128 102,177.16 
LEAS Ol eer O0 Oe XG mh ol mi COM tol mEStecislicmoceameushecalks 
































13 Jul 12 14:43:13.009 EXTCTRL LSP: Sent Path computation request and LSP status 





12 Jul 12 14:43:13.008 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
11 Jul 12 14:42:43.343 EXTCTRL LSP: Sent Path computation request and LSP status 





10 Jul 12 14:42:43.343 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
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9 Jul 12 14:42:43.343 EXTCTRL LSP: Sent Path computation request and LSP status 





8 Jul 12 14:42:43.343 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
7 Jul 12 14:42:43.342 EXTCTRL LSP: Sent Path computation request and LSP status 





6 Jul 12 14:42:43.342 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
5 Jul 12 14:42:43.341 EXTCTRL_LSP: Control status became external 


4 Jul 12 14:42:43.337 EXTCTRL_LSP: Control status became local 


3 Jul 12 14:42:43.323 EXTCTRL LSP: Sent Path computation request and LSP status 
































2a lea Ass Zoe xXIGLRimwhob  ConpubaLtonmrecuesty lmspmctakUsmeomtzatmmsh: 





signalled bw 0 req BW 0 admin group(exclude 0 include any 0 include all 0) priority 
setup 7 hold 0 
1 Jul 12 14:42:43.258 EXTCTRL LSP: Awaiting external controller connection 
Created: Tue Jul 12 14:42:43 2016 
Total 2 displayed, Up 2, Down 0 








Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 
The output displays the Isp2-pcc LSP as the PCE-controlled LSP. 


Verifying PCE Configuration on the PCC 


Purpose 


Verify the PCE parameters configuration and PCE state. 
Action 


From operational mode, run the show path-computation-client active-pce command. 


user@PCC> show path-computation-client active-pce 





PCE pcel 





General 
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LS 
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PIC! 


P2MP 
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E Status 











E IP address 
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P2MP LSP report allowed : On 
P2MP LSP update allowed 


LSP init allowed 
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PCReqs kore: 
PCReps Total: 
PCRpts Molecule 
PCUpdates dx@jteculme 
PCCreates Total: 
Timers 
Local Keepalive timer: 
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Remote Keepalive timer: 
Om esi 
Errors 
PCErr-recv 
PCErr-sent 
Type: 1 
PCH CCN eS 
PROCS = INES) 
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LSP cleanup timer: 


LSP cleanup timer: 


12 


The output displays the active PCE that Router PCC is connected to, and the pce1 PCE parameters and 


state. 
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Understanding Path Computation Element Protocol for MPLS RSVP-TE with Support for 
PCE-Initiated Point-to-Multipoint LSPs 


IN THIS SECTION 


@ Benefits of PCE-Initiated Point-to-Multipoint LSPs | 1427 

@ Signaling of PCE-Initiated Point-to-Multipoint LSPs | 1427 

@ Behavior of PCE-Initiated Point-to-Multipoint LSPs After PCEP Session Failure | 1428 
@ = Configuring PCE-Initiated Point-to-Multipoint LSP Capability | 1428 

@ Supported and Unsupported Features for PCE-Initiated Point-to-Multipoint LSPs | 1428 
e 


Mapping PCE-initiated Point-To-Multipoint LSPs to MVPN | 1429 


With the introduction of point-to-multipoint PCE-initiated LSPs, a PCE can initiate and provision a 
point-to-multipoint LSP dynamically without the need for local LSP configuration on the PCC. This enables 
the PCE to control the timing and sequence of the point-to-multipoint path computations within and across 
Path Computation Element Protocol (PCEP) sessions, thereby creating a dynamic network that is centrally 
controlled and deployed. 


Benefits of PCE-Initiated Point-to-Multipoint LSPs 


Meets the requirements of point-to-multipoint traffic engineering LSP placement in response to application 
demands through dynamic creation and tear down of point-to-multipoint LSPs, thereby creating a dynamic 
network that is centrally controlled and deployed. 


Signaling of PCE-Initiated Point-to-Multipoint LSPs 

The signaling of PCE-initiated point-to-multipoint LSPs is as follows: 

e When a new branch is added (Grafting)—Only the new branch sub-LSP is signaled and does not result 
in re-signaling of the entire point-to-multipoint tree. 


If any topology changes occurred before provisioning of the new sub-LSP, then the Path Computation 
Server (PCS) re-computes the entire point-to-multipoint tree and updates the point-to-multipoint LSP 
using a PC update message. 


e When a branch is deleted (Pruning)—The deleted branch sub-LSP is torn down and does not result in 
re-signaling of the entire point-to-multipoint tree. 


e When a branch sub-LSP parameter is changed—Change in sub-LSP parameters, such as Explicit Route 
Object (ERO), bandwidth, or priority, can happen either because of optimization, or on user request. If 
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there is a re-signaling request for a sub-LSP, the entire point-to-multipoint tree is re-signaled, and then 
the switchover to the new instance happens once the new instances of all the branches are up. 


e When a branch sub-LSP path fails—An error is reported to the PCS for the failed branch sub-LSP. On 
receiving the new ERO from the PCS, the entire point-to-multipoint tree is re-signaled along with the 
failed branch sub-LSP, and the switchover to the new instance happens in a make-before-break (MBB) 
fashion. 

Behavior of PCE-Initiated Point-to-Multipoint LSPs After PCEP Session Failure 


When a PCEP session fails, the PCE-initiated point-to-multipoint LSPs are orphaned until the expiration 
of the state timeout timer. After the state timeout timer expires, the PCE-initiated LSPs are cleaned up. 


To obtain control of a PCE-initiated point-to-multipoint LSP after a PCEP session failure, the primary or 
secondary PCE sends a PCInitiate message before the state timeout timer expires. 


Configuring PCE-Initiated Point-to-Multipoint LSP Capability 


By default, the creation and provisioning of point-to-multipoint LSPs by a PCE is not supported on a PCC. 
To enable this capability, include the p2mp-Isp-init-capability and p2mp-Isp-update-capability statements 
at the [edit protocols pcep pce pce-name] or [edit protocols pcep pce-group group-id] hierarchy levels. 


The p2mp-lsp-init-capability statement provides the capability to provision point-to-multipoint RSVP-TE 
LSPs by a PCE. The p2mp-lsp-update-capability statement provides the capability to update 
point-to-multipoint RSVP-TE LSP parameters by a PCE. 


Supported and Unsupported Features for PCE-Initiated Point-to-Multipoint LSPs 


The following features are supported with PCE-initiated point-to-multipoint LSPs: 


e Partial compliance with the Internet draft draft-ietf-pce-stateful-pce-p2mp (expires October 2018), Path 
Computation Element (PCE) Protocol Extensions for Stateful PCE usage for Point-to-Multipoint Traffic 
Engineering Label Switched Paths. 


The following features are not supported with PCE-initiated point-to-multipoint LSPs: 


e Delegation of point-to-multipoint locally controlled LSP. 

e LSP control delegation. 

e Interior gateway protocol (IGP) extension for PCE discovery within an IGP routing domain. 
e Request/response messaging. 

e Direct movement of branch sub-LSP from one point-to-multipoint tree to another. 


The same can be achieved by deleting a branch sub-LSP from the first point-to-multipoint tree and 
re-adding it to another after the PCReport message indicates LSP removal from the device. 


e IPvé6 is not supported. 


e SERO based signalling is not supported. 
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e Empty-ERO feature is not supported. 


e Link protection is not supported. 


Mapping PCE-initiated Point-To-Multipoint LSPs to MVPN 


You can associate a single or range of MVPN multicast flows (S,G) to a dynamically created PCE-initiated 
point-to-multipoint label-switched path (LSP). You can specify only selective types of flows for this feature 
to work. This includes: 


e Route distinguisher (RD) which is mapped to the MVPN routing-instance. 


e (S,G) which is the source of a multicast packet and destination multicast group address. This is used to 
filter incoming traffic for mapping it to the tunnel. 


e Point-to-multipoint LSP that is used to send traffic that matches the above-mentioned flow specification. 


For more details, see Internet draft draft-ietf-pce-pcep-flowspec-05 (expires February 16, 2020) PCEP 
Extension for Flow Specification. 


The current implementation of this feature does not implement the following sections of the draft: 


e Section 3.1.2—Advertising PCE capabilties in IGP 
e Section 3.2—PCReq and PCRep message 


e Section 7—Most of the flow specifications, except route distinguThe current implementation of this 
feature does not supporisher and IPv4 multicast flow specifications, are not supported. 


To enable the mapping of PCE-initiated point-to-multipoint LSPs to MVPN: 


e Include the pce_traffic_steering statement at the [edit protocols pcep pce pce-id] hierarchy level to 
indicate the support for flow specification capability (also called traffic steering) by the PCC. 


e Include the external-controller statement at the [edit routing-instances routing-instance-name 
provider-tunnel] hierarchy level. 


The presence of external-controller in the provider-tunnel configuration for MVPN indicates that the 
point-to-multipoint LSP and (S,G) for this MVPN instance can be provided by the external controller. 
This enables the external controller to dynamically configure (S,G) and point-to-multipoint LSP for MVPN. 


Take the following into consideration for mapping of PCE-initiated point-to-multipoint LSPs to MVPN: 


e If you do not enable the external-controller pccd statement for a particular MVPN instance, then the 
PCCD process does not configure (S,G) dynamically. 


e If you disable the external-controller pccd configuration from the CLI, then the dynamically learned 
multicast flows (S,G) for that particular MVPN instance is deleted and reported to the external controller. 


e When (S,G) is already configured from the CLI, the PCC cannot configure (S,G) dynamically as local 
configuration has a higher priority. 


If any particular (S,G) is learned from the external controller dynamically and then you configure the 
same (S,G) for the same MVPN instance, then the dynamically learned (S,G) is deleted and reported to 
the external controller through the PCC. 


If the routing protocol process reboots, then the PCCD process reconfigures all the (S,G) again. 
If the PCCD process reboots, then MVPN reports all PCCD configured (S,G) to the external controller. 


If user enables external-controller pccd for a particular MVPN instance, then MVPN requests the PCCD 
process to configure (S,G), if any present. 


If there are major configuration changes to a particular MPVN instance, then MVPN requests the PCCD 
process to reconfigure all (S,G) for that particular MVPN instance. 


All flow specifications associated with any PCE-initiated point-to-multipoint LSP must have the same 
RD. During PC initiation if all flow specifications do not have the same RD, then the PC initiate message 
is dropped with an error. 


You can associate a point-to-multipoint LSP only with selective type of flow specifications, otherwise 
the PC initiate message is dropped with an error. 


During PC update if all flow specifications do not have same the RD either due to a new flow specification 
addition, or due to existing flow specification update, then the PCC drops the update message. 


During PC update if all flow specifications do not meet the selective condition either due to new flow 
specification addition, or due to existing flow specifications update, then the PCC drops the update 
message. 


Behavior for mapping of PCE-initiated point-to-multipoint LSP with MVPN routing-instance and mapping 
of static (locally configured) point-to-multipoint LSP with MVPN instance is the same at user level. 


A flow specification ID can be associated with only one point-to-multipoint LSP. To associate the same 
RD and (S,G) to multiple point-to-multipoint LSPs, you can add multiple flow specifications with different 
IDs and same RD & (S,G). 


For PCEP-mapped dynamic (S,G), the threshold value is always the default value of 0. 


There is no limit on the number of flow specifications mapped to a single PCE-initiated point-to-multipoint 
LSP. 


The current implementation of this feature does not support: 

e Reporting of forwarding states that are associated with the point-to-multipoint LSP. 
e Inclusive provider tunnel dynamic configuration 

e Mapping for MVPN ingress replication tunnel 


e Programmable routing protocol process (prpd) 


e 


Reporting of CLI configured point-to-multipoint LSP which is mapped to MVPN multicast flows (S,G). 
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Enable Segment Routing for the Path Computation Element Protocol 


SUMMARY IN THIS SECTION 


@ Segment Routing for the Path Computation 
You can enable segment routing or Source Packet Element Protocol Overview | 1431 


Routing in Networking (SPRING) traffic-engineering 
(SR-TE) with the Path Computation Element Protocol 
(PCEP) for traffic steering. With this support, the 
advantages of segment routing are extended to the 
label-switched paths (LSPs) that are externally 
controlled by a Path Computation Element (PCE). 


@ ~=Example: Configure Segment Routing for the 
Path Computation Element Protocol | 1439 


Segment Routing for the Path Computation Element Protocol Overview 


IN THIS SECTION 


Benefits of Segment Routing for PCEP | 1431 
Segment Routing for Traffic Engineering | 1432 
Junos OS Implementation of Segment Routing for PCEP | 1432 


Segment Routing for PCEP Limitations and Unsupported Features | 1438 


Benefits of Segment Routing for PCEP 


e Setting up of LSPs through an external controller provides a global view of per-LSP and per-device 
bandwidth demand on the network, enabling online and real-time constraint-based path computation. 


The advantages of segment routing are extended to the LSPs initiated by an external controller, also 
known as a Path Computation Element (PCE), augmenting the benefits of external path computing in 
an MPLS network. 


e A Path Computation Client (PCC, which is an ingress MX Series router) with delegation capability can 
take back control of the delegated segment routing LSPs from the PCE when the PCEP session goes 
down; the LSPs would otherwise be deleted from the PCC. You can thus ensure LSP data protection by 
averting a situation where packets are silently discarded or dropped (also known as a traffic black-hole 
condition). 
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Segment Routing for Traffic Engineering 


Segment routing can operate over an IPv4 or IPvé data plane, and supports equal-cost multipath (ECMP). 
With the IGP extensions built into it, segment routing integrates with the rich multiservice capabilities of 
MPLS, including Layer 3 VPN, Virtual Private Wire Service (VPWS), Virtual Private LAN Service (VPLS), 
and Ethernet VPN (EVPN). 


Some of the high-level components of the segment routing-traffic engineering (SR-TE) solution include: 


e Use of an IGP for advertising link characteristics. This functionality is similar to RSVP-TE. 
e Use of Constrained Shortest Path First (CSPF) on the ingress device or the PCE. 
e Use of an IGP for advertising labels for links. 


In SR-TE functionality: 


1. The ingress device constructs an LSP by stacking the labels of the links that it wants to traverse. 


2. The per-link IGP advertisement is combined with label stacking to create source-routed LSPs on the 
ingress device, so the transit devices are not aware of the end-to-end LSPs. 


3. LSPs are created between edge nodes without placing any per-LSP memory requirements on the 
transit devices. (Creation of such LSPs is enabled as there is no per-LSP signaling in SR-TE.) 


4. Per-neighbor labels are stacked, which results in the management of a large number of labels, leading 
to control plane scaling. 


Junos OS Implementation of Segment Routing for PCEP 


IN THIS SECTION 


@ ~=PCE-Initiated Segment Routing LSPs | 1432 
@  PCE-Delegated Segment Routing LSPs | 1434 


Junos OS implements segment routing for PCEP for two types of LSPs—PCE-initiated LSPs and 
PCE-delegated LSPs. 


PCE-Initiated Segment Routing LSPs 


The PCE-initiated segment routing LSPs are those LSPs that the PCE creates for the adjacency and node 
segments 
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The PCE performs the following functions: 


1. Computes the path of the segment routing LSP. 


2. Provisions the LSP on the Path Computation Client (PCC) using PCEP segment routing extensions. 


3. Parses the PCEP segment routing extensions. 


4. Creates a tunnel route on the PCC that has its own preference value and is made available in the inet.3 
routing table to resolve IP traffic and services like any other tunnel route. 


The PCC performs the following functions: 


1. Selects the outgoing interface based on the first network access identifier (NAI) in the source Explicit 
Route Object (S-ERO). 


Junos OS supports S-EROs that contain the first hop as a strict hop; Junos OS doesn't support selection 
of the outgoing interface on the PCC based on a loose-hop node segment ID (SID). However, the 
remaining hops can be loose. No specific processing is done for the S-EROs that are beyond the first 
hop, other than to simply use the label for next-hop creation. 


2. Rejects the S-ERO if: 
e The S-ERO does not have labels in it. 


e The S-ERO carries more than six hops. 
The PCC creates an equal-cost multipath (ECMP) route when there are multiple LSPs to the same 


destination with the same metric. 


3. Waits for the PCE to process any event that leads to a change in the segment routing LSP after it is 
provisioned—for example, if the label is changed or withdrawn, or if one of the interfaces traversed by 
the LSP goes down. 

When the PCEP session goes down, the PCE-initiated segment routing LSP: 


1. Remains up for 300 seconds. 
2. Is deleted from the PCC after 300 seconds. 
For more details, see Internet drafts draft-ietf-pce-Isp-setup-type-03.txt (expires December 25, 2015), 


Conveying path setup type in PCEP messages; and draft-ietf-pce-segment-routing-06.txt (expires February 
10, 2016), PCEP Extensions for Segment Routing. 
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PCE-Delegated Segment Routing LSPs 


The PCE-delegated segment routing LSPs are those LSPs that the PCC configures locally and then delegates 
to a PCE controller. 


NOTE: 
Junos OS Release 20.1R1 supports: 


e PCE delegation capability only for noncolored segment routing LSPs with IPv4 destinations. 


e Delegation and reporting of only the first segment of a segment list to an external controller. 
Multiple segments are not supported for PCE delegation. 


The PCC can delegate a segment routing LSP to an external controller (the PCE) in the following ways: 


e Initial delegation—The local LSPs are yet to be configured on the PCC, and the delegation of the LSP 
happens at the time the LSP is configured. 


e Delegation of existing LSP—The local LSPs are configured on the PCC, and the delegation of the LSP 
happens after the source-routing path is configured. That is, the delegation capability is enabled on 
existing segment routing LSPs. 


After delegating a segment routing LSP, the PCE controls the delegated LSPs and can modify the LSP 
attributes for path computation. The LSP control reverts to the PCC when the PCEP session between the 
PCC and the PCE goes down. The PCE-delegated LSPs have an advantage over PCE-initiated LSPs in case 
the PCEP session goes down. In the case of PCE-initiated LSPs, when the PCEP session is down, the LSPs 
are deleted from the PCC. However, in the case of PCE-delegated LSPs, when the PCEP session goes 
down, the PCC takes back control of the delegated LSPs from the PCE. As a result, with PCE-delegated 
LSPs, we avert a situation where packets are silently discarded (also known as a traffic black-hole condition) 
when the session goes down. 


The following types of segment routing LSPs support the PCE-delegation capability: 


e Static LSPs—Statically configured source-routing paths that have the entire label stack statically 
configured. 


e Auto-translated LSPs—Statically configured source-routing paths that are automatically translated. 


e Computed LSPs—Statically configured source-routing paths that are computed with distributed 
Constrained Shortest Path First (CSPF). 


e Dynamic LSPs—Dynamically created tunnels triggered through the Dynamic Tunnel Module that have 
last-hop ERO resolution. 


Depending on the source of the segment routing LSP, you can configure the delegation capability on the 
PCC. To enable delegation of segment routing LSPs, include the Isp-external-controller pccd statement 
at the appropriate level under the [edit protocols source-packet-routing] hierarchy. 
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Table 33 on page 1435 shows a mapping of the LSP source to the corresponding configuration hierarchy 


level at which the delegation capability is enabled. 


NOTE: You must include the Isp-external-controller pccd statement at the [edit protocols 


source-packet-routing] and [edit protocols mpls] hierarchy levels before configuring the 


delegation capability on the PCC. 


Table 33: Mapping of Segment Routing LSP Source with Configuration Hierarchy 


Source of Segment Routing LSP 


e Auto-translated LSPs 
e Static LSPs 


Computed LSPs (distributed CSPF) 


Dynamic LSPs 


Configuration Hierarchy 


Primary segment list at [edit protocols source-packet-routing 
source-routing-path Isp-name primary path-name] 


Primary segment list of the source-routing path at: 


e [edit protocols source-packet-routing source-routing-path 
Isp-name primary path-name compute profile-name] 

e [edit protocols source-packet-routing source-routing-path 
Isp-name primary path-name] 


Primary segment list of the source-routing path template at: 


e [edit protocols source-packet-routing 
source-routing-path-template template-name primary 
primary-segment-list-name] 

e [edit protocols source-packet-routing 
source-routing-path-template template-name] 


You can view the control status of the SR-TE LSPs from the show spring-traffic-engineering command 


output. 


Table 34 on page 1436 displays the PCEP interaction when the Isp-external-controller statement is configured 


for a source-routing path. 


Table 34: PCEP Interaction LSP Delegation 


Isp-external-controller source-routing-path 
Configuration Hierarchy Delegation State 


Primary segment list of Initial delegation 
source-routing path 


1436 


PCEP Interaction Between PCC and PCE 


1. APCReport message is sent to the PCE for delegation. 
The PCReport contains only constraints and path details 
(such as ERO). 


2. PCE calculates the path for LSP and reports path to be 
in the down state. 


3. No route is programmed by the local LSP until the 
controller computes the ERO and notifies the result to 
the PCC through PCUpdate. 


The same behavior is seen when the routing protocol process 
(rpd) restarts or a Routing Engine switchover happens. 
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Table 34: PCEP Interaction LSP Delegation (continued) 


Isp-external-controller source-routing-path 


Configuration Hierarchy Delegation State PCEP Interaction Between PCC and PCE 

Primary segment list of Delegation of existing 1. APCReport is sent to the PCE for delegation. The 

source-routing path path PCReport contains only constraints and path details (such 
as ERO). 


2. Acorresponding primary segment is delegated to the 
PCE. 


3. PCE calculates the path for the LSP. 


4. The primary segment continues to contribute to the 
route as determined by the local configuration or 
computation until a PCUpdate is received from the PCE. 


e If Seamless BFD (S-BFD) is not configured for the 
primary segment, then there is no further update to 
the route and the LSP state is also not monitored and 
reported to the PCE. The LSP state at this point is 
reported as up or down depending on whether path 
computation had succeeded at that point. 


e If S-BFD is configured for the primary segment, then 
the state of the primary segment is tracked and 
reported to the PCE. If BFD detects the primary 
segment to be down, the corresponding primary path 
is removed from the route. The same route that was 
previously calculated is reprogrammed if that path is 
up now. 


5. Ifa PCUpdate message is received from the PCE, SR-TE 
uses the received parameter to set up the path for which 
the PCReport message was sent. The programmed path 
then includes only the segment list received from the 
PCE, and all the other segment lists that were previously 
programmed are removed. This reprogramming of the 
route happens in a make-before-break fashion. 


Primary segment of Delegation is not The segment list from the PCE (if available) is no longer used 
source-routing path configured or has been and the computation result from the local configuration is 
deleted. used. When the local result for the segment list is available, 


the corresponding segment list is used to program the route 
in a make-before-break fashion. 
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Table 34: PCEP Interaction LSP Delegation (continued) 


Isp-external-controller source-routing-path 


Configuration Hierarchy Delegation State PCEP Interaction Between PCC and PCE 
Segment list of Delegation is enabled Delegation functionality is triggered for the primary segment 
source-routing path after LSP is configured. list under the source-routing path. 
Segment list of Delegation is not Delegation functionality is removed from the primary 
source-routing path configured or has been segment list under the source-routing path. 

deleted. 
Primary segment list of Delegation is enabled e Under the source-routing path template—Delegation 
source-routing path after LSP is configured. functionality is triggered for the entire source-routing 
template path. 


Template configurations can be applied only to the 
Dynamic Tunnel Module. 


Under the primary path in the source-routing path 
template—Delegation functionality is triggered for that 
particular primary path according to the configuration. 


Primary segment list of Delegation is not Delegation functionality is removed from all the 
source-routing path configured or has been source-routing paths and primary paths that match the 
template deleted. template configuration. 


Segment Routing for PCEP Limitations and Unsupported Features 
The support of segment routing for PCEP does not add to the performance burden on the system. However, 


it has the following limitations: 


e An SR-TE LSP is not locally protected on the PCC. When the LSP is more than six hops, no service is 
provided on the LSP other than to carry plain IP traffic. 


Graceful Routing Engine switchover (GRES) and unified in-service software upgrade (unified ISSU) are 
not supported. 


e Nonstop active routing (NSR) is not supported. 


IPv6 is not supported. 


e PCE-delegated LSPs do not support the following: 


e Colored SR-TE LSPs 
e IPv6é LSPs 
e Secondary segment list of the source-routing path. Only one path of the segment list can be delegated. 


e Multisegment standard. Only the first segment of the segment list is delegated and reported to the 
controller. 
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Example: Configure Segment Routing for the Path Computation Element Protocol 


IN THIS SECTION 


Requirements | 1439 
Overview | 1439 
Configuration | 1441 


Verification | 1450 


This example shows how to configure segment routing or Source Packet Routing in Networking (SPRING) 
traffic-engineering (SR-TE) for the Path Computation Element Protocol (PCEP). In the configuration, we 
leverage the advantages of segment routing with the benefits of external path computing for efficient 
traffic engineering. 


Requirements 


This example uses the following hardware and software components: 


e Four MX Series 5G Universal Routing Platforms, where the ingress MX Series router is the Path 
Computation Client (PCC). 


e A TCP connection from the PCC to an external stateful Path Computation Element (PCE). 
e Junos OS Release 17.2 or later running on the PCC for the implementation of PCE-initiated LSPs. 


For PCE-delegation functionality, you must run Junos OS Release 20.1R1 or a later release. 
Before you begin: 


e Configure the device interfaces. 
e Configure MPLS. 


e Configure IS-IS. 


Overview 


The Junos OS implementation of segment routing for PCEP includes PCE-initiated and PCE-delegated 
SR-TE LSPs. 


e The implementation of PCE-initiated LSPs is introduced in Junos OS Release 17.2R1, where the 
traffic-engineering capabilities of segment routing are supported in PCEP sessions for LSPs initiated by 
a PCE. The PCE creates the LSPs for the adjacency and node segments. Tunnel routes are created in the 
inet.3 routing table of the PCC corresponding to the PCE-initiated SR-TE LSPs. 
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e The implementation of PCE-delegated LSPs is introduced in Junos OS Release 20.1R1, where the locally 
configured IPv4 noncolored segment routing LSPs on the PCC can be delegated to a PCE controller. 
The PCE then controls the LSP and can modify LSP attributes for path computation. 


The PCE-delegated LSPs have an advantage over PCE-initiated LSPs at the time the PCEP session goes 
down. In the case of PCE-initiated LSPs, when the PCEP session is down, the LSPs are deleted from the 
PCC. However, in the case of PCE-delegated LSPs, when the PCEP session goes down, the PCC takes 
back control of the delegated LSPs from the PCE. As a result, with PCE-delegated LSPs, we avert a situation 
where packets are silently discarded (also known as a traffic black-hole condition) when the PCEP session 
goes down. 


To enable segment routing for PCEP: 
For PCE-initiated segment routing LSPs: 


1. Enable external path computing for MPLS by including the Isp-external-controller statement at the 
[edit protocols mpls] hierarchy level. 


This configuration is required for PCEP with RSVP-TE extensions as well. You cannot disable PCEP 
with RSVP-TE when segment routing for PCEP is enabled. 


2. Enable external path computing for SR-TE by including the Isp-external-controller pccd statement at 
the [edit protocols spring-traffic-engineering] hierarchy level. 


3. Enable segment routing for the PCE by including the spring-capability statement at the [edit protocols 
pcep pce pce-name] hierarchy level. 


4. Optionally, configure the maximum SID depth for the PCE by including the max-sid-depth number 
statement at the [edit protocols pcep pce pce-name] hierarchy level. 


The maximum SID depth is the number of SIDs supported by a node or a link on a node. When not 
configured, a default maximum SID value of 5 is applied. 


5. Optionally, configure the preference value for segment routing by including the preference 
preference-value at the [edit protocol spring-te] hierarchy level. 


The preference value indicates the order in which a path is selected as the active path form among 
candidate paths, where a higher value has a higher preference. When not configured, a default preference 
value of 8 is applied. 


6. Optionally, configure segment routing logging for troubleshooting purpose by including the traceoptions 
statement at the [edit protocols spring-te] hierarchy level. 


For PCE-delegation of segment routing LSPs, in addition to the aforementioned steps, do the following: 


1. Define a segment list with label parameters. This creates a segment routing LSP locally on the PCC. 
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2. Enable delegation capability of the locally configured LSP on the PCC by including the 
Isp-external-controller pccd statement at any of the following hierarchies depending on the segment 
routing LSP source: 


For statically configured source-routing paths that are computed with distributed CSPF—[edit protocols 
source-packet-routing source-routing-path Isp-name primary path-name compute profile-name] and 
[edit protocols source-packet-routing source-routing-path Isp-name primary path-name] hierarchy 


levels. 


For statically configured source-routing paths that have the entire label stack statically configured 


and source-routing paths that are automatically translated—[edit protocols source-packet-routing 
source-routing-path Isp-name primary path-name] hierarchy level. 


For dynamically created tunnels triggered through the Dynamic Tunnel Module that have last-hop 


ERO resolution—[edit protocols source-packet-routing source-routing-path-template template-name 
primary primary-segment-list-name] and [edit protocols source-packet-routing 
source-routing-path-template template-name] hierarchy levels. 


Topology 

Figure 123 on page 1441 illustrates a sample network topology that has a PCEP session running between 
the PCE and the PCC (the ingress MX Series router). Routers R1, R2, and R3 are the other MX Series 
routers in the network. In this example, we configure segment routing for PCEP on the PCC. We also 
configure a static route on the PCC to Router R3 to verify the use of SR-TE tunnel routes when routing 
traffic for the static route. 


Figure 123: Segment Routing for PCEP 


PCE 
10.100.41.2/24 10.100.12.2/24 10.100.23.2/24 
ge-0/0/5 ge-0/1/2 ge-0/1/8 
ge-0/0/5 ge-0/1/2 ge-0/1/8 
PCC 10.100.41.1/24 Ri 10.100.12.1/24 R2 10.100.23.1/24 R3 
lo0=192.168.100.4/32 lo0=192.168.100.1/32 lo0=192.168.100.2/32 lo0=192.168.100.3/32  & 


Configuration 


CLI Quick Configuration 

To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 
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Although we present the configuration of all the devices (PCC and the three routers) in this section, the 
Step-by-Step procedure documents only the configuration of the PCC. 


PCC 


set interfaces ge-0/0/5 unit 0 family inet address 10.100.41.1/24 

set interfaces ge-0/0/5 unit 0 family iso 

set interfaces ge-0/0/5 unit 0 family mpls 

set interfaces loO unit O family inet address 192.168.100.4/32 primary 

set interfaces loO unit O family iso address 49.0011.0110.0000.0101.00 

set interfaces loO unit O family mpls 

set routing-options static route 100.1.1.1/32 next-hop 192.168.100.3 

set routing-options router-id 192.168.100.4 

set routing-options autonomous-system 64496 

set protocols rsvp interface fxp0.0 disable 

set protocols rsvp interface all 

set protocols mpls Isp-external-controller pccd 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols isis source-packet-routing srgb start-label 8300000 

set protocols isis source-packet-routing srgb index-range 4000 

set protocols isis source-packet-routing node-segment ipv4-index 101 

set protocols isis source-packet-routing node-segment ipv6-index 11 

set protocols isis level 1 disable 

set protocols isis level 2 wide-metrics-only 

set protocols isis interface all point-to-point 

set protocols isis interface all level 2 metric 10 

set protocols isis interface fxp0.0 disable 

set protocols isis interface lo0.0 passive 

set protocols source-packet-routing segment-list static_seg_list_1 hop1 label 800102 

set protocols source-packet-routing segment-list static_seg_list_1 hop2 label 800103 

set protocols source-packet-routing source-routing-path static_srte_Isp_1 to 192.168.100.3 

set protocols source-packet-routing source-routing-path static_srte_Isp_1 primary static_seg_list_1 
Isp-external-controller pccd 

set protocols spring-traffic-engineering Isp-external-controller pccd 

set protocols source-packet-routing source-routing-path static1 Isp-external-controller pccd 

set protocols pcep pce pce local-address 192.168.100.4 

set protocols pcep pce pcel destination-ipv4-address 10.102.180.232 

set protocols pcep pce pcel destination-port 4189 

set protocols pcep pce pcei pce-type active 

set protocols pcep pce pcel pce-type stateful 

set protocols pcep pce pce Isp-provisioning 

set protocols pcep pce pcel spring-capability 
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Router R1 


set interfaces ge-0/0/5 unit 0 family inet address 10.100.41.2/24 

set interfaces ge-0/0/5 unit 0 family iso 

set interfaces ge-0/0/5 unit 0 family mpls 

set interfaces ge-0/1/2 unit 0 family inet address 10.100.12.1/24 

set interfaces ge-0/1/2 unit 0 family iso 

set interfaces ge-0/1/2 unit 0 family mpls 

set interfaces loO unit O family inet address 192.168.100.1/32 primary 
set interfaces loO unit O family iso address 49.0011.0110.0000.0102.00 
set interfaces loO unit O family mpls 

set routing-options router-id 192.168.100.1 

set routing-options autonomous-system 64496 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols isis source-packet-routing srgb start-label 8300000 

set protocols isis source-packet-routing srgb index-range 4000 

set protocols isis source-packet-routing node-segment ipv4-index 102 
set protocols isis level 1 disable 

set protocols isis level 2 wide-metrics-only 

set protocols isis interface all point-to-point 

set protocols isis interface all level 2 metric 10 

set protocols isis interface fxp0.0 disable 

set protocols isis interface lo0.0 passive 


Router R2 


set interfaces ge-0/1/2 unit 0 family inet address 10.100.12.2/24 
set interfaces ge-0/1/2 unit 0 family iso 

set interfaces ge-0/1/2 unit 0 family mpls 

set interfaces ge-0/1/8 unit 0 family inet address 10.100.23.1/24 
set interfaces ge-0/1/8 unit 0 family iso 

set interfaces ge-0/1/8 unit 0 family mpls 

set interfaces loO unit O family inet address 192.168.100.2/32 
set interfaces loO unit O family iso address 49.0011.0110.0000.0105.00 
set interfaces loO unit O family mpls 

set routing-options router-id 192.168.100.2 

set routing-options autonomous-system 64496 
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set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols isis source-packet-routing srgb start-label 8300000 
set protocols isis source-packet-routing srgb index-range 4000 
set protocols isis source-packet-routing node-segment ipv4-index 105 
set protocols isis level 1 disable 

set protocols isis level 2 wide-metrics-only 

set protocols isis interface all point-to-point 

set protocols isis interface all level 2 metric 10 

set protocols isis interface all level 1 disable 

set protocols isis interface fxp0.0 disable 

set protocols isis interface lo0.0 passive 


Router R3 


set interfaces ge-0/1/8 unit 0 family inet address 10.100.23.2/24 

set interfaces ge-0/1/8 unit 0 family iso 

set interfaces ge-0/1/8 unit 0 family mpls 

set interfaces loO unit O family inet address 192.168.100.3/32 primary 
set interfaces loO unit O family iso address 49.0011.0110.0000.0103.00 
set interfaces loO unit O family mpls 

set routing-options static route 100.1.1.1/32 receive 

set routing-options router-id 192.168.100.3 

set routing-options autonomous-system 64496 

set protocols rsvp interface all 

set protocols rsvp interface fxp0.0 disable 

set protocols mpls interface all 

set protocols mpls interface fxp0.0 disable 

set protocols isis source-packet-routing srgb start-label 8300000 

set protocols isis source-packet-routing srgb index-range 4000 

set protocols isis source-packet-routing node-segment ipv4-index 103 
set protocols isis level 1 disable 

set protocols isis level 2 wide-metrics-only 

set protocols isis interface all point-to-point 

set protocols isis interface all level 2 metric 10 

set protocols isis interface fxp0.0 disable 

set protocols isis interface lo0.0 passive 
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Step-by-Step Procedure 


In this example, we configure only the PCC. 


The following steps require that you navigate various levels in the configuration hierarchy. For information 
about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure the PCC: 


1. Configure the interfaces of the PCC. 


[edit interfaces] 

user@PCC# set ge-0/0/5 unit O family inet address 10.100.41.1/24 
user@PCC# set ge-0/0/5 unit 0 family iso 

user@PCC# set ge-0/0/5 unit O family mpls 

user@PCC# set loO unit 0 family inet address 192.168.100.4/32 primary 
user@PCC# set loO unit 0 family iso address 49.0011.0110.0000.0101.00 
user@PCC# set loO unit 0 family mpls 


2. Configure the router ID and assign an autonomous system number for the PCC. 
[edit routing-options] 


user@PCC# set router-id 192.168.100.4 
user@PCC# set autonomous-system 64496 


3. Configure a static route from the PCC to Router R3. 


The static route is created for verification purpose only and does not affect the feature functionality. 


[edit routing-options] 
user@PCC# set static route 100.1.1.1/32 next-hop 192.168.100.3 


4. Configure RSVP on all the interfaces of the PCC, excluding the management interface. 


[edit protocols] 
user@PCC# set rsvp interface fxp0.0 disable 
user@PCC# set rsvp interface all 


5. Configure MPLS on all the interfaces of the PCC, excluding the management interface. 


[edit protocols] 
user@PCC# set mpls interface all 
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user@PCC# set mpls interface fxp0.0 disable 


6. Enable external path computing capability for MPLS. 


[edit protocols] 
user@PCC# set mpls Isp-external-controller pccd 


7. Configure IS-IS level 2 on all the interfaces of the PCC, excluding the management and loopback 


interfaces. 


[edit protocols] 

user@PCC# set isis level 1 disable 

user@PCCz# set isis level 2 wide-metrics-only 
user@PCCz# set isis interface all point-to-point 
user@PCC# set isis interface all level 2 metric 10 
user@PCCé# set isis interface fxp0.0 disable 
user@PCC# set isis interface lo0.0 passive 


8. Configure segment routing global block (SRGB) attributes for segment routing. 


[edit protocols] 

user@PCC+# set isis source-packet-routing srgb start-label 300000 
user@PCC+# set isis source-packet-routing srgb index-range 4000 
user@PCC# set isis source-packet-routing node-segment ipv4-index 101 
user@PCC# set isis source-packet-routing node-segment ipv6-index 11 


9. Enable external path computing capability for SR-TE. 


[edit protocols] 
user@PCC# set spring-traffic-engineering Isp-external-controller pccd 


10. Configure the PCE parameters and enable provisioning of the LSP by the PCE and the segment routing 
capability. 


[edit protocols] 

user@PCC# set pcep pce pce1 local-address 192.168.100.4 

user@PCC# set pcep pce pcel destination-ipv4-address 10.102.180.232 
user@PCC# set pcep pce pcei destination-port 4189 

user@PCC# set pcep pce pce1 pce-type active 


user@PCC# set pcep pce pce1 pce-type stateful 


11. Enable provisioning of segment routing LSPs by the PCE. 


[edit protocols] 
user@PCC# set pcep pce pce‘ Isp-provisioning 


12. Enable segment routing capability for the PCE. 


[edit protocols] 
user@PCC# set pcep pce pce1 spring-capability 


13. Define the static segment list static_seg_list_1 parameters. 


[edit protocols] 
user@PCC# set source-packet-routing segment-list static_seg_list_1 hop1 label 800102 
user@PCC# set source-packet-routing segment-list static_seg_list_1 hop2 label 800103 


14. Configure a static segment routing LSP from the PCC to Router R3 for PCE delegation. 


[edit protocols] 
user@PCC# set source-packet-routing source-routing-path static_srte_Isp_1 to 192.168.100.3 


15. Enable delegation capability for the static_srte_Isp_1 source-routing path. 


[edit protocols] 
user@PCC# set source-packet-routing source-routing-path static_srte_Ilsp_1 primary static_seg_list_1 
Isp-external-controller pccd 


By completing Steps 13, 14, and 15, you enable the PCC to delegate the segment routing LSPs to the 
PCE. 


16. Commit the configuration. 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show routing-options, 
and show protocols commands. If the output does not display the intended configuration, repeat the 
instructions in this example to correct the configuration. 
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user@PCC# show interfaces 
ge-0/0/5 { 
unit O { 
family inet { 
address 10.100.41.1/24; 

} 

family iso; 

family mpls; 


} 
lo0 { 
unit O { 
family inet { 
address 192.168.100.4/32 { 
primary; 


} 
family iso { 

address 49.0011.0110.0000.0101.00; 
} 


family mpls; 


user@PCC# show routing-options 
static { 
route 100.1.1.1/32 next-hop 192.168.100.3; 
} 
router-id 192.168.100.4; 
autonomous-system 64496; 


user@PCC# show protocols 
rsvp { 
interface fxp0.0 { 
disable; 
} 
interface all; 
} 
mpls { 
Isp-external-controller pccd; 
interface all; 
interface fxp0.0 { 
disable; 


1448 


} 
isis { 
source-packet-routing { 
srgb start-label 800000 index-range 4000; 
node-segment { 
ipv4-index 101; 
ipv6-index 11; 


} 

level 1 disable; 

level 2 wide-metrics-only; 

interface all { 
point-to-point; 
level 2 metric 10; 

} 

interface fxp0.0 { 
disable; 

} 

interface 100.0 { 


passive; 


} 
spring-traffic-engineering { 
Isp-external-controller pccd; 
} 
source-packet-routing { 
segment-list static_seg_list_1 { 
hop1 label 800102 
hop1 label 800102 
} 
source-routing-path static_srte_Isp_1 { 
to 192.168.100.3; 
primary { 
static_seg_list_1 { 
Isp-external-controller pccd; 


} 
pcep { 
pce pcel { 
local-address 192.168.100.4; 
destination-ipv4-address 10.102.180.232; 
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destination-port 4189; 
pce-type active stateful; 
Isp-provisioning; 
spring-capability; 


If you are done configuring the device (the PCC), enter commit from configuration mode. 


Verification 


IN THIS SECTION 


Verify IS-IS Adjacency and Labels | 1450 

Verify the Traffic Engineering Database | 1459 

Verify SR-TE LSPs | 1463 

Verify Tunnel Route Creation | 1466 

Verify Forwarding Table Entries | 1468 

Verify the Use of Tunnel Routes for Static Route Forwarding | 1470 


Confirm that the configuration is working properly. 


Verify IS-IS Adjacency and Labels 


Purpose 


Verify the IS-IS adjacency on the PCC. Take note of the SRGB label range, adjacency and node segment 
values, and SPRING capability output fields. 


Action 


From operational mode, run the show isis adjacency extensive, show isis database extensive, and show 


isis overview commands. 


user@PCC> show isis adjacency extensive 


R1 





Interface: ge-0/0/5.0, Level: 2, State: Up, Expires in 25 secs 


Pieroriieys 0, UWo/Dowd cxamenicaomss 1, Waste eieeasaicdoms OOsS7s15 age 


Circuit type: 2, Speaks: IP, IPv6 


Topologies: Unicast 


Restart capable: Yes, Adjacency advertisement: 


IP addresses: 10.100.41.2 
Level 2 IPv4 Adj-SID: 16 


WieeumSjabicalLein Ikeye;s 


When 


State 


Wed Apr 5 02:42:48 Up 


ICs; 








PieaOimaslieys Ol, 


Event 


Seenself 
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Advertise 


Down reason 


Interface: gre.0, Level: 2, State: Up, Expires in 25 secs 


Up/Down transitions: 1, Last transition: 00:27:00 ago 


Circuit type: 2, Speaks: IP, IPv6 


Topologies: 


Unicast 


Restart capable: Yes, Adjacency advertisement: Advertise 


IP addresses: 11.105.199.2 


Level 2 


WieeimMSaicsein Ikexe;s 


When 


State 


We Cleo nauuo MO) eno ci 0) Up 


user@PCC> show isis database extensive 


Event 


Seenself 


IS-IS level 1 link-state database: 


IS-IS level 2 link-state database: 


Down reason 


PCC.00-00 Sequence: Ox2a6, Checksum: Oxla4f, Lifetime: 1150 secs 


IPV4 Index: 


101 


Node Segment Blocks Advertised: 
Start Index : 0, Size : 4000, Label-Range: [ 800000, 803999 ] 
IS neighbor: R1.00 


Two-way fragment: R1.00-00, 
IS neighbor: PCE.00 


2 foreseen 
Wi? jorweitilss 2 
ID jorweeieissg 


Header: LSP 
Allocated 
Remaining 


Estimated 





192,168, 100,4/ 32 
1 LOL 102 .0/ 30 
11,105,199 0 / 30 


EDEN CCe 00> 00; sebenciehy: 


length: 1492 bytes, 


Two-way first 








243 bytes 


Cunves 10 
fragment: R1.00-00 
SinieLeg oy 77a 

Metric: 0 Internal Up 
eile: 10 Internal Up 
etric: 16777215 Internal Up 


Rowieeie IDS IO2. ete. LOW .4 


lifetime: 1150 secs, Level: 2, Interface: 0 


free bytes: 1084, Actual free bytes: 1249 


Aging timer expires in: 1150 


IPIEOICOCO ILS g 


We, IPAS 


secs 


Rackct ahora Dimr CCrOO OOF 


Checksum: Oxla4f, Sequen 


Length: 243 bytes, Lifetime 


1198 secs 


ce: Ox2a6, Attributes: 0x3 Ll L2 
NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes 


Packet type: 20, Packet version: 1, Max area: 0 


TLVs: 

Meee echicesses 29,0011 (3 

LSP Buffer Size: 1492 

Speaks: IP 

Speaks: IPV6 

iP meus alelg 192, 1's), 10 

IP gicicheasss 192. 6s), 00). 

IOGHEiavelmMNSs ICIS 

IS extended neighbor: Rl 
IP address: 10.100.41. 





) 


0.4 
4 


.00, Metric: default 10 
al 





Neighbor's IP address: 10.100.41.2 
Local interface index: 334, Remote interface index: 
Current reservable bandwidth: 

DieiomLey 10Mbps 

Digioesiey Al 10Mbps 

DigilOimliy 2 10Mbps 

Pieioriliiy 3 10Mbps 

Priority 4 10Mbps 

Veiorilicy 5 10Mbps 

Digioeaiey (6) 10Mbps 

Digiomley I ¢ ioMloyos 














Maximum reservable bandwidth: 10Mbps 


Maximum bandwidth: 10Mbps 


Administrative groups: 


0 none 


Pa wPwel Wel Sib = PilacgssOsx30 (ir s0, sO, Wei, bei, S380) , 


IS extended neighbor: PC 


LE Radcdre's's OS i8o9 
Neighbor's IP address: 
Local interface index: 


IP extended prefix: 11.1 


IP extended prefix: 11.105.199.0/30 metric 16777215 up 


IP extended prefix: 192. 
8 bytes of subtlvs 





vol 

Li 105,199 ,2 
329, Remot 
Ole OA Oy SOmmetrete Om uS 


interface index: 





168 1004/32 imeicicae O ws 


HOO, Weciees Clenceywile i677 7Ail'5 


33S 


Weight:0, Label: 16 


S138) 


INGOYeIS: (SD, bees Op (RSO ING I JP sO 180), WSO, Ing 0), Wibereys Sie (0), wellicvess sL(0)i. 


Router Capability: 





Router ID 192.168.100.4, Flags: 0x00 


SPRING Capability - Flags: OxcO(I:1,V:1), Range: 4000, SID-Label: 800000 
SPRING Algorithm - Algo: 0 


No queued transmissions 
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R1.00-00 Sequence: 0x297, Checksum: 0x1615, Lifetime: 839 secs 
IPV4 Index: 102 
Node Segment Blocks Advertised: 
Start Index 0, Size 4000, Label-Range: [ 800000, 803999 ] 
IS neighbor: PCC.00 Metric: 10 
Two-way fragment: PCC.00-00, Two-way first fragment: PCC.00-00 
IS neighbor: R2.00 Metric: 10 
Two-way fragment: R2.00-00, Two-way first fragment: R2.00-00 
WP prwearisxs 192,168, 100,1/52 Metric: 0 Internal Up 
WP jexesiei<s Li, 1OL, LOZ .0/ 30 Metric: 10 Internal Up 
iP jeeiis<g Lil, 102 .105.,0/30 Metric: 10 Internal Up 
Header: LSP ID: R1.00-00, Length: 302 bytes 
Allocated length: 302 bytes, Router ID: 192.168.100.1 
Remaining lifetime: 839 secs, Level: 2, Interface: 334 
Estimated free bytes: 0, Actual free bytes: 0 
Aging timer expires in: 839 secs 
Provocols: IP, [Py6 
Packet: LSP ID: R1.00-00, Length: 302 bytes, Lifetime 1196 secs 
Checksum: 0x1615, Sequence: 0x297, Attributes: 0x3 Ll L2 
NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes 
Packet type: 20, Packet version: 1, Max area: 0 
LiVSs 
Meee eckhleesse AY. OOil (Ss) 
LSP Buffer Size: 1492 
Speaks: IP 
Speaks: IPV6 
iP swowlecwe acle 192. Isis. 100. i 
12 accwesss 1925168. 100.1 
Hostname: R1 
IP extended prefix: 192.168.100.1/32 metric 0 up 
8 bytes of subtlvs 
INoxcle: (Siti), Wilegss Or“ CRS ONS, PSO pms, Ws, mg0), Aileo@sg Sie (@), Wadwes OL 
IP extended prefix: 11.101.102.0/30 metric 10 up 
IP extended prefix: 11.102.105.0/30 metric 10 up 
Router Capability: Router ID 192.168.100.1, Flags: 0x00 
SPRING Capability - Flags: Oxc0(1I:1,V:1), Range: 4000, SID-Label: 800000 
SPRING Algorithm — Algo: 0 
IS extended neighbor: R2.00, Metric: default 10 
me geeiessse 10,100,102. i 
Neighbor's IP address: 10.100.12.2 


Local in 


Current 


reservabl 





terface index: 334, Remote interface index: 


bandwidth: 





Picsrovaas 


Priori 
Priori 
Priori 


Dieal(oyie aL 





Priorit 


Priorit 


Priorit 





ey Gl Es Ge IS) tS és 


7 


10 
LO) 
10 
10 
10 
10 
LO) 
10 


bps 
pps 
bps 
pps 
bps 
pps 
bps 








bps 


Maximum reservable bandwidth: 10Mbps 


Maximum bandwidth: 10Mbps 


Administrative groups: 0 none 
Dae Weel Ach)—SiuD = PlagssWb230 (rs0,iscO,wsi,ingil,Ss®)) , 
IS extended neighbor: PCC.00, Metric: default 10 


IP address: 


110, LOO 4 62 


Neighbor's IP address: 10.100.41.1 


WoC aueena 


Current 


reservabl 


terface index: 333, Remote interface index: 





bandwidth: 





Priori 


Priori 


Pea Oye a. 


Priori 


Dieal(oyie aL 





Priori 


Priorit 


Pie @redete 


CY 





ay 


ny Onl (ES Go [Sy te eS 


7 


10 
10 
10 
10 
10 
ALY) 
LO) 
10 


pps 
pps 
pps 
bps 
bps 
bps 
bps 








pps 


Maximum reservable bandwidth: 10Mbps 


Maximum bandwidth: 10Mbps 


Administrative groups: 0 none 


Pa wPwel Ach =SilD = PilagssOx30 (irs, sO, Wei, bei, Se) , 


No queued transmissions 


R3.00-00 Sequence: 


IPV4 Index: 


Start Inde 
IS neighbor 


Two-way fragment: 


IP prefix: 
ID jorweizis<g 


0x95, Checksum: 0xd459, Lifetime: 895 
103 
Node Segment Blocks Advertised: 
x 0, Size : 4000, Label-Range: [ 800000, 
sR O10) Metric: 
R2.00-00, Two-way first fragment: 
192,168. LOO, 3/32 Metric: 
1 102.1 0/24 Metric: 
11,103,107 .0/ 30 Metric: 


WP jOweizilss 2 


Header: LSP 


DE 


R3.00-00, Length: 209 bytes 


33S 


Weight:0, Label: 17 


334 


Weight:0, Label: 16 


secs 


803999 | 
10 
R2.00-00 
Q Internal Up 
10 Internal Up 
10 Internal Up 


1454 


Allocated length: 


Remaining lifetime: 


Aging timer expires 





POC OColle sg Ie, 
iS Pa D ie Reo ra 010) 
Checksum: 0xd459, 
0x83, 


Packet: 
INEZ IED) 8 Fixed 

Packet type: 20, 

Ens 

49.00 

14 


Area address: 
LSP Buffer Size: 
a2 

IPV6 


Speaks: 
Speaks: 
iP wmepreer aelg i192. 1 
me? @iceleasse 192, 68 
Hostname: R3 

IS extended neighbo 


IP address: 10.10 


Neighbor's IP address: 


Local interface i 


Current reservabl 


284 bytes, 


Estimated free bytes: 


IPv6 


Sequence: 


Packet version: 


1455 


Roucer TU: 
2, 
Actual free bytes: 


192.168. 100.3 
Interface: 334 


HS 


895 secs, Level: 
US, 


in: 895 secs 


-00, Length: 209 bytes, 
0x95, Attributes: 
27 bytes, 


1, 


Lifetime 1192 secs 
Ok iki ib2 

1, 
0 


length: Version: Sysid length: 0 bytes 


Max area: 


dal 
Oe 


(3) 


68.100.3 
slOO. 3 


RZ) 5 OO), 
ORzere 


prone Meters et melo scam a0) 
LO, 100,23, 1 
336, Remot 


bandwidth: 


ndex: interface index: 334 








10 
LO) 
10 
10 
10 
10 
10 
10 


PiealOwalicw 
CY 
Cy 


Priorit 


Priori 


Priori 


Priori 


Priorit 


@y Gl Gs ty sy i & 


Pea yea 








Priority 7 


Maximum reservable bandwidth: 


Maximum bandwidth 

Administrative gr 

P2P IPV4 Adj-SID 
IP extended prefix: 


bps 
bps 
pps 
bps 
bps 
bps 
bps 








pps 

10Mbps 
: 10Mbps 

oups: 0 none 

= Piles 20x30 (sO e0, Weil, bei, Ss) , 


192 163,100, 35/ 52 imneicreske (0) wys 


Weight:0, Label: 16 


8 bytes of subtlvs 


Node SID, Flags: 
IP extended prefix: 
IP extended prefix: 
Router Capability: 
SPRING Capability 


SPRING Algorithm 





Os 4g ele epee oO yas Uy Value: 103 
1110S ,107 0/30 mecere 10 up 

1 1021 ,0/24 metrie i110) wis 

Ropicee 1D 192.168, 100.3, 


Oxe0 (IL3iL, Wail) , 


Algo SE EA(O)ry 


0x00 
4000, 


Flags: 


= plage: SID-Label: 800000 


0 


Range: 


- Algo: 


No queued t 





ransmissions 





1456 








R2.00-00 Sequence: Ox2aa, Checksum: Oxf8f4, Lifetime: 1067 secs 
IPV4 Index: 105 
Node Segment Blocks Advertised: 
Start Index O, Salwe 4000, Label-Range: [ 800000, 803999 ] 
IS neighbor: R1.00 Metric: 10 
Two-way fragment: R1.00-00, Two-way first fragment: R1.00-00 
IS neighbor: R3.00 Metric: 10 
Two-way fragment: R3.00-00, Two-way first fragment: R3.00-00 
WP jessie, 192,158, 100,.2/ 32 Metric: 0 Internal Up 
IP jeeeitiseg iil, 102. 105.,0/30 Metric: 10 Internal Up 
WP jesse: Lil, 103.107 .0/30 Metric: 10 Internal Up 
Header: LSP ID: R2.00-00, Length: 302 bytes 
Allocated length: 302 bytes, Router ID: 192.168.100.2 
Remaining lifetime: 1067 secs, Level: 2, Interface: 334 
Estimated free bytes: 0, Actual free bytes: 0 
Aging timer expires in: 1067 secs 
PEOLOCOVe* (fe, -Eev6 
Packet: LSP ID: R2.00-00, Length: 302 bytes, Lifetime 1194 secs 
Checksum: Oxf8f4, Sequence: Ox2aa, Attributes: 0x3 Ll L2 
NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes 
Packet type: 20, Packet version: 1, Max area: 0 
LiVsS: 
Mase eclcheesse 290011 (3) 
LSP Butter (Saze: 1492 
Speaks: IP 
Speaks: IPV6 
We wepicce ache 192,168. 100.2 
12 gebleesss 192 168, 10052 
Hostname: R2 
IP extended prefix: 192.168.100.2/32 metric 0 up 
8 bytes of subtlvs 
Necks: (Sid), Wilewese OnlO (CRS 0, INe PSO, 120), W30), Ing), Ailees Sie (@)), Wadlittess iOS 
IP extended prefix: 11.102.105.0/30 metric 10 up 
IP extended prefix: 11.103.107.0/30 metric 10 up 
Router Capability: Router ID 192.168.100.2, Flags: 0x00 
SPRING Capability - Flags: Oxc0(1I:1,V:1), Range: 4000, SID-Label: 800000 
SPRING Algorithm - Algo: 0 
IS extended neighbor: R3.00, Metric: default 10 


IP address: 10.100.23.1 


12) 


Neighbor's IP address: 10.100.23.2 


Local interface index: 334, Remote interface index: 336 





Current reservable bandwidth: 








Priority 0 : 10Mbps 
Pieiowslicy AL 10Mbps 
Piekomlioy 2 10Mbps 
Piew@oslicy so 3 Oilers 
Pigioidiry 4 10Mbps 
DigiLOieaiey 5) 10Mbps 
DiiomLey © 10Mbps 
ao) ab Ohya MO) Vo} oF) 








Maximum reservable bandwidth: 10Mbps 

Maximum bandwidth: 10Mbps 

Administrative groups: 0 none 

PAP wew4l Ach=SilD = PilagseWs0 (rsO, sO, weil, meil,SsO), meacinesO, 
IS extended neighbor: R1.00, Metric: default 10 

m2 gcelessse 10,100), 12.2 

Neighbor's IP address: 10.100.12.1 


Local interface index: 333, Remote interface index: 334 





Current reservable bandwidth: 














Digioerticwy (0) § ilOMloyoys 
DigioOieticy AL 10Mbps 
Pielomlicy 2 10Mbps 
Pieiowilicy s 3 il OMleyors 
Priority 4 10Mbps 
DigiOieaiey 5) 10Mbps 
DieiomLiey © 10Mbps 
Priority 7 : 10Mbps 


Maximum reservable bandwidth: 10Mbps 

Maximum bandwidth: 10Mbps 

Administrative groups: 0 none 

DAP IwPwel Ach =SilD = PilagseWbs0 (rs@, sO, weil, meil,SsO), meacinesO, 


No queued transmissions 





F.00-00 Sequence: 0x277, Checksum: 0x64a5, Lifetime: 533 secs 
lSmncAc n> Orme Ce010) Meiermdeg i677 721.5 
iP jeresitioes 1, O.0, 199/32 Metric: 0 Internal Up 
WP jorasieases Lit, 105,199, 0/30 Metric: 16777215 Internal Up 


Header: LSP ID: PCE.00-00, Length: 120 bytes 
Allocated length: 284 bytes, Router ID: 11.0.0.199 





Remaining lifetime: 533 secs, Level: 2, Interface: 329 





Estimated free bytes: 164, Actual free bytes: 164 


Aging timer expires in: 533 secs 


16 


17 


1457 


1458 


ProLocole: EP, IPy5 





Packet: LSP ID: PCE.00-00, Length: 120 bytes, Lifetime : 1196 secs 
Checksum: 0x64a5, Sequence: 0x277, Attributes: 0x3 Ll L2 
NLPID: 0x83, Fixed length: 27 bytes, Version: 1, Sysid length: 0 bytes 


Packet type: 20, Packet version: 1, Max area: 0 


TiVvs: 
Mase eiclehieesSs 11,0007 (Ss) 
LSP Buffer Size: 1492 
Speaks: IP 
Speaks: IPV6 
IP wewlcee ache 11,0.0,199 
1? access: 1,00, 199 
Hostname: PCI 
INeGmIEeIe Cajociowilieys iNewicsie ID IiL,O@,@.199, wlacss Oxo) 
iD Exacemuclael jorcisieaxs Ii LOS 199. 0/30 macrnie 167/725 wis 
IP extended prefix: 11.0.0.199/32 metric 0 up 
IS extended neighbor: PCC.00, Metric: default 16777215 
I? sceaesss Li, LOS. 199.2 
Neighbor's IP address: 11.105.199.1 





Le 


Local interface index: 329, Remote interface index: 329 





No queued transmissions 


user@PCcC> show isis overview 


Misizonle Craeinaicie cts 
ewiecie IDG IG)2). Gis}. LO), 4 
Hostname: PCC 
SijSeecl Ose R OOO Or OusOne 
Areaid: 49.0011 
Adjacency holddown: enabled 
Maximum Areas: 3 
LSP life time: 1200 
Attached bit evaluation: enabled 
SPF delay: 200 msec, SPF holddown: 5000 msec, SPF rapid runs: 3 
IPv4 is enabled, IPv6 is enabled, SPRING based MPLS is enabled 


Traffic engineering: enabled 





Restart: Disabled 





Helper mode: Enabled 
Layer2-map: Disabled 
Source Packet Routing (SPRING): Enabled 





SRGB Config Range: 


SRGB Start-Label : 800000, SRGB Index-Range : 4000 
SRGB Block Allocation: Success 

SRGB Start Index : 800000, SRGB Size : 4000, Label-Range: [ 800000, 803999 ] 
Node Segments: Enabled 


Ipv4 Index 
Level 1 
Internal rou 


External rou 





Prefix expor 
Wide metrics 
Source Packe 

Level 2 
Internal rou 


External rou 





Prefix expor 
Wide metrics 


Source Packe 


Meaning 





IMOVIE, ijenye) Atioveles< 3 ALAL 


te preference: 15 

te preference: 160 

5 Commies © 

are enabled, Narrow metrics are enabled 


t Routing is enabled 


te preference: 18 
te preference: 165 
£ coumes © 


are enabled 





t Routing is enabled 


The IS-IS adjacency between the PCC and PCE and that between the PCC and Router R1 are up and 
operational. The output also displays the label assignments for the adjacent and node segments. 


Verify the Traffic Engineering Database 


Purpose 


Verify the traffic engineering database entries on the PCC. 


Action 


From operational mod 


e, run the show ted database extensive command. 


user@PCC# show ted database extensive 


TED database: 5 
NodeID: PCC.00(1 





type: Ritr, Age 
PROECOCOLS LSI 
192 6 1G). LOO 4 
ict eRe OONGIES 
Local inte 
Color: wOmn 
Metric: 10 


IGP metric 


ISIS nodes 5 INET nodes 
92.168.100.4) 

& “0S Sees, Ibsliakwine i, iWainlktOwies iL 
S(2) 





ZAMS LOO), ocals LO,100 41,1, Remoces L0,100.41.,2 


rface index: 334, Remote interface index: 333 





one 


ea) 


1459 


1460 


Static BW: 10Mbps 

Reservable BW: 10Mbps 

Available BW [priority] bps: 
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps 
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps 

Interface Switching Capability Descriptor(1): 

Switching type: Packet 

Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps 
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps 
P2P Adjacency-SID: 
my, Sips 16, milage: Ox, Westelnes (0) 
Prefixes: 
OVA GH ILO) , 32 
Metric: 0, Flags: 0x00 
NESE a 5e—(S) 10D) g 
Siu Oil, wilacgss Ox40, Alee@s © 
SPRING-Capabilities: 
SRGB block [Start: 800000, Range: 4000, Flags: Oxc0] 
SPRING-Algorithms: 
Algo: 0 
NodeID: R1.00(192.168.100.1) 
Type: Rtr, Age: 712 secs, LinkIn: 2, LinkOut: 2 
Prococol: TSo-f5(2) 
192,168. LOO 5 i 
Hog BCC, O0 (192 168 100.4), Locals 10,100.42,.2, Remora: 10, 100.41.1 





Local interface index: 333, Remote interface index: 334 

Color: 0 none 

Metric: 10 

IGP metric: 10 

Static BW: 10Mbps 

Reservable BW: 10Mbps 

Available BW [priority] bps: 
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps 
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps 

Interface Switching Capability Descriptor(1): 

Switching type: Packet 

Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps 
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps 
P2P Adjacency-SID: 
A NV SID) Ko) chel l= Kee f= 0 )>-<6 10) nn (cate pole) 


To: R2200 (192 168. bOO 2), Locals 10,100.12. 1, Remote: 








Local interface index: 334, Remote interface index: 
Color: 0 none 
Metric: 10 
IGP metric: 10 
Static BW: 10Mbps 
Reservable BW: 10Mbps 
Available BW [priority] bps: 
[0] 10Mbps [1] 10Mbps [2] 10Mbps 
[4] 10Mbps [5] 10Mbps [6] 10Mbps 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 
aximum LSP BW [priority] bps: 
[0] 10Mbps [1] 10Mbps [2] 10Mbps 
[4] 10Mbps [5] 10Mbps [6] 10Mbps 
P2P Adjacency-SID: 
IPV4, SID: 17, Flags: 0x30, Weight: 0 
Prefixes: 
192,168,100. 1/32 
Metric: 0, Flags: 0x00 
use ae=1S) 1D) 8 
Sig OZ, Wilacss Oxe40, Ales O 
SPRING-Capabilities: 
SRGB block [Start: 800000, Range: 4000, Flags: Oxc0] 


SPRING-Algorithms: 
Algo: 0 
NodeID: R3.00(192.168.100.3) 
Type: Rtr, Age: 435 secs, LinkIn: 1, LinkOut: 1 
Prococol: TSo-iso (2) 
192,16. LOO. 3 


Toe 82 001192. oe. 100.2), bocale 10.100.25.2, Remote: 





Local interface index: 336, Remote interface index: 
Color: 0 none 
Meieietes IC 
IGP metric: 10 
Static BW: 10Mbps 
Reservable BW: 10Mbps 
Available BW [priority] bps: 
[0] 10Mbps [1] 10Mbps [2] 10Mbps 
[4] 10Mbps [5] 10Mbps [6] 10Mbps 


Interface Switching Capability Descriptor(1): 
Switching type: Packet 





Encoding type: Packet 


10,100,122 
S33 
[3] 10Mbps 
[7] 10Mbps 
[3] 10Mbps 
[7] 10Mbps 
LO0.LOW. 23.1 
334 
[3] 10Mbps 
[7] 10Mbps 


1461 


Maximum LSP BW [priority] bps: 
[0] 10Mbps [1] 10Mbps [2] 10Mbps 
[4] 10Mbps [5] 10Mbps [6] 10Mbps 
P2P Adjacency-SID: 
meWw4, Smps 16, Pillage: Ox30, Weacines 
Prefixes: 
LQ 168,100). 3/32 
Metric: 0, Flags: 0x00 
Prefix-SID: 
Sis los, Plage? O40, Al@ges @ 
SPRING-Capabilities: 


SRGB block [Start: 800000, Range: 4000, Flags: Oxc0] 


SPRING-Algorithms: 
MAC O)R (0) 
NodeID: R2.00(192.168.100.2) 
Type: Rtr, Age: 456 secs, LinkIn: 2, LinkOut: 2 
Provocoly To-is(2) 
192 -1G6e. LOW <2 


for RL OO (Loe bee. 00.1), Local: 10,100.12 .2, Remote: 


Local interface index: 333, Remote interface index: 





Color: 0 none 
Metric: 10 
IGP metric: 10 
Static BW: 10Mbps 
Reservable BW: 10Mbps 
Available BW [priority] bps: 
[0] 10Mbps [1] 10Mbps [2] 10Mbps 
[4] 10Mbps [5] 10Mbps [6] 10Mbps 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] 10Mbps [1] 10Mbps [2] 10Mbps 
[4] 10Mbps [5] 10Mbps [6] 10Mbps 
P2P Adjacency-SID: 
mew, Supe if, wilage: Oxs0, Weacines 


Tor RoUOO(Io2 168. 00 ls), Locals 10,100. 20.1, Remote: 


Local interface index: 334, Remote interface index: 





Colors 0 mone 

Metric: 10 

IGP metric: 10 

Static BW: 10Mbps 
Reservable BW: 10Mbps 
Available BW [priority] bps: 


[3] 10Mbps 

[7] 10Mbps 
10,100, 12. i 
334 

[3] 10Mbps 

[7] 10Mbps 

[3] 10Mbps 

[7] 10Mbps 
10,100 .23..2 
336 
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[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps 
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] 10Mbps [1] 10Mbps [2] 10Mbps [3] 10Mbps 
[4] 10Mbps [5] 10Mbps [6] 10Mbps [7] 10Mbps 
P2P Adjacency-SID: 
IPV4, SID: 16, Flags: 0x30, Weight: 0 
Prefixes: 
LY WG 100). 2/ 32 
Maceie:s O, Placse Ox) 
Prefix-SID: 
Sis OS, Places O40, Alees @ 
SPRING-Capabilities: 
SRGB block [Start: 800000, Range: 4000, Flags: Oxc0] 
SPRING-Algorithms: 
Algo: 0 
NodeID: PCE.00(11.0.0.199) 
Type: Rtr, Age: 267 secs, LinkIn: 0, LinkOut: 0 
Protocol: ise—iS(2) 
11.,0.0,199) 





Meaning 


The traffic engineering database includes entries advertised from Routers R1, R2, and R3, which the PCE 
uses for external path computing for the PCC. 


Verify SR-TE LSPs 


Purpose 
Verify the creation of SR-TE LSPs on the PCC. 


Action 


From operational mode, run the show path-computation-client Isp, show spring-traffic-engineering Isp 
detail, and show route protocol spring-te commands. 


user@PCC> show path-computation-client Isp 


Name Status PLSP-id LSP[iype 
Controller Path-Setup-Type Template 
avel5|_Sicl_ si (Up) 3 ext—provised 
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pcel spring-te 
node_sid_lsp (Up) 5 ext—provised 
pcel spring-te 


user@PCC> show spring-traffic-engineering Isp detail 


Name: adj_sid_lsp 

TOs 192.168, 100.3 

State: Up, Outgoing interface: ge-0/0/5.0 
Delegation info: 


Control-status: Externally controlled 





Routing-status: Externally routed 


SRI EROMMOpmCOMUniET mS 





ileye il (SibieiC%E)) ¢ 
IAI G IEP Wal WNclaeesiney 1D, IO, LOO .40l 1 =—S 10,100,412 
SID type: 20-bit label, Value: 16 

Blo 2 (SELIG) & 
IWAIS IPW4l MNcljaeemey ID, IO, LOO.12,1 —S IO, 100,112.27 
Sid) ieyioes 20-lowie lelosil, wells; iL7/ 

isloys. 3} (SIPIILCIE)) 8 
NAILS IP! chieceincy 1D, 10.100 25.1 => 10,100,232 
SID type: 20-bit label, Value: 16 





Name: node_sid_lsp 

TOs U2 USS. WOO, 3 

State: Up, Outgoing interface: ge-0/0/5.0 
Delegation info: 


Control-status: Externally controlled 





Routing-status: Externally routed 
SiR in Om ioOpmeolniten ES) 
ileye il (Sieber) § 
INAILG IP Wal ANclaeesiney 1D, IO, LOO 40,1 => 10,100,412 
SID type: 20-bit label, Value: 16 
Blo 2 (SirLUC)) & 
NAI: IPv4 Node ID, Node address: 192.168.100.1 
SID type: 20-bit label, Value: 800105 
isles) 3 (SIPISILCIE)) 5 
NAI: IPv4 Node ID, Node address: 192.168.100.2 
SID type: 20-bit label, Value: 800103 





Name: static_srte_lsp_1l 


Tunnel-source: Static configuration 


tog 192,163, 100.3 
State: Up 
DENeINe Sieaicswe: Sec. ilusie_il 
Outgoing interface: NA 
Delegation info: 
Control-status: Externally controlled 


Routing-status: Externally routed 





Auto-translate status: Disabled Auto-translate result: N/A 





BFD status: Up BFD name: V4-srte_bfd_session—4 
SRoEROmNOpEc ouimier mm 





Inyo I (Siewaleie)) = 
NA IPyl Achi@esmey ID, 13,1.1,.2 => 36,12.i16.1 
SID type: None 

nei 2 (Sitieeis)) s 
NAI: IPv4 Node ID, Node address: 192.168.100.3 
SID type: 20-bit label, Value: 804000 


so} of Wao bilt=3 on -hYA—1o Man TS) -t-S-G (LU) OES Pm DIO) S00 OD) 


user@PCC> show route protocol spring-te 


inet.0: 17 destinations, 17 routes (17 active, 0 holddown, O hidden) 


inet.3: 3 destinations, 4 routes (3 active, 0 holddown, O hidden) 





+ = Active Route, Last Active, * = Both 





192, 16S, LOO) 3/32 * [SPRING-TE/8] 00:23:32, metric 0 
CO IO 100 41.2 waa Ge-O/0/S5.0, PUSin 16, Busia 7 (ices) 
Sco MO, 100.41.2 wile Ge-O/0/S.0, Puisila SOOLOA, Busia SOMOS (eejs)) 





iso.0: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 
mpls.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden) 


inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 


Meaning 


The outputs show that two SR-TE LSPs—adj_sid_Isp and node_sid_Isp—have been created by the PCE for 
the adjacency and node segments, respectively. 


The segment routing LSP, static_srte_Isp_1, is enabled with the delegation capability. The Delegation info 
field shows the control and routing status of PCE-delegated LSPs. Externally controlled signifies that the 
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PCE has control over the LSPs. Externally routed signifies that the PCE has provided the ERO for the 
source-routing path. 


Verify Tunnel Route Creation 


Purpose 
Verify the tunnel routes created for the SR-TE LSPs that are included in the inet.3 routing table on the 
PCC. 


Action 
From operation mode, run the show route table inet.3 extensive command. 


user@PCC> show route table inet.3 extensive 


inet.3: 3 destinations, 4 routes (3 active, 0 holddown, O hidden) 
192.168.100.1/32 (1 entry, 1 announced) 

*L-ISIS Preference: 14 
Level: 2 
Next hop type: Router, Next hop index: 581 
Address: 0xb7a23b0 
Next-hop reference count: 13 
Next hop: 10.100.41.2 via ge-0/0/5.0, selected 
Session Id: 0x172 











State: Active Int 

Local AS: 64496 

Age: 45:51 Metric: 10 

Validation State: unverified 

ORR Generation-ID: 0 

Tasike IS=1LS 

Announcement bits (2): O-Resolve tr 1 2-Resolve tr 3 
AS path: I 





UGA 5 G3. LOO S/ 32 (2 itewaes, i siounveyoiarecyel)) 
*SPRING-TE Preference: 8 








Next hop type: Router, Next hop index: 0 
Address: 0xb61c190 

Next-hop reference count: 7 

Next hop: 10.100.41.2 via ge-0/0/5.0 weight Ox1 
Label operation: Push 16, Push 17 (top) 





LGIQS IL WEL QCEULOMS JORG SEL, joo cic ll (ite) 
Load balance label: Label 16: None; Label 17: None; 
Label element ptr: Oxb7a2a60 


Label parent element ptr: 0x0 





Label element references: 5 

















Label element child references: 0 


ISIS) 


192,168,100 .2/ 32 


Label element lsp id: 0 


Session Id: 0x0 
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None; 


























Next hop: 10.100.41.2 via ge-0/0/5.0 weight 0x1, selected 
Label operation: Push 800103, Push 800105 (top) 
Laloeil WWI BGELOME jorwCe-icicll, jorcm—icicll (ito) 

Load balance label: Label 800103: None; Label 800105: 
Label element ptr: Oxb7a2c40 

Label parent element ptr: 0x0 

Label element references: 2 

Label element child references: 0 

Label element lsp id: 0 

Session Id: 0x0 

State: Active Int 

TO Cauley AS): 64496 

Age: 9:44 Metric: 0 

Validation State: unverified 

Task: SPRING-TE 

Announcement bits (2): O-Resolve tr 1 2-Resolve tr 
AS path: I 

Preference: 14 

Level: 2 

Next hop type: Router, Next hop index: 0 
Address: Oxb7a28f0 

Next-hop reference count: 1 

Next hop: 10.100.41.2 via ge-0/0/5.0, selected 
Label operation: Push 800103 

Label TTL action: prop-ttl 

Load balance label: Label 800103: None; 

Label element ptr: 0xb7a2880 

Label parent element ptr: 0x0 

Label element references: 1 

Label element child references: 0 

Label element lsp id: 0 

Session Id: 0x0 


Staves init 


Inactive reason: Route Preference 


ILyoxeeull NSS 64496 
Age: 45:40 Metric: 30 
Validation State: unverified 


ORR Generation-ID: 0 
Tagieg ISIS) 
MS jowiclos I 


(1 entry, 1 announced) 


P= IES ICS} 
Level: 2 

Next hop type 
Address: 


Preference: 14 


: Router, Next hop index: 0 


Oxb7a29b0 





Next 


Next hop: 10. 
Label 
Label TTL act 
Load balance 
Label element 


Label 


hop referenc 


operation: 


coumies I 

100.41.2 via ge-0/0/5.0, selected 
Push 800105 
Prope eel 

Label 800105: 
Oxb7a2940 


0x0 


alia S 
label: None; 


Le 





parent 
Label 


lement ptr: 


references: 1 





Listen Su que. 


Label element 














Label element 
Session Id: 0 
Siedieer 
Local AS: 


Age: 45:40 


Validation State: 


child references: 0 
ES OMe clic) 
x0 


Active Int 


64496 
Meierste cme) 


unverified 


ORR Generation-ID: 0 


tasks ISLS 
Announcement 


AMS joecls I 


Meaning 


Tunnel routes have been created for the PCE-controlled LSP destination with SR-TE as the protocol label. 


Verify Forwarding Table Entries 


Purpose 
Verify that the SR-TE LSP destination 


Action 


From operation mode, run the show route forwarding-table destination ip-address extensive command. 


user@PCC> show route forwarding- 


Routing table: default.inet 


Internet: 





Enabled protocols: Bridging, 


Destination: 192.168.100.3/32 


Route type: user 





bits (2): O-Resolve tr ee Res olaicmas 3 


to Router R3 is installed in the forwarding table of the PCC. 


table destination 192.168.100.3 extensive 


[Index 0] 
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Route reference: 0 
Multicast RPF nh index: 
P2mpidx: 0 





Nexthop: 10.100.41.2 





Internet: 





Destination: default 











index: 0 





Route interfac 


0 


Flags: sent to PFE, rt nh decoupled 





Next—-hop type: unicast Index: 581 
Next-hop interface: ge-0/0/5.0 
Routing table: __pfe_private__.inet [Index 3] 


Enabled protocols: Bridging, 


Reference: 


index: 0 








Internet: 





Destination: default 











Internet: 





Destination: default 


Routes typ 





permanent 
Route reference: 0 
Multicast RPF nh index: 


P2mpidx: 0 





Flags: sent to PFE 





Next—-hop type: reject 


Routes typ permanent 

Route reference: 0 Route interfac 

Multicast RPF nh index: 0 

P2mpidx: 0 

Flags: sent to PFE 

Next-hop type: discard Index: 517 
Routing table: __juniper_services__.inet [Index 5] 


Enabled protocols: Bridging, 


Reference: 


index: 0 





Route typ permanent 

Route reference: 0 Route interfac 

Multicast RPF nh index: 0 

P2mpidx: 0 

Flags: sent to PFE 

Next—-hop type: discard Index: 530 
Routing table: __master.anon__.inet [Index 6] 


Enabled protocols: Bridging, Dual VLAN, 


Reference: 


index: 0 





Route interfac 
0 


Index: 545 


Reference: 


14 
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Meaning 
The SR-TE LSP destination IP address to Router R3 is installed as a forwarding entry. 


Verify the Use of Tunnel Routes for Static Route Forwarding 


Purpose 
Verify that the static route is taking the tunnel route created for the SR-TE LSPs. 


Action 


From operational mode, run the show route ip-address and show route forwarding-table destination 
ip-address commands. 


user@PCc> show route 100.1.1.1 


inet.0: 17 destinations, 17 routes (17 active, 0 holddown, O hidden) 
+ = Active Route, Last Active, * = Both 








100, 1,1,1/ 32 =[Siceiele/S]| OWsss3cso, mrecie2 0) 
> CO 10,100 41,2 wie ge-0/0/5.0, Pusin 16, Busia 17 (cei) 
icO IM 100 41.2 wie Ge-O/0/5.0, Pusin SOOLOS, Pusia SOOILOS Gees) 


user@PCC> show route forwarding-table destination 100.1.1.1 


Routing table: default.inet 
Invernet: 


Enabled protocols: Bridging, 





Destination Type RtRef Next hop Type Index NhRef Netif 
1O@,.1.1.1/32 user 0 indr 1048575 2 
LO 00 4 Roisin 1s, Busia 7 (ice) 50 


2 ge-0/0/5.0 


Routing table: __pfe_private__.inet 
Internet: 


Enabled protocols: Bridging, 








Destination Type RtRef Next hop Type Index NhRef Netif 
default perm 0 dscd Bly Dp 
Routing table: __juniper_services__.inet 

INCernels 


Enabled protocols: Bridging, 





Destination Type RtRef Next hop Type Index NhRef Netif 
default perm 0 dscd 530 Ds 
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Routing table: __master.anon__.inet 
Internet: 


Enabled protocols: Bridging, Dual VLAN, 





Destination Type RtRef Next hop Type Index NhRef Netif 
default perm 0 ie Cie 545 il 
Meaning 


The outputs show that the static route to Router R3 uses the tunnel route created for the SR-TE LSP. 


Static Segment Routing Label Switched Path 


IN THIS SECTION 


@ Understanding Static Segment Routing LSP in MPLS Networks | 1471 
@ Example: Configuring Static Segment Routing Label Switched Path | 1497 


The segment routing architecture enables the ingress devices in a core network to steer traffic through 
explicit paths. You can configure these paths using segment lists to define the paths that the incoming 
traffic should take. The incoming traffic may be labeled or IP traffic, causing the forwarding operation at 
the ingress device to be either a label swap, or a destination-based lookup. 


Understanding Static Segment Routing LSP in MPLS Networks 


IN THIS SECTION 


Introduction to Segment Routing LSPs | 1472 
Benefits of using Segment Routing LSPs | 1473 
Colored Static Segment Routing LSP | 1473 
Non-Colored Static Segment Routing LSP | 1474 
Static Segment Routing LSP Provisioning | 1481 
Static Segment Routing LSP Limitations | 1481 
Dynamic Creation of Segment Routing LSPs | 1482 
Color-Based Mapping of VPN Services | 1488 


Tunnel Templates for PCE-Initiated Segment Routing LSPs | 1496 


Source packet routing or segment routing is a control-plane architecture that enables an ingress router to 
steer a packet through a specific set of nodes and links in the network without relying on the intermediate 
nodes in the network to determine the actual path it should take. 


Introduction to Segment Routing LSPs 


Segment routing leverages the source routing paradigm. A device steers a packet through an ordered list 
of instructions, called segments. A segment can represent any instruction, topological or service-based. A 
segment can have a local semantic to a segment routing node or to a global node within a segment routing 
domain. Segment routing enforces a flow through any topological path and service chain while maintaining 
per-flow state only at the ingress device to the segment routing domain. Segment routing can be directly 
applied to the MPLS architecture with no change on the forwarding plane. A segment is encoded as an 
MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the 
top of the stack. Upon completion of a segment, the related label is popped from the stack. 


Segment routing LSPs can either be dynamic or static in nature. 


Dynamic segment routing LSPs—When a segment routing LSP is created either by an external controller and downloaded 
to an ingress device through Path Computation Element Protocol (PCEP) extensions, or from a BGP segment routing 
policy through BGP segment routing extensions, the LSP is dynamically provisioned. The segment list of the dynamic 
segment routing LSP is contained in the PCEP Explicit Route Object (ERO), or the BGP segment routing policy of the 
LSP. 
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Static segment routing LSPs—When a segment routing LSP is created on the ingress device through local configuration, 
the LSP is statically provisioned. 


A static segment routing LSP can further be classified as colored and non-colored LSPs based on the configuration of 
the color statement at the [edit protocols source-packet-routing source-routing-path Isp-name] hierarchy level. 


For example: 


[edit protocols] 
source-packet-routing { 
source-routing-path Isp_name { 
to destination_address; 
color color_value; 
binding-sid binding-label; 
primary segment_list_1_name weight weight; 


primary segment_list_n_name weight weight; 
secondary segment_list_n_name; 
sr-preference sr_preference_value; 


} 


Here, each primary and secondary statement refers to a segment list. 


[edit protocols] 
source-packet-routing { 
segment-list segment_list_name { 
hop_1_name label sid_label; 


hop_n_name label sid_label; 


Benefits of using Segment Routing LSPs 


e Static segment routing does not rely on per LSP forwarding state on transit routers. Hence, removing 
the need of provisioning and maintaining per LSP forwarding state in the core. 


e Provide higher scalability to MPLS networks. 


Colored Static Segment Routing LSP 


IN THIS SECTION 


@ Understanding Colored Static Segment Routing LSPs | 1474 
@ Segment List of Colored Segment Routing LSPs | 1474 


A static segment routing LSP configured with the color statement is called a colored LSP. 


Understanding Colored Static Segment Routing LSPs 


Similar to a BGP segment routing policy, the ingress route of the colored LSP is installed in the inetcolor.O 
or inet6color.0 routing tables, with destincation-ip-address, color as key for mapping IP traffic. 


A static colored segment routing LSP may have a binding SID, for which a route is installed in the mpls.O 
routing table. This binding SID label is used to map labeled traffic to the segment routing LSP. The gateways 
of the route are derived from the segment list configurations under the primary and secondary paths. 


Segment List of Colored Segment Routing LSPs 


The colored static segment routing LSPs already provde support for first hop label mode of resolving an 
LSP. However, first hop IP mode is not supported for colored segment routing LSPs. Starting in Junos OS 
Release 19.1R1, a commit check feature is introduced to ensure that all the segment lists contributing to 
the colored routes have the minimum label present for all hops. If this requirement is not met, the commit 
is blocked. 


Non-Colored Static Segment Routing LSP 


IN THIS SECTION 


@ Understanding Non-Colored Segment Routing LSPs | 1474 
@ Segment List of Non-Colored Segment Routing LSPs | 1475 


A static segment routing LSP that is configured without the color statement is a non-colored LSP. Similar 
to PCEP segment routing tunnels, the ingress route is installed in the inet.3 or inet6.3 routing tables. 


Junos OS supports non-colored static segment routing LSPs on ingress routers. You can provision 
non-colored static segment routing LSP by configuring one source routed path and one or more segment 
lists. These segment lists can be used by multiple non-colored segment routing LSPs. 


Understanding Non-Colored Segment Routing LSPs 


The non-colored segment routing LSP has a unique name and a destination IP address. An ingress route 
to the destination is installed in the inet.3 routing table with a default preference of 8 and a metric of 1. 
This route allows non-colored services to be mapped to the segment routing LSP pertaining to the 
destination. In case the non-colored segment routing LSP does not require an ingress route then the ingress 
route can be disabled. A non-colored segment routing LSP uses binding SID label to achieve segment 
routing LSP stitching. This label that can be used to model the segment routing LSP as a segment that may 
be further used to construct other segment routing LSPs in a hierarchical manner. The transit of the binding 
SID label, by default, has a preference of 8 and a metric of 1. 


Starting in Junos OS Release 18.2R1, statically configured non-colored segment routing LSPs on the ingress 
device are reported to the Path Computation Element (PCE) through a Path Computation Element Protocol 
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(PCEP) session. These non-colored segment routing LSPs may have binding service identifier (SID) labels 
associated with them. With this feature, the PCE can use this binding SID label in the label stack to provision 
PCE-initiated segment routing LSP paths. 


Anon-colored segment routing LSP can have a maximum of 8 primary paths. If there are multiple operational 
primary paths then the packet forwarding engine (PFE) distributes traffic over the paths based on the load 
balancing factors like the weight configured on the path. This is equal cost multi path (ECMP) if none of 
the paths have a weight configured on them or weighted ECMP if at least one of the paths has a non-zero 
weight configured on the paths. In both the cases, when one or some of the paths fail, the PFE rebalances 
the traffic over the remaining paths that automatically leads to achieving path protection. A non-colored 
segment routing LSP can have a secondary path for dedicated path protection. Upon failure of a primary 
path, the PFE rebalances the traffic to the remaining functional primary paths. Otherwise, the PFE switches 
the traffic to the backup path, hence achieving path protection. A non-colored segment routing LSP may 
specify a metric at [edit protocols source-packet-routing source-routing-path Isp-name] for its ingress 
and binding-SID routes. Multiple non-colored segment routing LSPs have the same destination address 
that contribute to the next hop of the ingress route. 


Multiple non-colored segment routing LSPs have the same destination address that contribute to the next 
hop of the ingress route. Each path ,either primary or secondary, of each segment routing LSP is considered 
as a gateway candidate, if the path is functional and the segment routing LSP has the best preference of 
all these segment routing LSPs. However, the maximum number of gateways that the next-hop can hold 
cannot exceed the RPD multi-path limit, which is 128 by default. Extra paths are pruned, firstly secondary 
paths and then primary paths. A given segment list may be referred multiple times as primary or secondary 
paths by these segment routing LSPs. In this case, there are multiple gateways, each having a unique 
segment routing LSP tunnel ID. These gateways are distinct, although they have identical outgoing label 
stack and interface. A non-colored segment routing LSP and a colored segment routing LSP may also have 
the same destination address. However, they correspond to different destination addresses for ingress 
routes, as the colored segment routing LSP’s destination address is constructed with both its destination 
address and color. 


NOTE: Inthe case where a static non-colored segment routing LSP and a PCEP-created segment 
routing LSP co-exist and have the same to address that contributes to the same ingress route, 
if they also have the same preference. Otherwise, the segment routing LSP with the best 
preference is installed for the route. 


Segment List of Non-Colored Segment Routing LSPs 


Asegment list consists of a list of hops. These hops are based on the SID label or an IP address. The number 
of SID labels in the segment list should not exceed the maximum segment list limit. You can configure the 
maximum segment list limit at the [edit protocols source-packet-routing] hierarchy level. 


Prior to Junos OS Release 19.1R1, for a non-colored static segment routing LSP to be usable, the first hop 
of the segment list had to be an IP address of an outgoing interface and the second to nth hops could be 
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SID labels. Starting in Junos OS Release 19.1R1, this requirement does not apply, as the first hop of the 
non-colored static LSPs now provides support for SID labels, in addition to IP addresses. With the first 
hop label support, MPLS fast reroute (FRR) and weighted equal-cost multipath is enabled for resolving the 
static non-colored segment routing LSPs, similar to colored static LSPs. 


For the first-hop label mode to take effect, you must include the inherit-label-nexthops statement globally 
or individually for a segment list, and the first hop of the segment list must include both IP address and 
label. If the first hop includes only IP address, the inherit-label-nexthops statement does not have any 
effect. 


You can configure inherit-label-nexthops at any one of the following hierarchies. The inherit-label-nexthops 
statement takes effect only if the segment list first hop includes both IP address and label. 


e Segment list level—At the [edit protocols source-packet-routing segment-list segment-list-name] hierarchy 
level. 


e Globally—At the [edit protocols source-packet-routing] hierarchy level. 


When the inherit-label-nexthops statement is configured globally, it takes precedence over the segment-list 
level configuration, and the inherit-label-nexthops configuration is applied to all the segment lists. When 
the inherit-label-nexthops statement is not configured globally, only segment lists with both labels and IP 
address present in the first hop, and configured with inherit-label-nexthops statement are resolved using 
SID labels. 


For dynamic non-colored static LSPs, that is the PCEP-driven segment routing LSPs, the 
inherit-label-nexthops statement must be enabled globally, as the segment-level configuration is not 
applied. 


Table 22 on page 715 describes the mode of segment routing LSP resolution based on the first hop 
specification. 


Table 35: Non-Colored Static LSP Resolution Based on First Hop Specification 


First Hop Specification Mode of LSP Resolution 

IP address only The segment list is resolved using the IP 
address. 

For example: 


segment-list path-1 { 
hop-1 ip-address 172.0.12.2; 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 
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Table 35: Non-Colored Static LSP Resolution Based on First Hop Specification (continued) 


First Hop Specification 


SID only 
For example: 


segment-list path-2 { 
hop-1 label 1000011; 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 


IP address and SID (without the inherit-label-nexthops configuration) 


For example: 


segment-list path-3 { 
hop1 { 
label 801006; 
ip-address 172.24.1.2; 
} 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 


IP address and SID (with the inherit-label-nexthops configuration) 


For example: 


segment-list path-3 { 
inherit-label-nexthops; 
hop1 { 
label 801006; 
ip-address 172.24.1.2; 
} 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 


Mode of LSP Resolution 


The segment list is resolved using SID 
labels. 


By default, the segment list is resolved 
using IP address. 


The segment list is resolved using SID 
labels. 


You can use the show route ip-address protocol spring-te active-path table inet.3 command to view the 
non-colored segment routing traffic-engineered LSPs having multiple segment lists installed in the inet.3 


routing table. 
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For example: 


user@host> show route 7.7.7.7 protocol spring-te active-path table inet.3 


inet.3: 42 destinations, 59 routes (41 active, 0 holddown, 1 hidden) 


( 
+ = Active Route, Last Active, * = Both 











Tota Ve Vs B2 *[SPRING-TE/8] 00:01:25, metric 1, metric? 0 
S tO lil ,l.1.2 wila St-0/0/0.1, Pusin SOL007 
EtG 251,12 waa St-0/O/2.1, Pusin SOLOOT 
Corl lO2Z elevate 0/0/02, bush cO 00m Push sO L0OZiGe@p 


EO© 21,202 ,1.28 via st-0/0/2.2, Pusin SOL007, Pusin SOLOS (cop 


© Li, 1OS.1.2 wie st-O/0/0.,3, Pusin BOLOO7, Pusin SOLOOS (eco 





EO® Zi 20S 1.2 wie st-O/O0/2,3, Pusin SOLOO7, Pusin SOLOW (eco 


to 11.104.1.2 via et-0/0/0.4, Push 801007, Push 801003, Push 


801002 (top) 
to 21.204.1.2 via et-0/0/2.4, Push 801007, Push 801006, Push 


801005 (top) 
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NOTE: 


The first hop type of segment lists of a static segment routing LSP can cause a commit to fail, if: 


e Different segment lists of a tunnel have different first hop resolution types. This is applicable 
to both colored and non-colored static segment routing LSPs. However, this does not apply 
for PCEP-driven LSPs; a system log message is generated for the mismatch in the first hop 
resolution type at the time of computing the path. 


For example: 


segment-list path-1 { 


} 


hop-1 ip-address 172.0.12.2; 


hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 


segment-list path-2 { 


} 


hop-1 label 1000011; 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 


source-routing-path Isp1 { 


The commit of tunnel Isp1 fails, as path-1 is of IP addressmode and path-2 is of label mode. 


e The binding SID is enabled for the static non-colored LSP whose segment list type is SID label. 


to 172.10.10.1; 

primary { 
path-1; 
path-2; 


For example: 


segment-list path-3 { 


} 


hop-1 label 1000011; 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 


source-routing-path Isp1 { 
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to 172.10.10.1; 

binding-sid 333; 

primary { 
path-3; 


Configuring binding SID over label segment list is supported only for colored static LSPs and 
not for no-colored static LSPs. 


Static Segment Routing LSP Provisioning 


Segment provisioning is performed on per-router basis. For a given segment on a router, a unique service 
identifier (SID) label is allocated from a desired label pool which may be from the dynamic label pool for 
an adjacency SID label or from the segment routing global block (SRGB) for a prefix SID or node SID. The 
adjacency SID label can be dynamically allocated, which is the default behavior, or be allocated from a 
local static label pool (SRLB). A route for the SID label is then installed in the mpls.0O table. 


Junos OS allows static segment routing LSPs by configuring the segment statement at the [edit protocols 
mpls static-label-switched-path static-label-switched-path] hierarchy level. A static segment LSP is identified 
by a unique SID label that falls under Junos OS static label pool. You can configure the Junos OS static 
label pool by configuring the static-label-range static-label-range statement at the [edit protocols mpls 
label-range] hierarchy level. 


Static Segment Routing LSP Limitations 


e Junos OS currently has a limitation that the next hop cannot be built to push more than the maximum 
segment list depth labels. So, a segment list with more than the maximum SID labels (excluding the SID 
label of the first hop which is used to resolve forwarding next-hop) is not usable for colored or non-colored 
segment routing LSPs. Also, the actual number allowed for a given segment routing LSP may be even 
lower than the maximum limit, if an MPLS service is on the segment routing LSP or the segment routing 
LSP is ona link or a node protection path. In all cases, the total number of service labels, SID labels, and 
link or node protection labels must not exceed the maximum segment list depth. You can configure the 
maximum segment list limit at [edit protocols source-packet-routing] hierarchy level. Multiple non-colored 
segment routing LSPs with less than or equal to the maximum SID labels can be stitched together to 
construct a longer segment routing LSP. This is called segment routing LSP stitching. It can be achieved 
using binding-SID label. 


e The segment routing LSP stitching is actually performed at path level. If a non-colored segment routing 
LSP has multiple paths that is multiple segment lists, each path can be independently stitched to another 
non-colored segment routing LSP at a stitching point. A non-colored segment routing LSP which is 
dedicated to stitching may disable ingress route installation by configuring no-ingress statement at [edit 
protocols source-packet-routing source-routing-path Isp-name] hierarchy level. 
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e A maximum of 8 primary paths and 1 secondary path are supported per non-colored static segment 
routing LSP. If there is a violation in configuration, commit check fails with an error. 


e If any segment-list is configured with more labels than the maximum segment list depth, the configuration 
commit check fails with an error. 


Dynamic Creation of Segment Routing LSPs 


IN THIS SECTION 


Configuring Dynamic Segment Routing LSP Template | 1482 

Resolving Dynamic Segment Routing LSPs | 1483 

Considerations for Configuring Dynamic Creation of Segment Routing LSPs | 1487 
Services Supported over Dynamic Segment Routing LSPs | 1487 

Behavior With Multiple Tunnel Sources in Segment Routing | 1488 


Dynamic Segment Routing LSPs Limitations | 1488 


In segment routing networks that have each provider edge (PE) device connected to every other PE device, 
a large amount of configuration is required for setting up the segment routing label-switched paths (LSPs), 
although only a few segment routing traffic-engineered (SR-TE) paths may be used. You can enable 

BGP-trigerred dynamic creation of these LSPs to reduce the amount of configuration in such deployments. 


Configuring Dynamic Segment Routing LSP Template 


To configure the template for enabling dynamic creation of segment routing LSPs, you must include the 
spring-te statement at the [edit routing-options dynamic-tunnels] hierarchy. 


e The following is a sample configuration for color dynamic segment routing LSP template: 


[edit routing-options] 
dynamic-tunnels { 
<dynamic-tunnel-name> { 
spring-te { 
source-routing-path-template { 
<template-name1> color [c1 c2]; 
<template-name2> color [c3]; 
<template-name3> color-any; 
} 
destination-networks { 
<dest1>; 
<dest2>; 


e The following is a sample configuration for non-color dynamic segment routing LSP template: 


dynamic-tunnels { 
<dynamic-tunnel-name> { 
spring-te { 
source-routing-path-template { 
<template-name1>; 


} 


destination-networks { 
<dest1>; 
<dest2>; 


Resolving Dynamic Segment Routing LSPs 


IN THIS SECTION 
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Resolving Colored Dynamic Segment Routing LSP 


When the BGP prefixes are assigned with color community, they initially get resolved over the 
catch-all-route-for-that-particular-color policy, and in turn, the SR-TE template on which the BGP prefix 
should be resolved onto is identified. The destinations SID is then derived from the BGP payload prefix 
next-hop attribute. For example, if the next hop of the BGP payload prefix is an IP address that belongs 
to Device A, then the node-SID of Device A is taken and a corresponding label is prepared and pushed to 
the bottom of the stack. The BGP payload prefix is resolved in a color-only mode, where the node-SID of 
Device A is at the bottom of the final label stack, and the SR-TE path labels are on top. 


The final LSP template name is a combination of prefix, color, and tunnel name; for example, 
<prefix>:<color>:dt-srte-<tunnel-name>. The color in the LSP name is displayed in hexadecimal format, 
and the format of the tunnel name is similar to that o RSVP-triggered tunnel LSP names. 
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To successfully resolve a colored destination network, the color should have a valid template mapping, 
either to a specific color, or through the color-any template. Without a valid mapping, the tunnel is not 
created and the BGP route requesting for resolution remains unresolved. 


Resolving Uncolored Dynamic Segment Routing LSPs 


The catch-all routes for non-colored LSPs are added to the inet.3 routing table. The non-colored tunnel 

destination must be configured in a different spring-te configuration with only one template name in the 
mapping list. This template name is used for all the tunnel routes matching any of the destination networks 
configured under the same spring-te configuration. These tunnels are similar to RSVP tunnels in functionality. 


The final LSP template name is a combination of prefix and tunnel name; for example, 
<prefix>:dt-srte-<tunnel-name>. 


Dynamic Segment Routing LSP Sample Configuration 
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The dynamic segment routing LSP template always carries a partial path. The last hop node SID is derived 
automatically at the tunnel creation time depending on the protocol next-hop address (PNH) node SID. 
The same template can be used by multiple tunnels to different destinations. In such cases, the partial 
path remains the same, and only the last hop changes depending on the PNH. Dynamic segment routing 
LSP templates are not common to a single tunnel, as a result a full path cannot be carried on it. You can 
use a segment list if a full path is to be used. 


Colored Dynamic Segment Routing LSPs 


Sample configuration for colored dynamic segment routing LSPs: 


protocols source-packet-routing { 
source-routing-path-template sr_Isp11 { 
primary sr_sl1 
primary sr_sl2 weight 2 
sr-preference 180; 


} 
dynamic-tunnels tunnel1 { 
spring-te { 
source-routing-path-template { 


1485 


sr_Isp1 color [123 124 125 ]; 
sr_lsp2 color-any 

} 

destination-networks { 
22.33.44.0/24; 


For the above-mentioned sample configuration, the route entries are as follows: 


inetcolor.O tunnel route: 22.33.44.0-0/24 --> RT_.NH_TUNNEL 

inetcolor6.0 tunnel route: ffff::22.33.44.0-0/120 --> RT_NH_TUNNEL 

BGP prefix to tunnel mapping: 

R1 (prefix) -> 22.33.44.55-101(PNH) LSP tunnel name = 22.33.44.55:65:dt-srte-tunnel1 

R1 (prefix) -> ffff::22.33.44.55-101(PNH) LSP tunnel name = 22.33.44.55:65:dt-srte-tunnel1 
R1 (prefix) -> ffff::22.33.44.55-124(PNH) LSP tunnel name = 22.33.44.55:7c:dt-srte-tunnel1 
inetcolor.0 tunnel route: 

22.33.44.55-101/64 --> <next-hop> 

22.33.44.55-124/64 --> <next-hop> 

inetcolor6.0 tunnel route: 

ffff::22.33.44.55-101/160 --> <next-hop> 

ffff::22.33.44.55-124/160 --> <next-hop> 


Non-Colored Dynamic Segment Routing LSPs 


Sample configuration for non-colored dynamic segment routing LSPs: 


protocols source-packet-routing { 
source-routing-path-template sr_Isp1 { 
primary sr_sl1 
primary sr_sl2 weight 2 
sr-preference 180; 


} 
dynamic-tunnels { 
tunnel1 { 
spring-te { 
source-routing-path-template { 


sr_Isp1 color [ 101 ]; 
} 
destination-networks { 
22.33.44.0/24; 


} 
tunnel2 { 
spring-te { 
source-routing-path-template { 
sr_Isp1; 
} 
destination-networks { 
22.33.44.0/24; 


For the above-mentioned sample configuration, the route entries are as follows: 


inet.3 tunnel route: 22.33.44.0/24 --> RT_NH_TUNNEL 
inet6.3 tunnel route: ffff::22.33.44.0/120 --> RT_NH_TUNNEL 


BGP prefix to tunnel mapping: 


R1 (prefix) -> 22.33.44.55(PNH) LSP template name = LSP1 --- 22.33.44.55:dt-srte-tunnel2 
R1 (prefix) -> ffff::22.33.44.55(PNH) LSP template name = LSP1 --- 22.33.44.55:dt-srte-tunnel2 
inet.3 tunnel route: 22.33.44.55/32 --> <next-hop> 


inet6.3 tunnel route: ffff::22.33.44.55/128 --> <next-hop> 


Unresolved Dynamic Segment Routing LSP 


Sample configuration for unresolved dynamic segment routing LSPs: 


protocols source-packet-routing { 


source-routing-path-template sr_Isp1 { 


primary sr_sl1 
primary sr_sl2 weight 2 
sr-preference 180; 
} 
} 
dynamic-tunnels tunne!1 { 
spring-te { 
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source-routing-path-template { 
sr_Isp1 color [120 121 122 123]; 
} 


destination-networks { 
22.33.44.0/24; 
1.1.1.0/24, 


For the above-mentioned sample configuration, the route entries are as follows: 


inetcolor.O tunnel route: 22.33.44.0 - 0/24 --> RT_.NH_TUNNEL 1.1.1.0 - 0 /24 --> RT_NH_TUNNEL 


inetcolor6.0 tunnel route: ffff::22.33.44.0 - 0/120 --> RT_.NH_TUNNEL ffff::1.1.1.0 - 0 /24 --> 
RT_NH_TUNNEL 


BGP prefix to tunnel mapping: R1 (prefix) -> 22.33.44.55-124(PNH) Tunnel will not be created. (Template 
not found for the color). 


Considerations for Configuring Dynamic Creation of Segment Routing LSPs 
When configuring the dynamic creation of segment routing LSPs, take the following into consideration: 
e Atemplate can be assigned with a color object. When the dynamic tunnel spring-te configuration includes 


a template with a color object, you must configure all other templates with color objects as well. All 
destinations are assumed to be colored within that configuration. 


e Atemplate can have a list of colors defined on it, or can be configured with the color-any option. Both 
these options can coexist in the same spring-te configuration. In such cases, templates assigned with 
specific colors have a higher preference. 


Ina spring-te configuration, only one template can be defined with the color-any option. 


The color-to-template mapping is done on a one-to-one basis. One color cannot map to multiple templates. 


The template name should be configured in the spring-te statement under the [edit protocols] hierarchy, 


and should have the primary option enabled. 
e Colored and non-colored destinations cannot co-exist in the same spring-te configuration. 


e You cannot configure same destination networks, with or without color, under different spring-te 
configuration statements. 


e Innon-colored spring-te configuration, only one template can be configured without color object. 


Services Supported over Dynamic Segment Routing LSPs 


The following services are supported over colored dynamic segment routing LSPs: 


e Layer 3 VPN 
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e BGP EVPN 
e Export policy services 
The following services are supported over non-colored dynamic segment routing LSPs: 


e Layer 3 VPN 
e Layer 2 VPN 


e Multipath configurations 


Behavior With Multiple Tunnel Sources in Segment Routing 


When two sources download routes to the same destination from segment routing (for example static and 
dynamic sourced tunnels), then the segment routing preference is used for choosing the active route entry. 
A higher value has greater preference. In case the preference remains the same, then the tunnel source is 
used to determine the route entry. 


Dynamic Segment Routing LSPs Limitations 

The dynamic SR-TE LSPs do not support the following features and functionalities: 

e IPvé segment routing tunnels. 

e Static tunnels. 

e 6PE is not supported. 

e Distributed CSPF. 

e sBFD and LDP tunnelling is not supported for dynamic SR-TE LSPs and in a template. 


e Install and B-SID routes in a template. 


Color-Based Mapping of VPN Services 
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You can specify color as a protocol next hop constraint (in addition to the IPv4 or IPv6 address) for resolving 
transport tunnels over static colored and BGP segment routing traffic-engineered (SRTE) LSPs. This is 
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called the color-IP protocol next hop resolution, where you are required to configure a resolution-map 
and apply to the VPN services. With this feature, you can enable color-based traffic steering of Layer 2 
and Layer 3 VPN services. 


Junos OS supports colored SRTE LSPs associated with a single color. The color-based mapping of VPN 
services feature is supported on static colored LSPs and BGP SRTE LSPs. 


VPN Service Coloring 
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In general, a VPN service may be assigned a color on the egress router where the VPN NLRI is advertised, 
or on an ingress router where the VPN NLRI is received and processed. 


You can assign a color to the VPN services at different levels: 


e Per routing instance. 
e Per BGP group. 
e Per BGP neighbor. 


e Per prefix. 


Once you assign a color, the color is attached to a VPN service in the form of BGP color extended 
community. 


You can assign multiple colors to a VPN service, referred to as multi-color VPN services. In such cases, 
the last color attached is considered as the color of the VPN service, and all other colors are ignored. 


Multiple colors are assigned by egress and/or ingress devices through multiple policies in the following 
order: 


e BGP export policy on the egress device. 
e BGP import policy on the ingress device. 
e VRF import policy on the ingress device. 
The two modes of VPN service coloring are: 


Egress Color Assignment 


In this mode, the egress device (that is, the advertiser of the VPN NLRI) is responsible for coloring the VPN 
service. To enable this mode, you can define a routing policy, and apply it in the VPN service’s 
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routing-instance vrf-export, group export, or group neighbor export at the [edit protocols bgp] hierarchy 
level. The VPN NLRI is advertised by BGP with the specified color extended community. 


For example: 


[edit routing-options] 
community red-comm { 
members color:0:50; 


[edit policy-options] 
policy-statement pol-color { 
term t1 { 
from { 
[any match conditions]; 


} 

then { 
community add red-comm; 
accept; 


[edit routing-instances] 
vpn-X { 


vrf-export pol-color ...; 


NOTE: When you apply the routing policy as an export policy of a BGP group or BGP neighbor, 
you must include the vpn-apply-export statement at the BGP, BGP group, or BGP neighbor level 
in order for the policy to take an effect on the VPN NLRI. 


[edit protocols bgp] 
group PEs { 


neighbor PE-A { 
export pol-color ...; 
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vpn-apply-export; 


The routing policies are applied to Layer 3 VPN prefix NLRIs, Layer 2 VPN NRLIs, and EVPN NLRIs. The 
color extended community is inherited by all the VPN routes, imported, and installed in the target VRFs 
on one or multiple ingress devices. 


Ingress Color Assignment 


In this mode, the ingress device (that is, the receiver of the VPN NLRI) is responsible for coloring the VPN 
service. To enable this mode, you can define a routing policy, and apply it to the VPN service’s 
routing-instance vrf-import, group import, or group neighbor import at the [edit protocols bgp] hierarchy 
level. All the VPN routes matching the routing policy is attached with the specified color extended 
community. 


For example: 


[edit routing-options] 
community red-comm { 
members color:0:50; 


[edit policy-options] 
policy-statement pol-color { 
term t1 { 
from { 
[any match conditions]; 
} 
then { 
community add red-comm; 
accept; 


[edit routing-instances] 
vpn-Y { 


vrf-import pol-color ...; 


Or 
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[edit protocols bgp] 
group PEs { 


neighbor PE-B { 
import pol-color ...; 


Specifying VPN Service Mapping Mode 


To specify flexible VPN service mapping modes, you must define a policy using the resolution-map 
statement, and refer the policy in a VPN service's routing-instance vrf-import, group import, or group 


neighbor import at the [edit protocols bgp] hierarchy level. All the VPN routes matching the routing policy 
are attached with the specified resolution-map. 


For example: 


[edit policy-options] 

resolution-map map-A { 
<mode-1>; 
<mode-2>; 


} 
policy-statement pol-resolution { 
term t1 { 
from { 


[any match conditions]; 


} 

then { 
resolution-map map-A; 
accept; 


You can apply import policy to the VPN service’s routing-instance. 


[edit routing-instances] 
vpn-Y { 


vrf-import pol-resolution ...; 


You can also apply the import policy to a BGP group or BGP neighbor. 
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[edit protocols bgp] 
group PEs { 


neighbor PE-B { 
import pol-resolution ...; 


NOTE: Each VPN service mapping mode should have a unique name defined in the 
resolution-map. Only a single entry of IP-color is supported in the resolution-map, where the 
VPN route(s) are resolved using a colored-IP protocol next hop in the form of ip-address:color. 


Color-IP Protocol Next Hop Resolution 


The protocol next hop resolution process is enhanced to support colored-IP protocol next hop resolution. 
For a colored VPN service, the protocol next hop resolution process takes a color and a resolution-map, 
builds a colored-IP protocol next hop in the form of IP-address:color, and resolves the protocol next hop 
in the inet6color.0 routing table. 


You must configure a policy to support multipath resolution of colored Layer 2 VPN, Layer 3 VPN, or EVPN 
services over colored LSPs. The policy must then be applied with the relevant RIB table as the resolver 
import policy. 


For example: 


[edit policy-options] 
policy-statement mpath { 
then multipath-resolve; 


[edit routing-options] 
resolution { 
rib bgp.I3vpn.0 { 
inetcolor-import mpath; 


} 


resolution { 
rib bgp.I3vpn-inet6.0 { 
inet6color-import mpath; 


resolution { 
rib bgp.I2vpn.0 { 
inetcolor-import mpath; 


} 
resolution { 
rib mpls.0 { 
inetcolor-import mpath; 


} 
resolution { 
rib bgp.evpn.0O { 
inetcolor-import mpath; 


Fallback to IP Protocol Next Hop Resolution 


If a colored VPN service does not have a resolution-map applied to it, the VPN service ignores its color 
and falls back to the IP protocol next hop resolution. Conversely, if a non-colored VPN service has a 
resolution-map applied to it, the resolution-map is ignored, and the VPN service uses the IP protocol next 
hop resolution. 


The fallback is a simple process from colored SRTE LSPs to LDP LSPs, by using a RIB group for LDP to 
install routes in inet{6}color.O routing tables. A longest prefix match for a colored-IP protocol next hop 
ensures that if a colored SRTE LSP route does not exist, an LDP route with a matching IP address should 
be returned. 


BGP Labeled Unicast Color-based Mapping over SR-TE Tunnels 


Starting in Junos OS Release 20.2R1, BGP Labeled Unicast (BGP-LU) can resolve IPv4 and IPv6 routes 
over IPv4 and IPvé segment routing-traffic engineering (SR-TE) tunnels. . You can configure a resolution 
map policy for BGP-LU to construct colored protocol next hops by combining BGP next hop and BGP 
extended color community. The colored protocol next hops are then resolved on colored SR-TE tunnels 
in the inetcolor.0O or inet6color.0 table. If a resolution map policy is not configured, BGP-LU continues to 
use inet.3 and inet6.3 tables for non-color based mapping. The BGP-LU IPvé6 feature supports IPv6-only 
networks where routers do not have any IPv4 addresses configured. Currently we support BGP IPvé LU 
over IPv6 SR-TE with IS-IS underlay. 


In Figure 54 on page 734, the controller configures 4 colored SR-TE tunnels from Router A to Router D in 
an IPv6 core network. Each colored tunnel takes a different path to the destination, abcd::3701:2d05. On 
Router A, BGP imports policies to assign an extended color community and resolution map of IP-Color to 
the received BGP-LU prefix abcd::3700:6/128. Based on the resolution map and the color, BGP-LU resolves 
the colored protocol next hop on one of the colored SR-TE tunnels. 
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Figure 124: BGP IPvé6 LU over colored IPv6 SR-TE Tunnels 
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BGP-LU supports the following scenarios: 


e BGP IPv4 LU over colored BGP IPv4 SR-TE, with ISIS/OSPF IPv4 SR extensions. 
e BGP IPv4 LU over static colored and non-colored IPv4 SR-TE, with ISIS/OSPF IPv4 SR extensions. 
e BGP IPv6é LU over colored BGP IPv6 SR-TE, with ISIS IPv6 SR extensions. 


e BGP IPvé6 LU over static colored and non-colored IPv6 SR-TE, with ISIS IPv6 SR extensions. 


Supported and Unsupported Features for Color-Based Mapping of VPN Services 

The following features and functionality are supported with color-based mapping of VPN services: 
e BGP Layer 3 VPN 

e BGP Layer 2 VPN (Kompella Layer 2 VPN) 

e BGP EVPN 


Resolution-map with a single IP-color option. 


Colored IPv4 and IPv6 protocol next hop resolution. 


Routing information base (also known as routing table) group based fallback to LDP LSP in inetcolor.O 
routing table. 


Colored SRTE LSP. 


e Virtual platforms. 


e 64-bit Junos OS. 


Logical systems. 


BGP labeled unicast. 
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The following features and functionality are not supported with color-based mapping of VPN services: 


e Colored MPLS LSPs, such as RSVP, LDP, BGP-LU, static. 

e Layer 2 circuit 

e FEC-129 BGP auto-discovered and LDP-signaled Layer 2 VPN. 
e VPLS 

e MVPN 


e IPv4 and IPvé6 using resolution-map. 


Tunnel Templates for PCE-Initiated Segment Routing LSPs 


You can configure a tunnel template for PCE-initiated segment routing LSPs to pass down two additional 
parameters for these LSPs - Bidirectional forwarding detection (BFD) and LDP tunneling. 


When a PCE-Initiated segment routing LSP is being created, the LSP is checked against policy statements 
(if any) and if there is a match, the policy applies the configured template for that LSP. The template 
configuration is inherited only if it is not provided by the LSP source (PCEP); for example, metric. 


To configure a template: 


1. Include the source-routing-path-template statement at the [edit protocols source-packet-routing] 
hierarchy level. You can configure the additional BFD and LDP tunneling parameters here. 


2. Include the source-routing-path-template-map statement at the [edit protocols source-packet-routing] 
hierarchy level to list the policy statements against which the PCE-initiated LSP should be checked. 


3. Define a policy to list the LSPs on which the template should be applied. 


The from statement can include either the LSP name or LSP regular expression using the Isp and 
Isp-regex match conditions. These options are mutually exclusive, so you can specify only one option 
at a given point in time. 


The then statement must include the sr-te-template option with an accept action. This applies the 
template to the PCE-initiated LSP. 


Take the following into consideration when configuring a template for PCE-initiated LSPs: 


e Template configuration is not applicable to staticalyy configured segment routing LSPs, or any other 
client's segment routing LSP. 


e PCEP-provided configuration has precedence over template configuration. 


e PCEP LSP does not inherit template segment-list configuration. 


Example: Configuring Static Segment Routing Label Switched Path 
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This example shows how to configure static segment routing label switched paths (LSPs) in MPLS networks. 
This configuration helps to bring higher scalability to MPLS networks. 


Requirements 


This example uses the following hardware and software components: 


e Seven MX Series 5G Universal Routing Platforms 


e Junos OS Release 18.1 or later running on all the routers 
Before you begin, be sure you configure the device interfaces. 


Overview 


Junos OS a set of explicit segment routing paths are configured on the ingress router of a non-colored 
static segment routing tunnel by configuring the segment-list statement at the [edit protocols 
source-packet-routing] hierarchy level. You can configure segment routing tunnel by configuring the 
source-routing-path statement at [edit protocols source-packet-routing] hierarchy level. The segment 
routing tunnel has a destination address and one or more primary paths and optionally secondary paths 
that refer to the segment list. Each segment list consists of a sequence of hops. For non-colored static 
segment routing tunnel, the first hop of the segment list specifies an immediate next hop IP address and 
the second to Nth hop specifies the segment identifies (SID) labels corresponding to the link or node which 
the path traverses. The route to the destination of the segment routing tunnel is installed in inet.3 table. 


Topology 


In this example, configure layer 3 VPN on the provider edge routers PE1 and PES. Configure the MPLS 
protocol on all the routers. The segment routing tunnel is configured from router PE1 to router PE5 with 
a primary path configured on router PE1 and router PE5 . Router PE1 is also configured with secondary 
path for path protection. The transit routers PE2 to PE4 are configured with adjacency SID labels with 
label pop and an outgoing interface. 
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Figure 125: Static Segment Routing Label Switched Path 
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CLI Quick Configuration 


To quickly configure this example, copy the following commands, paste them into a text file, remove any 
line breaks, change any details necessary to match your network configuration, copy and paste the 
commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode. 


PE1 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.1/24 
set interfaces ge-0/0/0 unit 0 family mpls maximum-labels 5 

set interfaces ge-0/0/1 unit 0 family inet address 10.10.13.1/24 
set interfaces ge-0/0/1 unit 0 family mpls maximum-labels 5 

set interfaces ge-0/0/5 unit 0 family inet address 10.10.17.1/24 
set routing-options autonomous-system 65000 

set routing-options forwarding-table export load-balance-policy 
set routing-options forwarding-table chained-composite-next-hop ingress I3vpn 
set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls label-range static-label-range 1000000 1000999 
set protocols bgp group pe type internal 

set protocols bgp group pe local-address 192.168.147.211 

set protocols bgp group pe family inet-vpn unicast 

set protocols bgp group pe neighbor 192.168.146.181 


PE2 
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set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols source-packet-routing segment-list sl-15-primary hop-1 ip-address 10.10.13.3 
set protocols source-packet-routing segment-list sl-15-primary hop-2 label 1000134 
set protocols source-packet-routing segment-list sl-15-primary hop-3 label 1000145 
set protocols source-packet-routing segment-list sl-15-backup hop-1 ip-address 10.10.12.2 
set protocols source-packet-routing segment-list sl-15-backup hop-2 label 1000123 

set protocols source-packet-routing segment-list sl-15-backup hop-3 label 1000134 
set protocols source-packet-routing segment-list sl-15-backup hop-4 label 1000145 

set protocols source-packet-routing source-routing-path Isp-15 to 192.168.146.181 

set protocols source-packet-routing source-routing-path Isp-15 binding-sid 1000999 
set protocols source-packet-routing source-routing-path Isp-15 primary sl-15-primary 
set protocols source-packet-routing source-routing-path Isp-15 secondary sl-15-backup 
set policy-options policy-statement VPN-A-export term a from protocol ospf 

set policy-options policy-statement VPN-A-export term a from protocol direct 

set policy-options policy-statement VPN-A-export term a then community add VPN-A 
set policy-options policy-statement VPN-A-export term a then accept 

set policy-options policy-statement VPN-A-export term b then reject 

set policy-options policy-statement VPN-A-import term a from protocol bgp 

set policy-options policy-statement VPN-A-import term a from community VPN-A 

set policy-options policy-statement VPN-A-import term a then accept 

set policy-options policy-statement VPN-A-import term b then reject 

set policy-options policy-statement bgp-to-ospf from protocol bgp 

set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger 
set policy-options policy-statement bgp-to-ospf then accept 

set policy-options policy-statement load-balance-policy then load-balance per-packet 
set policy-options community VPN-A members target:65000:1 

set routing-instances VRF1 instance-type vrf 

set routing-instances VRF1 interface ge-0/0/5.0 

set routing-instances VRF1 route-distinguisher 192.168.147.211:1 

set routing-instances VRF1 vrf-import VPN-A-import 

set routing-instances VRF1 vrf-export VPN-A-export 

set routing-instances VRF1 vrf-table-label 

set routing-instances VRF1 protocols ospf export bgp-to-ospf 

set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/5.0 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.2/24 


PE3 


PE4 


1500 


set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.2/24 

set interfaces ge-0/0/1 unit 0 family mpls 

set protocols mpls static-label-switched-path adj-23 segment 1000123 

set protocols mpls static-label-switched-path adj-23 segment next-hop 10.10.23.3 
set protocols mpls static-label-switched-path adj-23 segment pop 

set protocols mpls static-label-switched-path adj-21 segment 1000221 

set protocols mpls static-label-switched-path adj-21 segment next-hop 10.10.12.1 
set protocols mpls static-label-switched-path adj-21 segment pop 

set protocols mpls interface ge-0/0/0.0 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls label-range static-label-range 1000000 1000999 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 


set interfaces ge-0/0/0 unit 0 family inet address 10.10.13.3/24 

set interfaces ge-0/0/0 unit 0 family mpls 

set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.3/24 

set interfaces ge-0/0/1 unit 0 family mpls 

set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.3/24 

set interfaces ge-0/0/2 unit 0 family mpls 

set protocols mpls static-label-switched-path adj-34 segment 1000134 

set protocols mpls static-label-switched-path adj-34 segment next-hop 10.10.34.4 
set protocols mpls static-label-switched-path adj-34 segment pop 

set protocols mpls static-label-switched-path adj-32 segment 1000232 

set protocols mpls static-label-switched-path adj-32 segment next-hop 10.10.23.2 
set protocols mpls static-label-switched-path adj-32 segment pop 

set protocols mpls interface ge-0/0/1.0 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls label-range static-label-range 1000000 1000999 

set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 


PES 
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set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.4/24 

set interfaces ge-0/0/2 unit 0 family mpls 

set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.4/24 

set interfaces ge-0/0/3 unit 0 family mpls 

set protocols mpls static-label-switched-path adj-45 segment 1000145 

set protocols mpls static-label-switched-path adj-45 segment next-hop 10.10.45.5 
set protocols mpls static-label-switched-path adj-45 segment pop 

set protocols mpls static-label-switched-path adj-43 segment 1000243 

set protocols mpls static-label-switched-path adj-43 segment next-hop 10.10.34.3 
set protocols mpls static-label-switched-path adj-43 segment pop 

set protocols mpls interface ge-0/0/2.0 

set protocols mpls interface ge-0/0/3.0 

set protocols mpls label-range static-label-range 1000000 1000999 

set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 


set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.5/24 

set interfaces ge-0/0/3 unit 0 family mpls maximum-labels 5 

set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.5/24 

set routing-options autonomous-system 65000 

set protocols mpls interface ge-0/0/3.0 

set protocols mpls label-range static-label-range 1000000 1000999 

set protocols bgp group pe type internal 

set protocols bgp group pe local-address 192.168.146.181 

set protocols bgp group pe family inet-vpn unicast 

set protocols bgp group pe neighbor 192.168.147.211 

set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 

set protocols ospf area 0.0.0.0 interface lo0.0 

set protocols bfd sbfd local-discriminator 0.0.0.32 minimum-receive-interval 1000 
set protocols source-packet-routing segment-list sl-51 hop-1 ip-address 10.10.45.4 
set protocols source-packet-routing segment-list sl-51 hop-2 label 1000243 

set protocols source-packet-routing segment-list sl-51 hop-3 label 1000232 

set protocols source-packet-routing segment-list sl-51 hop-4 label 1000221 

set protocols source-packet-routing source-routing-path Isp-51 to 192.168.147.211 
set protocols source-packet-routing source-routing-path Isp-51 primary sl-51 

set policy-options policy-statement VPN-A-export term a from protocol ospf 

set policy-options policy-statement VPN-A-export term a from protocol direct 

set policy-options policy-statement VPN-A-export term a then community add VPN-A 


set policy-options policy-statement VPN-A-export term a then accept 

set policy-options policy-statement VPN-A-export term b then reject 

set policy-options policy-statement VPN-A-import term a from protocol bgp 

set policy-options policy-statement VPN-A-import term a from community VPN-A 
set policy-options policy-statement VPN-A-import term a then accept 

set policy-options policy-statement VPN-A-import term b then reject 

set policy-options policy-statement bgp-to-ospf from protocol bgp 

set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger 
set policy-options policy-statement bgp-to-ospf then accept 

set policy-options community VPN-A members target:65000:1 

set routing-instances VRF1 instance-type vrf 

set routing-instances VRF1 interface ge-0/0/4.0 

set routing-instances VRF1 route-distinguisher 192.168.146.181:1 

set routing-instances VRF1 vrf-import VPN-A-import 

set routing-instances VRF1 vrf-export VPN-A-export 

set routing-instances VRF1 vrf-table-label 

set routing-instances VRF1 protocols ospf export bgp-to-ospf 

set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/4.0 


CE1 
set interfaces ge-0/0/0 unit 0 family inet address 10.10.17.7/24 
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 
CE2 
set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.6/24 
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 
Configuring Device PE1 


Step-by-Step Procedure 


The following example requires that you navigate various levels in the configuration hierarchy. For 


information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


To configure Device PE1: 


1. Configure the interfaces. 
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[edit interfaces] 
set ge-0/0/0 unit O family inet address 10.10.12.1/24 
set ge-0/0/0 unit 0 family mpls maximum-labels 5 


set ge-0/0/1 unit 0 family inet address 10.10.13.1/24 
set ge-0/0/1 unit O family mpls maximum-labels 5 


set ge-0/0/5 unit O family inet address 10.10.17.1/24 


2. Configure autonomous system number and options to control packet forwarding routing options. 


[edit routing-options] 

set autonomous-system 65000 

set forwarding-table export load-balance-policy 

set forwarding-table chained-composite-next-hop ingress I3vpn 


3. Configure the interfaces with the MPLS protocol and configure the MPLS label range. 


[edit protocols mpls] 

set interface ge-0/0/0.0 

set interface ge-0/0/1.0 

set label-range static-label-range 1000000 1000999 


4. Configure the type of peer group, local address, protocol family for NLRIs in updates, and IP address 
of a neighbor for the peer group. 


[edit protocols bgp] 

set group pe type internal 

set group pe local-address 192.168.147.211 
set group pe family inet-vpn unicast 

set group pe neighbor 192.168.146.181 


5. Configure the protocol area interfaces. 


[edit protocols ospf] 

set area 0.0.0.0 interface ge-0/0/0.0 
set area 0.0.0.0 interface lo0.0 

set area 0.0.0.0 interface ge-0/0/1.0 
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6. Configure the IPv4 address and labels of primary and secondary paths for source routing-traffic 
engineering (TE) policies of protocol source packet routing (SPRING). 


[edit protocols source-packet-routing segment-list] 
set sl-15-primary hop-1 ip-address 10.10.13.3 

set sl-15-primary hop-2 label 1000134 

set sl-15-primary hop-3 label 1000145 

set sl-15-backup hop-1 ip-address 10.10.12.2 

set sl-15-backup hop-2 label 1000123 

set sl-15-backup hop-3 label 1000134 

set sl-15-backup hop-4 label 1000145 


7. Configure destination IPv4 address, binding SID label, primary, and secondary source routing path for 
protocol SPRING. 


[edit protocols source-packet-routing source-routing-path] 
set Isp-15 to 192.168.146.181 

set Isp-15 binding-sid 1000999 

set Isp-15 primary sl-15-primary 

set Isp-15 secondary sl-15-backup 


8. Configure policy options. 


[edit policy-options policy-statement] 

set VPN-A-export term a from protocol ospf 

set VPN-A-export term a from protocol direct 

set VPN-A-export term a then community add VPN-A 
set VPN-A-export term a then accept 

set VPN-A-export term b then reject 

set VPN-A-import term a from protocol bgp 

set VPN-A-import term a from community VPN-A 

set VPN-A-import term a then accept 

set VPN-A-import term b then reject 

set bgp-to-ospf from protocol bgp 

set bgp-to-ospf from route-filter 10.10.0.0/16 orlonger 
set bgp-to-ospf then accept 

set load-balance-policy then load-balance per-packet 


9. Configure BGP community information. 


[edit policy-options] 
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set community VPN-A members target:65000:1 


10. Configure routing instance VRF1 with instance type, interface, router distinguisher, VRF import, export 
and table label. Configure export policy and interface of area for protocol OSPF. 


[edit routing-instances VRF1] 

set instance-type vrf 

set interface ge-0/0/5.0 

set route-distinguisher 192.168.147.211:1 

set vrf-import VPN-A-import 

set vrf-export VPN-A-export 

set vrf-table-label 

set protocols ospf export bgp-to-ospf 

set protocols ospf area 0.0.0.0 interface ge-0/0/5.0 


Results 


From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, 
show protocols, show routing-options, and show routing-instances commands. If the output does not 
display the intended configuration, repeat the instructions in this example to correct the configuration. 


user@PE1# show interfaces 
ge-0/0/0 { 
unit O { 

family inet { 
address 55.1.12.1/24; 

} 

family mpls { 
maximum-labels 5; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 55.1.13.1/24; 
} 
family mpls { 
maximum-labels 5; 


ge-0/0/5 { 
unit O { 
family inet { 
address 55.1.17.1/24; 


user@PE1# show routing-options 


autonomous-system 65000; 
forwarding-table { 
export load-balance-policy; 
chained-composite-next-hop { 
ingress { 
I3vpn; 


user@PE1# show protocols 
mpls { 
interface ge-0/0/0.0; 
interface ge-0/0/1.0; 
label-range { 
static-label-range 1000000 1000999; 


} 
bgp { 
group pe { 
type internal; 
local-address 128.9.147.211; 
family inet-vpn { 
unicast; 

} 
neighbor 128.9.146.181; 


} 
ospf { 
area 0.0.0.0 { 
interface ge-0/0/0.0; 
interface 100.0; 
interface ge-0/0/1.0; 
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} 
bfd { 
} 
source-packet-routing { 
segment-list sl-15-primary { 
hop-1 ip-address 55.1.13.3; 
hop-2 label 1000134; 
hop-3 label 1000145; 
} 
segment-list sl-15-backup { 
hop-1 ip-address 55.1.12.2; 
hop-2 label 1000123; 
hop-3 label 1000134; 
hop-4 label 1000145; 
} 
source-routing-path Isp-15 { 
to 128.9.146.181; 
binding-sid 1000999; 
primary { 
sl-15-primary; 
} 
secondary { 
sl-15-backup; 


user@PE1# show policy-options 
policy-statement VPN-A-export { 
terma { 
from protocol [ ospf direct ]; 
then { 
community add VPN-A; 
accept; 


} 
term b { 
then reject; 


} 
policy-statement VPN-A-import { 
terma { 
from { 


1507 


protocol bgp; 
community VPN-A; 
} 
then accept; 
} 
term b { 
then reject; 


} 
policy-statement bgp-to-ospf { 
from { 
protocol bgp; 
route-filter 55.1.0.0/16 orlonger; 
} 
then accept; 
} 
policy-statement load-balance-policy { 
then { 
load-balance per-packet; 


} 
community VPN-A members target:65000:1; 


user@PE1# show routing-instances 
VRF1 { 
instance-type vrf; 
interface ge-0/0/5.0; 
route-distinguisher 128.9.147.211:1; 
vrf-import VPN-A-import; 
vrf-export VPN-A-export; 
vrf-table-label; 
protocols { 
ospf { 
export bgp-to-ospf; 
area 0.0.0.0 { 
interface ge-0/0/5.0; 


Configuring Device PE2 


Step-by-Step Procedure 
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The following example requires that you navigate various levels in the configuration hierarchy. For 
information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide. 


1. Configure the interfaces. 


[edit interfaces] 
set ge-0/0/0 unit O family inet address 10.10.12.2/24 
set ge-0/0/0 unit O family mpls 


set ge-0/0/1 unit O family inet address 10.10.23.2/24 
set ge-0/0/1 unit O family mpls 


2. Configure the static LSP for protocol MPLS. 


3. Configure interfaces and static label range for protocol MPLS. 


[edit protocols mpls static-label-switched-path] 
set adj-23 segment 1000123 

set adj-23 segment next-hop 10.10.23.3 

set adj-23 segment pop 

set adj-21 segment 1000221 

set adj-21 segment next-hop 10.10.12.1 

set adj-21 segment pop 


[edit protocols mpls] 

set interface ge-0/0/0.0 

set interface ge-0/0/1.0 

set label-range static-label-range 1000000 1000999 


4. Configure interfaces for protocol OSPF. 


Results 


From configuration mode on router PE2, confirm your configuration by entering the show interfaces and 
show protocols commands. If the output does not display the intended configuration, repeat the instructions 


[edit protocols ospf area 0.0.0.0] 
set interface ge-0/0/0.0 
set interface ge-0/0/1.0 


in this example to correct the configuration. 
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user@PE2# show interfaces 
ge-0/0/0 { 
unit O { 
family inet { 
address 55.1.12.2/24; 
} 


family mpls; 


} 
ge-0/0/1 { 
unit O { 
family inet { 
address 55.1.23.2/24, 
} 


family mpls; 


user@PE2# show protocols 
mpls { 
static-label-switched-path adj-23 { 
segment { 
1000123; 
next-hop 55.1.23.3; 


pop; 


} 
static-label-switched-path adj-21 { 
segment { 
1000221; 
next-hop 55.1.12.1; 
pop; 


} 
interface ge-0/0/0.0; 
interface ge-0/0/1.0; 
label-range { 
static-label-range 1000000 1000999; 


} 
ospf { 
area 0.0.0.0 { 
interface ge-0/0/0.0; 
interface ge-0/0/1.0; 
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Verification 


IN THIS SECTION 


Verifying Route Entry of Routing Table inet.3 of Router PE1 | 1511 

Verifying Route Table Entries of Routing Table mpls.0 of Router PE1 | 1512 

Verifying SPRING Traffic Engineered LSP of Router PE1 | 1512 

Verifying SPRING Traffic Engineered LSPs on the Ingress Router of Router PE1 | 1513 


9 
@ 
9 
®@ 
@ Verifying the Routing Table Entries of Routing Table mpls.0 of Router PE2 | 1514 
© 


Verifying the Status of Static MPLS LSP Segments of Router PE2 | 1515 


Confirm that the configuration is working properly. 
Verifying Route Entry of Routing Table inet.3 of Router PE1 


Purpose 


Verify the route entry of routing table inet.3 of router PE1. 
Action 


From operational mode, enter the show route table inet.3 command. 





user@PE1> show route table inet.3 


inet.3: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 


192.168.146.181/32 PSE REGEN Gb .OslO SiO) AG) mmc ieeresieomelt 
ScomlOr ORG resm vet cg —0y/.0)/sle0 mets nelAO\O ONE Sy am etiam OO OeSAN tao) 





to 10.10.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, 
Push 1000123 (top) 


Meaning 


The output displays the ingress routes of segment routing tunnels. 


Verifying Route Table Entries of Routing Table mpls.0 of Router PE1 


Purpose 


Verify the route entries of routing table mpls.O 
Action 


From operational mode, enter the show route table mpls.0 command. 


user@PE1> show route table mpls.0 





mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, O hidden) 
































+ = Active Route, Last Active, * = Both 

0 “(MES / Ol] OSeL25852, imsiereale: i 
Receive 

il IMPS Ol Ossi2 S12) emeie atom 
Receive 

2) IMPS) Oll0 S32 51> 2) aemeteraatcml 
Receive 

3} =(MPLS/O]) OFe25s52, wrercieale il 
Receive 

16 Avie Ny AON OS eae) 

> wala iei.0 (WRF), LoS 
1000999 * [SPRING-TE/8] 03:04:03, metric 1 
> to 10.10.13.3 via ge-0/0/1.0, Swap 1000145, Push 1000134 (top) 


to 10.10.12.2 via ge-0/0/0.0, Swap 1000145, Push 1000134, 
Push 1000123 (top) 


Meaning 


The output displays the SID labels of segment routing tunnels. 


Verifying SPRING Traffic Engineered LSP of Router PE1 


Purpose 


Verify SPRING traffic engineered LSPs on the ingress routers. 
Action 


From operational mode, enter the show spring-traffic-engineering overview command. 





user@PE1> show spring-traffic-engineering overview 
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Overview of SPRING-TE: 





el 


Route preference: 8 


Number of LSPs: 1 (Up: 1, Down: 0) 





External controllers: 


< Not configured > 


Meaning 


The output displays the overview of SPRING traffic engineered LSPs on the ingress router. 


Verifying SPRING Traffic Engineered LSPs on the Ingress Router of Router PE1 


Purpose 


Verify SPRING traffic engineered LSPs on the ingress router. 
Action 


From operational mode, enter the show spring-traffic-engineering Isp detail command. 





user@PE1# show spring-traffic-engineering Isp detail 


Name: lsp-15 

HOS W268. VAS, We 

State: Up 
Petting Sill S—jeseimescy 
Outgoing interface: ge-0/0/1.0 
BFD status: N/A (Up: 0, Down: 0) 





SR-ERO) hop) count: 3 
Bee I (Sieraeie)) < 
NAS Iw Aclieeemey 1D, O.0.0.0 —> 10.10,15.3 
SID type: None 
neo 2 (SiteiCie)) s 
NAT: None 
SID type: 20-bit label, Value: 1000134 
EUG OMS Man (ionlenraele oles) ies 
NAI: None 
SID type: 20-bit label, Value: 1000145 
Path ssi > backup 
Outgoing interface: ge-0/0/0.0 
BFD status: N/A (Up: 0, Down: 0) 
SR-ERO hop count: 4 





Inky I (Siewaleie)) = 
NAS Iw Mchaccsiney ID, O.0.0,0 —> 10.10.12 ,2 
SID type: None 
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Ineo 2 ((SiEwaLSHE)) = 
NAI: None 


SID type: 


NAI: None 


SID type: 


NAI: None 
SID type: 


Total displayed LSPs: 


Meaning 


20-bit label, Value: 
ne 3 (SireiLeis) s 


20-bit label, Value: 
Bey 4 (Sieraeie)) < 


20-bit label, Value: 


I (Ujeg 1, Dew 


Nn: 


0) 


1000123 


1000134 


1000145 


The output displays details of SPRING traffic engineered LSPs on the ingress router 


Verifying the Routing Table Entries of Routing Table mpls.0 of Router PE2 


Purpose 


Verify the routing table entries of routing table mpls.O of router PE2. 


Action 


From operational mode, enter the show route table mpls.0 command. 





user@PE2> show route table mpls.0 


mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, O hidden) 








+ = Active Rout 
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1000221 (S=0) *([MPLS/6] 03:22:29, metric 1 
acon Opel Opreermnvaitcmcic— 010/10 Ome Op 


Verifying the Status of Static MPLS LSP Segments of Router PE2 


Purpose 
Verify the status of MPLS LSP segments of router PE2. 


Action 


From operational mode, enter the show mpls static-Isp command. 





user@PE2> show mpls static-Isp 


LIMGIASSS ILVSIENS)s 
Total 0, displayed 0, Up 0, Down 0 


Transit LSPs: 





Total 0, displayed 0, Up 0, Down 0 


Bypass lskst 
Total 0, displayed 0, Up 0, Down 0 


Segment LSPs: 


LSPname SID-label State 
alcla=2as OCO2Z 2s Up 
adeia2s 1000123 Up 


Total 2, displayed 2, Up 2, Down 0 


Meaning 


The output displays the status of static MPLS LSP segments of router PE2. 
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Release History Table 


Release Description 


20.2R1 Starting in Junos OS Release 20.2R1, BGP Labeled Unicast (BGP-LU) can resolve IPv4 and IPvé 
routes over IPv4 and IPv6é segment routing-traffic engineering (SR-TE) tunnels. 


19.4R1 You can configure a tunnel template for PCE-initiated segment routing LSPs to pass down two 
additional parameters for these LSPs - Bidirectional forwarding detection (BFD) and LDP tunneling. 


19.1R1 Starting in Junos OS Release 19.1R1, a commit check feature is introduced to ensure that all the 
segment lists contributing to the colored routes have the minimum label present for all hops. 


19.1R1 Starting in Junos OS Release 19.1R1, this requirement does not apply, as the first hop of the 
non-colored static LSPs now provides support for SID labels, in addition to IP addresses. With the 
first hop label support, MPLS fast reroute (FRR) and weighted equal-cost multipath is enabled for 
resolving the static non-colored segment routing LSPs, similar to colored static LSPs. 


18.2R1 Starting in Junos OS Release 18.2R1, statically configured non-colored segment routing LSPs on 
the ingress device are reported to the Path Computation Element (PCE) through a Path Computation 
Element Protocol (PCEP) session. 


Enabling Distributed CSPF for Segment Routing LSPs 


IN THIS SECTION 


Distributed CSPF Computation Constraints | 1517 
Distributed CSPF Computation Algorithm | 1517 
Distributed CSPF Computation Database | 1518 


3 
(3) 
e 
@® ~~ Configuring Distributed CSPF Computation Constraints | 1518 
@ Distributed CSPF Computation | 1520 

@ Interaction Between Distributed CSPF Computation and SRTE Features | 1520 
e 


Distributed CSPF Computation Sample Configurations | 1521 


Prior to Junos OS Release 19.2R1S1, for traffic engineering of segment routing paths, you could either 
explicitly configure static paths, or use computed paths from an external controller. With the distributed 
Constrained Shortest Path First (CSPF) for segment routing LSP feature, you can compute a segment 
routing LSP locally on the ingress device according to the constraints you have configured. With this 
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feature, the LSPs are optimized based on the configured constraints and metric type (traffic-engineering 
or IGP). The LSPs are computed to utilize the available ECMP paths to the destination with segment routing 
label stack compression enabled or disabled. 


Distributed CSPF Computation Constraints 


Segment routing LSP paths are computed when all the configured constraints are met. 


The distributed CSPF computation feature supports the following subset of constraints specified in the 
Internet draft, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing Policy for Traffic Engineering: 


e Inclusion and exclusion of administrative groups. 


e Inclusion of loose or strict hop IP addresses. 


NOTE: You can specify only router IDs in the loose or strict hop constraints. Labels and other 
IP addresses cannot be specified as loose or strict hop constraints in Junos OS Release 
19.2R1-S1. 


e Maximum number of segment IDs (SIDs) in the segment list. 


e Maximum number of segment lists per candidate segment routing path. 


The distributed CSPF computation feature for segment routing LSPs does not support the following types 
of constraints and deployment scenarios: 


e IPV6 addresses. 

e Inter domain segment routing traffic engineering (SRTE) LSPs. 

e Unnumbered interfaces. 

e Multiple protocols routing protocols such as, OSPF, ISIS, and BGP-LS, enabled at the same time. 
e Computation with prefixes or anycast addresses as destinations. 


e Including and excluding interface IP addresses as constraints. 


Distributed CSPF Computation Algorithm 


IN THIS SECTION 


@ Label Stack Compression Enabled | 1518 
@ Label Stack Compression Disabled | 1518 
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The distributed CSPF computation feature for segment routing LSPs uses the label stack compression 
algorithm with CSPF. 


Label Stack Compression Enabled 


A compressed label stack represents a set of paths from a source to a destination. It generally consists of 
node SIDs and adjacency SIDs. When label stack compression is enabled, the result of the computation is 
a set of paths that maximize ECMP to the destination, with minimum number of SIDs in the stack, while 
conforming to constraints. 


Label Stack Compression Disabled 


The multipath CSPF computation with label stack compression disabled finds up to N segment lists to 
destination, where: 


e The cost of all segment lists is equal to and the same as the shortest traffic-engineering metric to reach 
the destination. 


e Each segment list is comprised of adjacency SIDs. 
e The value of N is the maximum number of segment lists allowed for the candidate path by configuration. 
e No two segment lists are identical. 


e Each segment list satisfies all the configured constraints. 


Distributed CSPF Computation Database 


The database used for SRTE computation has all links, nodes, prefixes and their characteristics irrespective 
of whether traffic-engineering is enabled in those advertising nodes. In other words, it is the union of the 
traffic-engineering database (TED) and the IGP link state database of all domains that the computing node 
has learnt from. 

Configuring Distributed CSPF Computation Constraints 

You can use a compute profile to logically group the computation constraints. These compute profiles are 


referenced by the segment routing paths for computing the primary and secondary segment routing LSPs. 


To configure a compute profile, include the compute-profile statement at the [edit protocols 
source-packet-routing] hierarchy level. 


The configuration for the supported computation constraints include: 


e Administrative groups 


You can configure admin-groups under the [edit protocols mpls] hierarchy level. Junos OS applies the 
administrative group configuration to the segment routing traffic-engineering (SRTE) interfaces. 


To configure the computation constraints you can specify three categories for a set of administrative 
groups. The computation constraint configuration can be common to all candidate segment routing 
paths, or it can be under individual candidate paths. 


e include-any—Specifies that any link with at least one of the configured administrative groups in the 
list is acceptable for the path to traverse. 


e include-all—Specifies that any link with all of the configured administrative groups in the list is 
acceptable for the path to traverse. 


e exclude—Specifies that any link which does not have any of the configured administrative groups in 
the list is acceptable for the path to traverse. 


Explicit path 


You can specify a series of router IDs in the compute profile as a constraint for computing the SRTE 
candidate paths. Each hop has to be an IPv4 address and can be of type strict or loose. If the type of a 
hop is not configured, strict is used. You must include the compute option under the segment-list 
statement when specifying the explicit path constraint. 


Maximum number of segment lists (ECMP paths) 


You can associate a candidate path with a number of dynamic segment-lists. The paths are ECMP paths, 
where each segment-list translates into a next hop gateway with active weight. These paths are a result 
of path computation with or without compression. 


You can configure this attribute using the maximum-computed-segment-lists 
maximum-computed-segment-lists option under the compute-profile configuration statement. This 
configuration determines the maximum number of such segment lists computed for a given primary and 
secondary LSP. 


Maximum segment list depth 


The maximum segment list depth computation parameter ensures that amongst the ECMP paths that 
satisfy all other constraints such as administrative group, only the paths that have segment lists less than 
or equal to the maximum segment list depth are used. When you configure this parameter as a constraint 
under the compute-profile, it overrides the maximum-segment-list-depth configuration under the [edit 
protocols source-packet-routing] hierarchy level, if present. 


You can configure this attribute using the maximum-segment-list-depth maximum-segment-list-depth 
option under the compute-profile configuration statement. 


Protected or unprotected adjacency SIDs 


You can configure protected or unprotected adjacency SID as a constraint under the compute-profile 
to avoid links with the specified SID type. 


Metric type 


You can specify the type of metric on the link to be used for computation. By default, SR-TE LSPs use 
traffic-engineering metrics of the links for computation. The traffic-engineering metric for links is 
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advertised by traffic-engineering extensions of IGP protocols. However, you may also choose to use the 
IGP-metric for computation by using the metric-type configuration in the compute profile. 


You can configure this attribute using the metric-type (igp | te) option under the compute-profile 
configuration statement. 


Distributed CSPF Computation 


The SRTE candidate paths are computed locally such that they satisfy the configured constraints. When 
label stack compression is disabled, the multi-path CSPF computation result is a set of adjacency SID 
stacks. When label stack compression is enabled, the result is a set of compressed label stacks (composed 
of adjacent SIDs and node SIDs). 


When secondary paths are computed, the links, nodes and SRLGs taken by the primary paths are not 
avoided for computation. For more information on primary and secondary paths, see “Configuring Primary 
and Secondary LSPs” on page 570. 


For any LSPs with unsuccessful computation result, the computation is retried as traffic-engineering 
database (TED) changes. 


Interaction Between Distributed CSPF Computation and SRTE Features 


IN THIS SECTION 


Weights Associated With Paths of an SRTE Policy | 1520 
BFD Liveliness Detection | 1520 
inherit-label-nexthops | 1521 


Auto-Translate Feature | 1521 


Weights Associated With Paths of an SRTE Policy 


You can configure weights against computed and static SRTE paths, which contribute to the next hops of 
the route. However, a single path that has computation enabled can result in multiple segment lists. These 
computed segment lists are treated as ECMP amongst themselves. You can assign hierarchical ECMP 
weights to these segments, considering the weights assigned to each of the configured primaries. 


BFD Liveliness Detection 


You can configure BFD liveliness detection for the computed primary or secondary paths. Every computed 
primary or secondary path can result in multiple segment lists, as a result, the BFD parameters configured 
against the segment lists are applied to all the computed segment lists. If all the active primary paths go 
down, the pre-programmed secondary path (if provided) becomes active. 


inherit-label-nexthops 


You are not required to explicitly enable the inherit-label-nexthops configuration under the [edit protocols 
source-packet-routing segment-list segment-list-name] hierarchy for the computed primary or secondary 
paths, as it is a default behavior. 


Auto-Translate Feature 


You can configure the auto-translate feature on the segment lists, and the primary or secondary paths 
with the auto-translate feature reference these segment lists. On the other hand, the primary or secondary 
on which compute feature is enabled cannot reference any segment list. As a result, you cannot enable 
both the compute feature and the auto-translate feature for a given primary or secondary path. However, 
you could have an LSP configured with a primary path with compute type and another with auto-translate 
type. 


Distributed CSPF Computation Sample Configurations 


IN THIS SECTION 


@ Example 1 | 1521 
@ Example 2 | 1522 
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Example 1 


In Example 1, 


e The non-computed primary path references a configured segment-list. In this example, the configured 
segment list static_sl1 is referenced, and it also serves as the name for this primary path. 


e Acomputed primary should have a name configured, and this name should not reference any configured 
segment list. In this example, compute_segment1 is not a configured segment list. 


e The compute_profile_red compute-profile is applied to the primary path with the name compute_segment1. 


e The compute_profile_red compute-profile includes a segment list of type compute, which is used to 
specify the explicit path constraint for the computation. 


[edit protocols source-packet-routing] 
segment-list static_sI1{ 
hop1 label 80000 
} 
segment-list exp_path1 { 
hop1 ip-address 10.1.1.1 loose 
hop2 ip-address 2.2.2.2 


1521 


1522 


compute 

} 

compute-profile compute_profile_red { 
include-any red 
segment-list exp_path1 
maximum-segment-list-depth 5 


The weights for computed path next-hops and static next-hops are 2 and 3, respectively. Assuming the 
next-hops for computed paths are comp_nh1, comp_nh2, and comp_nh3, and the next-hop for static path 
is static_nh, the weights are applied as follows: 


Next-Hop Weight 

comp_nh1 2 

comp_nh2 2 

comp_nh3 2 

static_nh 9 
Example 2 


In Example 2, both the primary and secondary paths can be of compute type and can have their own 
compute-profiles. 


[edit protocols source-packet-routing] 

compute-profile compute_profile_greenf{ 
include-any green 
maximum-segment-list-depth 5 

} 

compute-profile compute_profile_red{ 
include-any red 
maximum-segment-list-depth 8 


Example 3 


In Example 3, when compute is mentioned under a primary or secondary path, it results in local computation 
of a path to the destination without any constraints or other parameters for the computation. 


[edit protocols source-packet-routing] 
source-routing-path srte_colored_policy1 { 
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to 5.5.5.5 
color 5 
binding-sid 10001 
primary { 
compute_segment1 { 
compute 


Example: Configuring CoS-Based Forwarding and Policy-Based Routing For SR-TE LSPs 


SUMMARY IN THIS SECTION 


@  CoS-Based Forwarding and Policy-Based 
CoS-based forwarding (CBF) and policy-based routing Routing For SR-TE LSPs Overview | 1523 
(PBR, also known as filter-based forwarding) can be 


enabled for non-colored segment routing-traffic 
engineered (SR-TE) LSPs to steer selective traffic over 
an explicit SR-TE path, providing you the benefit of 
servicing traffic based on class-of-service or a policy. 


® Configure CoS-Based Forwarding and 
Policy-Based Routing for SR-TE LSPs | 1524 


CoS-Based Forwarding and Policy-Based Routing For SR-TE LSPs Overview 


IN THIS SECTION 


@ Benefits of CoS-Based Forwarding (CBF) and Policy-Based Routing (PBR) For SR-TE LSPs | 1523 
@ Segment Routing Path Sources Supporting CBF and PBR | 1524 
® Considerations for Configuring CBF and PBR for SR-TE LSPs | 1524 


Benefits of CoS-Based Forwarding (CBF) and Policy-Based Routing (PBR) For SR-TE LSPs 
With CBF and PBR you can: 


e Use combinations of segment routing-traffic engineering (SR-TE) paths to steer service traffic in the 
core. 
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e Choose the supporting services to resolve over the selected SR-TE paths. 


Segment Routing Path Sources Supporting CBF and PBR 


The following segment routing path sources support CoS-based forwarding and policy-based routing: 


e Static SR-TE paths—Statically configured source-routing paths that have the entire label stack statically 
configured. 


e PCEP—Dynamically provisioning source-routing paths created on a controller, and downloaded to an 
ingress router in an ERO either through PCEP segment routing extensions, or ina BGP segment routing 
policy through BGP segment routing extensions. 


e Dynamic LSPs—Dynamically created tunnels triggered through the Dynamic Tunnel Module that have 
last-hop ERO resolution. 


e Auto-translated paths—Statically configured source-routing paths that are automatically translated. 


Considerations for Configuring CBF and PBR for SR-TE LSPs 


Remember: 


e CBF and PBR is enabled only on non-colored SR-TE LSPs that are either statically or dynamically 
configured. 


e Both CBF and PBR configurations for SR-TE LSPs can co-exist on a device; the order of configuration 
decides the type in which the routes are forwarded. 


e For PBR, if the first-hop of the SR-TE LSP is a label, then you must include the resolution 
preserve-nexthop-hiearchy statement at the [edit routing-options] hierarchy level. 


e The class-based forwarding of routes for CBF is visible only in the forwarding table and not on the routes. 
e The policy-based forwarding of routes for PBR is done on the routes and is seen in the show route 


command output. 


Configure CoS-Based Forwarding and Policy-Based Routing for SR-TE LSPs 


SUMMARY 


CoS-based forwarding (CBF) and policy-based routing (PBR, also known as filter-based forwarding 
FBF) can be used to steer selective traffic using an explicit segment routing-traffic engineered (SR-TE) 
label-swtiched path (LSP). Only non-colored segment routing LSPs that have the next hop configured 
as first hop label or IP address support CBF and PBR. 


Before You Begin 


e You must be running Junos OS Release 20.1 and later releases to enable CBF and PBR for non-colored 
SR-TE LSPs. 


e Configure the device interfaces and ensure the devices are connected to the network. 


e Define segment lists and configure SR-TE LSPs and their associated parameters. 
To configure an SR-TE LSP, do the following: 


1. Define the segment list with label parameters. 


[edit protocol] 
user@host# set source-packet-routing segment-list segment-list-name hop-name ip-address ip-address 
user@host# set source-packet-routing segment-list segment-list-name hop-name label number 


For example: 


[edit protocol] 

user@host# set source-packet-routing segment-list sr1 hop1 ip-address 11.1.1.2 
user@host# set source-packet-routing segment-list sr1 hop2 label 801002 
user@host# set source-packet-routing segment-list sr1 hop3 label 801003 
user@host# set source-packet-routing segment-list sr1 hop4 label 801007 
user@host# set source-packet-routing segment-list sr1 hop1 ip-address 11.1.1.2 
user@host# set source-packet-routing segment-list sr1 hop2 label 801002 
user@host# set source-packet-routing segment-list sr1 hop3 label 801003 
user@host# set source-packet-routing segment-list sr1 hop4 label 801007 
user@host# set source-packet-routing segment-list sr2 hop1 ip-address 11.11.1.2 
user@host# set source-packet-routing segment-list sr2 hop2 label 801002 
user@host# set source-packet-routing segment-list sr2 hop3 label 801003 
user@host# set source-packet-routing segment-list sr2 hop4 label 801007 
user@host# set source-packet-routing segment-list sr3 hop1 ip-address 11.12.1.2 
user@host# set source-packet-routing segment-list sr3 hop2 label 801002 
user@host# set source-packet-routing segment-list sr3 hop3 label 801003 
user@host# set source-packet-routing segment-list sr3 hop4 label 801007 
user@host# set source-packet-routing segment-list sr4 hop1 ip-address 11.13.1.2 
user@host# set source-packet-routing segment-list sr4 hop2 label 801002 
user@host# set source-packet-routing segment-list sr4 hop3 label 801003 
user@host# set source-packet-routing segment-list sr4 hop4 label 801007 


2. Configure the source-routing path for the SR-TE LSPs and specify the preference value and primary 
segment for the path. 


[edit protocols] 
user@host# set source-packet-routing source-routing-path source-routing-path-name to destination-ip-address 
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user@host# set source-packet-routing source-routing-path source-routing-path-name preference preference 
user@host# set source-packet-routing source-routing-path source-routing-path-name primary primary-segment 


For example: 


[edit protocols] 

user@host# set source-packet-routing source-routing-path srtelsp1 to 7.7.7.7 
user@host# set source-packet-routing source-routing-path srtelsp1 preference 1 
user@host# set source-packet-routing source-routing-path srtelsp1 primary sr1 
user@host# set source-packet-routing source-routing-path srtelsp2 to 7.7.7.7 
user@host# set source-packet-routing source-routing-path srtelsp2 preference 1 
user@host# set source-packet-routing source-routing-path srtelsp2 primary sr2 
user@host# set source-packet-routing source-routing-path srtelsp3 to 7.7.7.7 
user@host# set source-packet-routing source-routing-path srtelsp3 preference 1 
user@host# set source-packet-routing source-routing-path srtelsp3 primary sr3 
user@host# set source-packet-routing source-routing-path srtelsp4 to 7.7.7.7 
user@host# set source-packet-routing source-routing-path srtelsp4 preference 1 
user@host# set source-packet-routing source-routing-path srtelsp4 primary sr4 


You can now configure CBF and PBR for the configured SR-TE LSPs. 
To configure CBF, do the following 


1. Define Differentiated Services Code Point (DSCP) classifiers to handle incoming IPv4 packets, forwarding 
classes, and option values. 


[edit class-of-service] 
user@host# set classifiers dscpclassifier-name forwarding-class forwarding-class-name loss-priority level 
code-points [ aliases ] [ 6 bit-patterns ] 


For example: 


[edit class-of-service] 

user@host# set classifiers dscp mydscp forwarding-class af11 loss-priority low code-points 001010 
user@host# set classifiers dscp mydscp forwarding-class af11 loss-priority medium-high code-points 001100 
user@host# set classifiers dscp mydscp forwarding-class af11 loss-priority high code-points 001110 
user@host# set classifiers dscp mydscp forwarding-class af21 loss-priority low code-points 010010 
user@host# set classifiers dscp mydscp forwarding-class af21 loss-priority medium-high code-points 010100 
user@host# set classifiers dscp mydscp forwarding-class af21 loss-priority high code-points 010110 
user@host# set classifiers dscp mydscp forwarding-class af31 loss-priority low code-points 011010 
user@host# set classifiers dscp mydscp forwarding-class af31 loss-priority medium-high code-points 011100 
user@host# set classifiers dscp mydscp forwarding-class af31 loss-priority high code-points 011110 
user@host# set classifiers dscp mydscp forwarding-class af41 loss-priority low code-points 100010 
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user@host# set classifiers dscp mydscp forwarding-class af41 loss-priority medium-high code-points 100100 
user@host# set classifiers dscp mydscp forwarding-class af41 loss-priority high code-points 100110 


2. Define forwarding classes (FCs) for grouping packets for transmission, and assign packets to output 
queues. 


[edit class-of-service] 
user@host# set forwarding-classes queue queue-numner class-name 


For example: 


[edit class-of-service] 

user@host# set forwarding-classes queue O af11 
user@host# set forwarding-classes queue 1 af21 
user@host# set forwarding-classes queue 2 af31 
user@host# set forwarding-classes queue 3 af41 


3. Assign the configured classifiers to the device interfaces. 


[edit class-of-service] 
user@host# set interfaces interface-name unit unit classifiers dscp classifier-name 


For example: 


[edit class-of-service] 
user@host# set interfaces ge-0/0/8 unit 1 classifiers dscp mydscp 
user@host# set interfaces ge-0/0/8 unit 2 classifiers dscp mydscp 


4. Define CoS-based forwarding policy options with LSP next-hop as the SR-TE LSP. 


[edit class-of-service] 
user@host# set forwarding-policy next-hop-map map-name forwarding-classes class-name Isp-next-hop 
source-routing-path-name 


For example: 


[edit class-of-service] 

user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af11 Isp-next-hop srtelsp1 
user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af21 Isp-next-hop srtelsp2 
user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af41 Isp-next-hop srtelsp3 
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user@host# set forwarding-policy next-hop-map my_cbf forwarding-class af31 Isp-next-hop srtelsp4 


5. Discard traffic that does not meet any forwarding class in the next-hop map. 


[edit class-of-service] 
user@host# set forwarding-policy next-hop-map map-name forwarding-class-default discard 


For example: 


[edit class-of-service] 
user@host# set forwarding-policy next-hop-map my_cbf forwarding-class-default discard 


6. Configure a policy statement that specifies that routes matching the route filter are subject to the CoS 
next-hop mapping specified by map-name. 


[edit policy-options] 
user@host# set policy-statement policy-name from route-filter destination-prefix match-type <actions> 
user@host# set policy-statement policy-name then cos-next-hop-map map-name 
For example: 
[edit policy-options] 


user@host# set policy-statement cbf from route-filter 4.0.0.1/16 orlonger 
user@host# set policy-statement cbf then cos-next-hop-map my_cbf 


7. Apply the policy to routes being exported from the routing table into the forwarding table. This enables 
CBF for SR-TE LSPs. 


[edit routing-options] 
user@host# set forwarding-table export policy-name 


For example: 


[edit routing-options] 
user@host# set forwarding-table export cbf 


8. Commit the configuration. 


user@host# commit 


Verify CBF Configuration 


You can verify the CBF configuration using the show route forwarding-table destination ip-address vpn 


vpn-name extensive command. 


user@host> show route forwarding-table destination 4.0.0.1 vpn vpn1 extensive 


Routing table: vpnl.inet [Index 8] 
Tie Siemens 

DSsicimemenomas 4,0 .0,1/382 

RoutSs type; weer 

Route reference: 0 


Multicast RPF nh index: 0 





P2mpidx: 0 


Flags: sent to PFE 

Next-hop type: indirect 

Next—-hop type: indexed 

Route type: idx:0 

Nessclnees Iii, t,t .2 

Next—-hop type: Push 296, Push 801007, 


Reference: 1 








Route interface-index: 0 


Index: 1048579 Reference: 10001 
Index: 837 Reference: 2 

Load Balance Label: None 

Next-hop interface: ge-0/0/1.1 

Route type: idx:1 

excess iis iil, l.2 

Next—-hop type: Push 296, Push 801007, 


Iyer ts}(0) ILO) S),, 


Push 801003, 


Push 801002 (top) Index: 807 


Push 801002 (top) Index: 809 


For CBF, the class-based forwarding of routes is visible only in the forwarding table, unlike PBR, where 


the filtered routes are visible in the show route command output. 


To configure PBR, do the following 


1. Configure a policy statement which specifies that routes matching the protocol and route filter are 
subject to the LSP next-hop, or are load balanced as equal-cost multipath (ECMP) in the forwarding 


table. 


[edit policy-options] 
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user@host# set policy-statement policy-name from protocol protocol-name 

user@host# set policy-statement policy-name from route-filter destination-prefix match-type <actions> 
user@host# set policy-statement policy-name then install-nexthop Isp Isp-name 

user@host# set policy-statement policy-name then load-balance per-packet 


For example: 
[edit policy-options] 
user@host# set policy-statement pbr term 1 from protocol bgp 
user@host# set policy-statement pbr term 1 from route-filter 4.0.0.1/32 exact 
user@host# set policy-statement pbr term 1 then install-nexthop Isp srtelsp1 


user@host# set policy-statement pbr term 1 then load-balance per-packet 
user@host# set policy-statement pbr term 1 then reject 


2. Configure the device to perform custom route resolution on protocol next hops of routes. 


NOTE: The resolution preserve-nexthop-hierarchy statement is mandatory for PBR to work 
when the first-hop of the SR-TE LSP is a label. 


[edit routing-options] 
user@host# set resolution preserve-nexthop-hierarchy 


3. Apply the policy to routes being exported from the routing table into the forwarding table. This enables 
PBR for SR-TE LSPs. 


[edit routing-options] 
user@host# set forwarding-table export policy-name 


For example: 


[edit routing-options] 
user@host# set forwarding-table export pbr 


4. Commit the configuration. 


user@host# commit 
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Verify PBR Configuration 


You can verify the PBR configuration using the show route destination-prefix command. 


user@host> show route 4.0.0.1 


vpnl.inet.0: 10003 destinations, 10003 routes (10003 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


Al 0.10. Lf 32 [ES /LIO| OORza4si2, ikeesilioieese 100, seo Wo 75 7ad 
AS path: 10 I, validation-state: unverified 
e@ iil ,l.i,2 wie ge-O/0/il.1, Busia SOSES, Pusin GOLOOT, Pusin 


801003, Push 801002 (top) 
> co lil, dl, wie ee-O/0/1.2%, Busia SOIBS, Buisin SOOO, Puisin 


801003, Push 801002 (top) 
fo 1,2 1A wae Gas-O/O/il.s, Pisin SOVSS, Puisin SOIOO7, irwisiln 


801003, Push 801002 (top) 
eo Lil IS .1.2 waa ge-O/O/i,4, Pusin 50983, Pusin SOIOOI, Pusia 


801003, Push 801002 (top) 











user@host> show route 4.0.0.1 expanded-nh extensive 


vpnl.inet.0: 10003 destinations, 10003 routes (10003 active, 0 holddown, 0 hidden) 
AR OR Onell o un Clan c intents; ae leercinn omine ec) 
Installed-nexthop: 
imeke (O<ejeeas#) 7.7.7.7 PBwsian HOMES SSSsio@m—IDS OWscil@ie 
Keeic iia (OxweV74 basa) iincleses OAS 7S) wists 7.7.7.7 
Chain (Oxc7aa798) Index:823 Push 50983 

Router (0xc417034) 11.1.1.2 Push 801007, Push 801003, Push 801002(top) via 

ge-0/0/1.1 


The output displays all next-hops for the destination prefix, 4.0.0.1. The expanded-nh extensive options 
displays the filtered next-hops under the Krt_inh output field. 


user@host> show route 4.0.0.2 


vpnl.inet.0: 10003 destinations, 10003 routes (10003 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


AN ORO. 2/7 32 =[XES/LIO] OOSSOsi4, leealjorat 100, trom 7. 7aoF 
AS path: 10 I, validation-state: unverified 
eG Lil, .l.2 wia ge-O/Of/l.i, Pwsin S69, PUSin SOLOOT, Pusia 





801003, Push 801 


SOTO OS eeusinec Opl 


801003, Push 801 


801003, Push 801 





002 ( 


002 ( 


002 ( 


002 ( 
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top) 
S t© 11,11,1,.2 wa ge-0/0/1.2, Busia 569, Pusin SOLOOT, Puen 
top) 
©@ L112 ,1.2 wie Ge-0/0/1.3, Pugin 569, Pusia BOLOOT, Piwsila 


top) 
ico) Wi, 2 wie eS-O/O/il.3, Pusin BOY, Duisin SOMOOW, wiwisile 
top) 





user@host> show route 7.7.7.7 protocol spring-te 


inet.0: 10082 destinations, 10119 routes (10082 active, 0 holddown, 0O hidden) 


dime SS 25 cClasiciinaicdems, 77 iwowces 


+ = Active Rout 


(25 active, 0 holddown, O hidden) 
Last Active, * = Both 








Tato to tl S2 
801002 (top) 
801002 (top) 
801002 (top) 
801002 (top) 





, 


* 





[SPRING-TE/1] 00:00:32, metric 1, metric2 4 
> ico li l.,1.4 wie ce-O/O/l.1, Busia SOLOO7, Puisin SOMOOS, Iisa 


cOQ Mili, .2 wia ce-0/O/1.2, Pusin SOLOO7T, Pusin SOLOOS, Mmsia 


cO@ M1 .I2.1.2 wie Ge-O/O/1l.s, Pusin BOLOOT, Pmsin SOLOOS, Busia 








GQ Li,l7,1.2 wie Ge-O/O/l.~S, Pusin SOIOO7, Pwisl SONOOS, wisn 


For PBR the show route command output does the policy-based filtering of routes. 


Release History Table 


Release 


20.2R1 


19.4R1 


19.4R1 


79. URL 


19.1R1 


18.2R1 


17,21 


16.1 


16.1 


14.2R4 


Description 


Starting in Junos OS Release 20.2R1, BGP Labeled Unicast (BGP-LU) can resolve IPv4 and IPv6é 
routes over IPv4 and IPvé segment routing-traffic engineering (SR-TE) tunnels. 


You can associate a single or range of MVPN multicast flows (S,G) to a dynamically created 
PCE-initiated point-to-multipoint label-switched path (LSP). 


You can configure a tunnel template for PCE-initiated segment routing LSPs to pass down two 
additional parameters for these LSPs - Bidirectional forwarding detection (BFD) and LDP tunneling. 


Starting in Junos OS Release 19.1R1, a commit check feature is introduced to ensure that all the 
segment lists contributing to the colored routes have the minimum label present for all hops. 


Starting in Junos OS Release 19.1R1, this requirement does not apply, as the first hop of the 
non-colored static LSPs now provides support for SID labels, in addition to IP addresses. With 
the first hop label support, MPLS fast reroute (FRR) and weighted equal-cost multipath is enabled 
for resolving the static non-colored segment routing LSPs, similar to colored static LSPs. 


Starting in Junos OS Release 18.2R1, statically configured non-colored segment routing LSPs on 
the ingress device are reported to the Path Computation Element (PCE) through a Path Computation 
Element Protocol (PCEP) session. 


Starting in Junos OS Release 17.2, in addition to external cspf, two new path computation types 
are introduced for the PCE-controlled LSPs: local cspf and no cspf. 


Starting with Junos OS Release 16.1, you can secure a PCEP session using TCP-MD5 authentication 
as per RFC 5440. 


Junos OS Release 16.1 introduces the feature of securing a PCEP session using TCP-MD5 
authentication as per RFC 5440. 


Starting in Junos OS Release 14.2R4, support of auto-bandwidth is provided for PCE-controlled 
LSPs. 
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Verify MPLS Interfaces 


Purpose 


If the MPLS protocol is not configured correctly on the routers in your network, the interfaces are not 
able to perform MPLS switching. 


NOTE: For a labeled route to be resolved over an interface, family mpls must be configured at 
the [edit interfaces] hierarchy level for the route to be successfully resolved. When the interface 
is not configured with family mpls, labelled routes do not get resolved. 


Action 


To verify MPLS interfaces, enter the following Junos OS command-line interface (CLI) operational mode 
command: 


user@host> show mpls interface 


Sample Output 1 


The following sample output is for all routers in the network shown in MPLS Network Topology. 


user@R1> show mpls interface 


Interface State Administrative groups 
so-0/0/0.0 Up <none> 
SO 0/10/10) Up <none> 
so-0/0/2.0 Up <none> 


user@R2> show mpls interface 


Interface State Administrative groups 
so-0/0/0.0 Up <none> 
so-0/0/1.0 Up <none> 


so-0/0/2.0 Up <none> 


so-0/0/3.0 Up 


user@R3> show mpls interface 


Interface State 
so-0/0/0.0 Up 
so-0/0/1.0 Up 
so-0/0/2.0 Up 
so-0/0/3.0 Up 


user@R4> show mpls interface 


Interface State 
so-0/0/0.0 Up 
so-0/0/1.0 Up 
so-0/0/2.0 Up 
so-0/0/3.0 Up 


user@R5> show mpls interface 


Interface State 
so-0/0/0.0 Up 
so-0/0/1.0 Up 
so-0/0/2.0 Up 


user@R6> show mpls interface 


Interface State 
so-0/0/0.0 Up 
so-0/0/1.0 Up 
so-0/0/2.0 Up 
SO= 0/107 2er0 Up 


| Sample Output 2 


user@R6> show mpls interface 


Interface State 
so-0/0/0.0 Up 
Sm 0/10} lee 0) Up 


so-0/0/3.0 Up 


<none> 


Administrative groups 
<none> 
<none> 
<none> 


<none> 


Administrative groups 
<none> 
<none> 
<none> 


<none> 


Administrative groups 
<none> 
<none> 


<none> 


Administrative groups 
<none> 
<none> 
<none> 


<none> 


Administrative groups 
<none> 


<none> 


<none> # so-0/0/2.0 is missing 
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| Sample Output 3 


user@host> show mpls interface 


MPLS not configured 


Meaning 

Sample Output 1 shows that all MPLS interfaces on all routers in the network are enabled (Up) and can 
perform MPLS switching. If you fail to configure the correct interface at the [edit protocols mpls] hierarchy 
level or include the family mpls statement at the [edit interfaces type-fpc/pic/port unit number | hierarchy 
level, the interface cannot perform MPLS switching, and does not appear in the output for the show mpls 
interface command. 


Administrative groups are not configured on any of the interfaces shown in the example network in MPLS 
Network Topology. However, if they were, the output would indicate which affinity class bits are enabled 
on the router. 


Sample Output 2 shows that interface so-0/0/2.0 is missing and therefore might be incorrectly configured. 
For example, the interface might not be included at the [edit protocols mpls] hierarchy level, or the family 
mpls statement might not be included at the [edit interfaces type-fpc/pic/port unit number] hierarchy 
level. If the interface is configured correctly, RSVP might not have signaled over this interface yet. For 
more information on determining which interface is incorrectly configured, see Verify Protocol Families. 


Sample Output 3 shows that the MPLS protocol is not configured at the [edit protocols mpls] hierarchy 
level. 


Verify the MPLS Configuration 


Purpose 

After you have checked the transit and ingress routers, use the traceroute command to verify the BGP 
next hop, and used the ping command to verify the active path, you can check for problems with the MPLS 
configuration at the [edit protocols mpls] and [edit interfaces] hierarchy levels. 


NOTE: For a labeled route to be resolved over an interface, family mpls must be configured at 
the [edit interfaces] hierarchy level for the route to be successfully resolved. When the interface 
is not configured with family mpls, labelled routes do not get resolved. 


Action 


To verify the MPLS configuration, enter the following commands from the ingress, transit, and egress 
routers: 
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user@host> show configuration protocols mpls 
user@host> show configuration interfaces 


| Sample Output 1 


user@R1> show configuration protocols mpls 
label-switched-path R1-to-R6é { 

mor VOL OL 
} 


inactive: interface so-0/0/0.0; 








inactive: interface so-0/0/1.0; 
interface so-0/0/2.0; 
interface fxp0.0 { 

disable; 


user@R3> show configuration protocols mpls 
interface fxp0.0 { 

disable; 
} 


inactive: interface so-0/0/0.0; 








inactive: interface so-0/0/1.0; 
interface so-0/0/2.0; 
interface so-0/0/3.0; 


user@R6> show configuration protocols mpls 
label-switched-path R6-to-R1 { 
co O00. i 





inactive: interface so-0/0/0. 


~ 





inactive: interface so-0/0/1. 





inactive: interface so-0/0/2. 








eo ZS S&S S&S 


inactive: interface so-0/0/3.0; <<< Incorrectly configured 
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Sample Output 2 


user@R6> show configuration interfaces 
so-0/0/0 { 
winasice O 4 
family inet { 
access 10,1, 56,2/ 308 
} 
family iso; 


family mpls; 


} 
so-0/0/1 { 
Binaic 0 tf 
family inet { 
aclizess 10. 1.,45,2/ 30% 
} 
family iso; 


family mpls; 


} 
SOs 0/0/24 
unit O { 
family inet { 
access 10,1, 26.2/ 30% 
} 
family iso; 


family mpls; 


} 
So = 0/0/sme 
winaie O ff 
family inet { 
across WO.1.,36,2/ 30s 
} 
family iso; 


family mpls; 


} 
fxpod { 
winwic O 4 
family inet { 
address 192.168.70.148/21; 


} 


1o0 { 
Dinaic O 
family inet { 
ac Gisecismell Om OmOnioeser 
access 127.050, 1/325 
} 
family iso { 
address 49.0003.1000.0000.0006.00; 
} 
} 
} 
Meaning 


Sample Output 1 from the ingress, transit, and egress routers shows that the configuration of interfaces 
on egress router R6 is incorrect. Interface so-0/0/3.0 is included as inactive at the [edit protocols mpls] 
hierarchy level, when it should be active because it is the interface through which the LSP travels. 


Sample Output 2 shows that interfaces are correctly configured for MPLS on egress router R6. The 
interfaces are also correctly configured on the ingress and transit routers (not shown). 


Checking the MPLS Layer 


Purpose 

After you have configured the label-switched path (LSP), issued the show mpls Isp command, and determined 
that there is an error, you might find that the error is not in the physical, data link, Internet Protocol (IP), 

interior gateway protocol (IGP), or Resource Reservation Protocol (RSVP) layers. Continue investigating 

the problem at the MPLS layer of the network. 


Figure 126 on page 1542 illustrates the MPLS layer of the layered MPLS model. 
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Figure 126: Checking the MPLS Layer 
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. show interfaces 
Physical Layer show interfaces terse 
ping host 


015547 











With the MPLS layer, you check whether the LSP is up and functioning correctly. If the network is not 
functioning at this layer, the LSP does not work as configured. 


Figure 127 on page 1542 illustrates the MPLS network used in this topic. 


Figure 127: MPLS Network Broken at the MPLS Layer 
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The network shown in Figure 127 on page 1542 is a fully meshed configuration where every directly connected 
interface can receive and send packets to every other similar interface. The LSP in this network is configured 
to run from ingress router R1, through transit router R3, to egress router R6. In addition, a reverse LSP is 
configured to run from R6 through R3 to R1, creating bidirectional traffic. 


However, in this example, the reverse LSP is down without a path from R6 to R1. 


The cross shown in Figure 127 on page 1542 indicates where the LSP is broken. Some possible reasons the 
LSP is broken might include an incorrectly configured MPLS protocol, or interfaces that are incorrectly 
configured for MPLS. 


In the network shown in Figure 127 on page 1542, a configuration error on egress router R6 prevents the 
LSP from traversing the network as expected. 


To check the MPLS layer, follow these steps: 


1. Verify the LSP | 1543 

2. Verify the LSP Route on the Transit Router | 1547 

3. Verify the LSP Route on the Ingress Router | 1549 

4. Verify MPLS Labels with the traceroute Command | 1551 
5. Verify MPLS Labels with the ping Command | 1552 

6. Take Appropriate Action | 1554 

7. Verify the LSP Again | 1555 


Verify the LSP 


Purpose 

Typically, you use the show mpls Isp extensive command to verify the LSP. However for quick verification 
of the LSP state, use the show mpls Isp command. If the LSP is down, use the extensive option (show mpls 
Isp extensive) as a follow-up. If your network has numerous LSPs, you might consider specifying the name 
of the LSP, using the name option (show mpls Isp name name or show mpls Isp name _ name extensive). 


Action 


To verify that the LSP is up, enter some or all of the following commands from the ingress router: 


user@host> show mpls Isp 

user@host> show mpls Isp extensive 
user@host> show mpls Isp name name 
user@host> show mpls Isp name name extensive 
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Sample Output 1 


user@R1> show mpls Isp 
Ingress LSP: 1 sessions 


fe) From State Re Actinerat a P LSPname 
OPO RI Oro OPO RO ne! Dn 0 - R1-to-R6 





Total 1 displayed, Up 0, Downi1 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


user@R3> show mpls Isp 
Ingress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 
Total 0 displayed, Up 0, Down 0 


user@R6> show mpls Isp 

Ingress LSP: 1 sessions 

To From State Rt ActivePath iB LSPname 
10.0.0.2 NORIO RN Ora6 Dn @ = R6-to-R1 





Total 1 displayed, Up 0, Downi1 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 
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| Sample Output 2 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


NOFA Or Oren© 
From: 10.0.0.1, State: Dn, ActiveRoute: 0, LSPname: Ril-to-R6 
ActivePath: (none) 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





Primary State: Dn 
Will be enqueued for recomputation in 22 second(s). 
1 Nov 2 14:43:38 CSPF failed: no route toward 10.0.0.6 [175 times] 
Created: Tue Nov 2 13:18:39 2004 

Total 1 displayed, Up 0, Down 1 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


user@R3> show mpls Isp extensive 
Ingress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


user@R6> show mpls Isp extensive 


Ingress LSP: 1 sessions 


10.0502 
From: 10.0.0.6, State: Dn, ActiveRoute: 0, LSPname: R6-to-R1 
ActivePath: (none) 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





Primary State: Dn 
Will be enqueued for recomputation in 13 second(s). 


1 Nov 2 14:38:12  CSPF failed: no route toward 10.0.0.1 [177 times] 
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Created: Tue Nov 2 13:12:22 2004 
Total 1 displayed, Up 0, Down 1 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


| Sample Output 3 


user@R1> show mpls Isp name R1-to-R6 
Ingress LSP: 1 sessions 


fe) From State Rt ActivePath P LSPname 
OPO OG 10.0.0. i Dn Q = R1-to-R6 





Total 1 displayed, Up 0, Down 1 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


| Sample Output 4 


user@R1> show mpls Isp name R1-to-R6 extensive 


Ingress LSP: 1 sessions 


tO RIOR ORuG 
From: 10.0.0.1, State: Dn, ActiveRoute: 0, LSPname: R1l-to-R6 
ActivePath: (none) 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





Primary State: Dn 
Will be enqueued for recomputation in 10 second(s). 
1 Nov 2 14:51:53 CSPF failed: no route toward 10.0.0.6/192 times] 


Created: Tue Nov 2 13:18:39 2004 
Total 1 displayed, Up 0, Down 1 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 


Sample Output 1 shows a brief description of the state of the LSP for the ingress, transit, and egress 
routers. Output from ingress router R1 and egress router R6 shows that both LSPs are down, R1-to-R6 
and R6-toR1. With the configured LSPs on R1 and R6, we would expect egress LSP sessions on both R1 
and Ré. In addition, transit router R3 has no transit sessions. 


Sample Output 2 shows all information about the LSPs, including all past state history and the reason why 
an LSP failed. Output from R1 and Ré6 indicates that there is no route to the destination because the 
Constrained Shortest Path First (CSPF) algorithm failed. 


Sample Outputs 3 and 4 show examples of the output for the show mpls Isp name command with the 
extensive option. In this instance, the output is very similar to the show mpls Isp command because only 
one LSP is configured in the example network in “MPLS Network Broken at the MPLS Layer” on page 1542. 
However, in a large network with many LSPs configured, the results would be quite different between the 
two commands. 


Verify the LSP Route on the Transit Router 


Purpose 


If the LSP is up, the LSP route should appear in the mpls.0O routing table. MPLS maintains an MPLS path 
routing table (mpls.0), which contains a list of the next label-switched router in each LSP. This routing table 
is used on transit routers to route packets to the next router along an LSP. If routes are not present in the 
output for the transit router, check the MPLS protocol configuration on the ingress and egress routers. 


Action 


To verify the LSP route on the transit router, enter the following command from the transit router: 


user@host> show route table mpls.0 


Sample Output 1 


user@R3> show route table mpls.0 
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mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) 











+ = Active Route, Last Active, * = Both 

0 *[MPLS/0] 16w2d 21:52:40, metric 1 
Receive 

i A (MP LS/ 0) Mow2id 27:52 740) metric il 
Receive 

2 *([MPLS/0] 16w2d 21:52:40, metric 1 
Receive 





| Sample Output 2 


user@R3> show route table mpls.0O 


mpls.0: 7 destinations, 7 routes (7 active, 0 holddown, O hidden) 





























+ = Active Route, Last Active, * = Both 
0 *[MPLS/0] 16w2d 22:26:08, metric 1 
Receive 
alg *[MPLS/0] 16w2d 22:26:08, metric 1 
Receive 
Z = MELS/ CO] owecl 22gA2Gr0, imeiereske iL 
Receive 
100864 “PRSWe2/ 7] OOsO7E23, meicee i 
> via so-0/0/2.0, label-switched-path R6-to-R1 
100864 (S=0) “RSW 7] WOOsO7s23, aieieieie 1 
> via so-0/0/2.0, label-switched-path R6-to-R1 
100880 “(RSWe/ 7 OCOsO7sOLl, meaiereie i 
> via so-0/0/3.0, label-switched-path R1-to-R6 
100880 (S=0) H([RSW2/ 7 OCOsO7sOl, meaicreie i 
> via so-0/0/3.0, label-switched-path R1-to-R6 




















Meaning 


Sample Output 1 from transit router R3 shows three route entries in the form of MPLS label entries. These 
MPLS labels are reserved MPLS labels defined in RFC 3032, and are always present in the mpls.0 routing 
table, regardless of the state of the LSP. The incoming labels assigned by RSVP to the upstream neighbor 
are missing from the output, indicating that the LSP is down. For more information on MPLS label entries, 
see Checklist for Verifying LSP Use. 


In contrast, Sample Output 2 shows the MPLS labels and routes for a correctly configured LSP. The three 
reserved MPLS labels are present, and the four other entries represent the incoming labels assigned by 
RSVP to the upstream neighbor. These four entries represent two routes. There are two entries per route 
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because the stack values in the MPLS header may be different. For each route, the second entry 100864 
(S=0) and 100880 (S=0) indicates that the stack depth is not 1, and additional label values are included in 
the packet. In contrast, the first entry, 100864 and 100880 has an inferred S=1 value which indicates a 
stack depth of 1 and makes each label the last label in that particular packet. The dual entries indicate that 
this is the penultimate router. For more information on MPLS label stacking, see RFC 3032, MPLS Label 
Stack Encoding. 


Verify the LSP Route on the Ingress Router 


Purpose 
Check whether the LSP route is included in the active entries in the inet.3 routing table for the specified 
address. 


Action 


To verify the LSP route, enter the following command from the ingress router: 


user@host> show route destination 


Sample Output 1 


user@R1> show route 10.0.0.6 


inet.O : 27 destinations, 27 routes (27 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 
NO PORIORTGH/se2 *(IS=1S/ isi Sel Ols4iss7, wmesicwie 20 
tO IO,1,12.2 waa so-0/0/0.0 
Ste lO ,1,15.2 Wa so-0/0/i1.0 
tO IO,1,18.2 waa so-0/0/2.0 


user@R6> show route 10.0.0.1 


inet.O : 28 destinations, 28 routes (28 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 
1@.0,.0,1/32 “([IS=-1S/1S] Sel OleOilsgse, macere 20 
EG IM 51,56,1 Wie so-0/0/0.0 
SitO 0,126.1 wa so-0/0/2.0 
EG LM .1 36.1 Wa soO-0/0/3.0 
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| Sample Output 2 


user@R1> show route 10.0.0.6 


inet.0: 28 destinations, 28 routes (27 active, 0 holddown, 1 hidden) 








+ = Active Route, Last Active, * = Both 


OPO Orcy 3 “[IS=$1S/ is] cl O26i13s42, imeaciene 20 
c© IO,1,12.2 wia so-0/0/0.0) 
Sto 10,1,15,.2 wa so-0/0/i1.0 
tO IO ,1,18,.2 waa so-0/0/2.0 


inet.3 : 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 


LO PAOR OMG soe, SIRS VE Tl 00] a metre) 
> via so-0/0/2.0, label-switched-path R1-to-R6 


user@R6> show route 10.0.0.1 


inet.0: 29 destinations, 29 routes (28 active, 0 holddown, 1 hidden) 
1 








+ = Active Route, Last Active, = Both 


100.0 ,1/32 “([LS—-1S/ ls] Sel Ole sde@s, meacenre 20) 
EG 1O,1,56.1 Wie so-0/0/0.0 
StO 0,126.1 waa so-0/0/2.0 
tO IO,1,36.1 wala so-0/0/3.0 


inet.3 : 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 


10,0 ,0.1/ 32 = (DROW / 7 | OOS Oe sis) intstereale: 20) 
> via so-0/0/3.0, label-switched-path R6-to-R1 


Meaning 

Sample Output 1 shows entries in the inet.O routing table only. The inet.3 routing table is missing from 
the output because the LSP is not working. The inet.O routing table is used by interior gateway protocols 
(IGPs) and Border Gateway Protocol (BGP) to store routing information. In this case, the IGP is Intermediate 
System-to-Intermediate System (IS-IS). For more information on the inet.0 routing table, see the Junos 
MPLS Applications Configuration Guide. 


If the LSP was working, we would expect to see entries that include the LSP in the inet.3 routing table. 
The inet.3 routing table is used on ingress routers to route BGP packets to the destination egress router. 
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BGP uses the inet.3 routing table on the ingress router to help resolve next-hop addresses. BGP is configured 
in the example network shown in “MPLS Network Broken at the MPLS Layer” on page 1542. 


Sample Output 2 shows output you should receive when the LSP is up. The output shows both the inet.O 
and inet.3 routing tables, indicating that LSPs R1-to-R6 and R6-to-R1 are available. 


Verify MPLS Labels with the traceroute Command 


Purpose 

Display the route packets take to a BGP destination where the BGP next hop for that route is the LSP 
egress address. By default, BGP uses the inet.0 and the inet.3 routing tables to resolve the next-hop 
address. When the next-hop address of the BGP route is not the router ID of the egress router, traffic is 
mapped to IGP routes, not to the LSP. Use the traceroute command as a debugging tool to determine 
whether the LSP is being used to forward traffic. 


Action 


To verify MPLS labels, enter the following command from the ingress router: 


user@host> traceroute hostname 


| Sample Output 1 


user@R1> traceroute 100.100.6.1 

traceroute to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets 
Oe ee it Me de) 0,027 ms 0.561 ms 0.520 mse 
2 IO. 26.2 (10,1,.26.42) ©O.570 ms UN O.558 me YN 4.879 ms IN 


user@R6> traceroute 100.100.1.1 

traceroute to 100.100.1.1 (100.100.1.1), 30 hops max, 40 byte packets 
L IO.1.26,1 (L0.1,2661) ©.630 ms 0.545 ms 0.438 ims 

2 IUOct,12,1 (10,1,12.1) O.551 ms YN O.557 ms UN 0.526 mse UN 


| Sample Output 2 


user@R1> traceroute 100.100.6.1 
to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets 
i IO.L.13,2 (LO.1,13.2) O.866 ms O.746 ms 0,724 me 
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MPLS Label=100912 CoS=0 TTL=1 S=1 
2 UDI S602 CO.1.56.4) OST ms YN O.597 ams VN O54 ims LIN 


user@R6> traceroute 100.100.1.1 
traceroute to 100.100.1.1 (100.100.1.1), 30 hops max, 40 byte packets 
i IO.1.36,1 (10.1.36.1) 0.802 ms O.716 ms 0.688 ms 


MPLS Label=100896 CoS=0 TTL=1 S=1 
& AUDLetSsl CO ,toISs.1) O.570 ms UN W568 ms YN OW 4 sms HIN 


Meaning 

Sample Output 1 shows that BGP traffic is not using the LSP, consequently MPLS labels do not appear in 
the output. Instead of using the LSP, BGP traffic is using the IGP (IS-IS, in the example network in “MPLS 
Network Broken at the MPLS Layer” on page 1542) to reach the BGP next-hop LSP egress address. The 
Junos OS default behavior uses LSPs for BGP traffic when the BGP next hop equals the LSP egress address. 


Sample Output 2 is an example of output for a correctly configured LSP. The output shows MPLS labels, 
indicating that BGP traffic is using the LSP to reach the BGP next hop. 


Verify MPLS Labels with the ping Command 


Purpose 
When you ping a specific LSP, you check that echo requests are sent over the LSP as MPLS packets. 


Action 


To verify MPLS labels, enter the following command from the ingress router to ping the egress router: 
user@host> ping mpls rsvp Isp-name detail 
For example: 


user@R1> ping mpls rsvp R1-to-Ré detail 


| Sample Output 1 


user@R1> ping mpls rsvp R1-to-Ré detail 
LSP R1l-to-R6 —- LSP has no active path, exiting. 


user@R6> ping mpls rsvp R6-to-R1 detail 
LSP R6-to-R1l - LSP has no active path, exiting. 


| Sample Output 2 


user@R1> traceroute 10.0.0.6 


traceroute to 10.0.0.6 (10.0.0.6), 30 hops max, 40 byte packets 
dL IO.1,15,2 (lO .1,ls.2) 0.708 ms O.613 ms 0.576 me 
2 10.0,0.6 (10,0.0,6) O.7o5 ms 0,708 ms 0.700 ims 


user@R1> ping mpls rsvp R1-to-Ré detail 

Request for seq 1, to interface 69, label 
Reply for seq 1, return code: Egress-—ok 
Request for seq 2, to interface 69, label 
Reply for seq 2, return code: Egress-—ok 
Request for seq 3, to interface 69, label 
Reply for seq 3, return code: Egress-—ok 
Request for seq 4, to interface 69, label 


Reply for seq 4, return code: Egress—-ok 











Request for seq 5, to interface 69, label 




















Reply for seq 5, return code: Egress-—ok 


=== Igjoling SisiriLsties === 


5 packets transmitted, 5 packets received, 


user@R6> ping mpls rsvp R6-to-R1 detail 

Request for seq 1, to interface 70, label 
Reply for seq 1, return code: Egress-—ok 
Request for seq 2, to interface 70, label 
Reply for seq 2, return code: Egress-—ok 
Request for seq 3, to interface 70, label 
Reply for seq 3, return code: Egress—ok 
Request for seq 4, to interface 70, label 


Reply for seq 4, return code: Egress-—ok 











Request for seq 5, to interface 70, label 




















Reply for seq 5, return code: Egress-ok 


=== Igjoimg Statistics === 


5 packets transmitted, 5 packets received, 


Meaning 


Sample Output 1 shows that the LSP does not have an active path to forward echo requests, indicating 


that the LSP is down. 


Sample Output 2 is an example of output you should receive when the LSP is up and forwarding packets. 


100880 


100880 


100880 


100880 








100880 


0% packet loss 


100864 


100864 


100864 


100864 





100864 


0% packet loss 
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Take Appropriate Action 


Problem 

Description: Depending on the error you encountered in your investigation, you must take the appropriate 
action to correct the problem. In this example, an interface is incorrectly configured at the [edit protocols 
mpls] hierarchy level on egress router R6. 


Solution 


To correct the error in this example, follow these steps: 


1. Activate the interface in the MPLS protocol configuration on egress router R6: 


user@R6> edit 

user@R6# edit protocols mpls 

[edit protocols mpls] 

user@R6# show 

user@R6# activate interface so-0/0/3.0 


2. Verify and commit the configuration: 


[edit protocols mpls] 
user@R6# show 
user@R6# commit 


Sample Output 


user@R6> edit 





Entering configuration mode 


[edit] 


user@R6# edit protocols mpls 


[edit protocols mpls] 

user@R6# show 

label-switched-path R6-to-R1 { 
co LOO ,0. if 

} 


inactive: interface so-0/0/0.0; 








inactive: interface so-0/0/1.0; 





inactive: interface so-0/0/2.0; 


inactive: interface so-0/0/3.0; <<< Incorrectly configured interface 


[edit protocols mpls] 
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user@R6# activate interface so-0/0/3 


[edit protocols mpls] 

user@R6# show 

label-switched-path R6-to-R1 { 
co LO 0,0.1- 

} 


inactive: interface so-0/0/0.0; 








inactive: interface so-0/0/1.0; 





inactive: interface so-0/0/2.0; 


interface so-0/0/3.0; <<< Correctly configured interface 


[edit protocols mpls] 
user@R6# commit 


commit complete 


Meaning 


The sample output shows that the incorrectly configured interface so-0/0/3.0 on egress router R6 is now 
activated at the [edit protocols mpls] hierarchy level. The LSP can now come up. 


Verify the LSP Again 


Purpose 
After taking the appropriate action to correct the error, the LSP needs to be checked again to confirm that 
the problem in the BGP layer has been resolved. 


Action 


To verify the LSP again, enter the following command from the ingress, transit, and egress routers: 


user@host> show mpls Isp extensive 


| Sample Output 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


OP OR ORnG 
From: 10.0.0.1, State: Up, ActiveRoute: 1, LSPname: R1-to-R6 
ActivePath: (primary) 


LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


+ 





Primary Sieceer mw 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 
LOL 13.2 S 1O.1s.86.2 8 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPr 





WO sdolSs2# Wels S662 





6 Nov 2 15:48:52 Selected as active path 

5 Now 2 los4@sch2 Record iNouwires LO t,1s.2 Isl. 38.2 

4 Nov 2 15:48:52 Up 

3 Nov 2 15:48:52 Originate Call 

2 Nov 2 15:48:52 CSPF: computation result accepted 

1 Nov 2 15:48:22 CSPF failed: no route toward 10.0.0.6[308 times] 
Created: Tue Nov 2 13:18:39 2004 


Total 1 displayed, Up 1, Down 0 





Egress LSP: 1 sessions 


10 .@.0.1 





From: 10.0.0.6, LSPstate:Up , ActiveRoute: 0 


LSPname: R6-to-R1 , LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Time ikeiries i159, Simees mua Now 2 I5esdescso 2004 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 39106 protocol 0 
BN wmoayewoms IO,L.13,2 (so-0/0/2.,0) 10 pees 
Adspec: received MTU 1500 





PATH sentto: localclient 





RES VARe VsicOmsm Loca lelmrcrit 
Necorcl seuices IO, So.2 IO) ,l,is,2 <seillic> 





otal 1 displayed, Up 1, Down 0 


Transit LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


user@R3> show mpls Isp extensive 


Ingress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 
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mpt): 


Transit LSP: 2 sessions 


OPRO Ra Opels 
From: 10.0.0.6, LSPstate: Up, ActiveRoute: 1 
LSPname: R6-to-R1l, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 
Resv style: 1 FF, Label in: 100864, Label out: 3 
time Iheities 128, Salimeee mas Woy 2 1Ssssedil 2004 





Tspec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 39106 protocol 0 
PACHeeveercOm= asl Op les Omran (SO=0)/.0)/ Sr 0)) mela Ommolates 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.1.13.1 (so-0/0/2.0) 10 pkts 
Sy woyizems IO,1,13,1 (se-0/0/2,0) 10 pes 
pole iewiees 110). i, iS), il 

Necome weweSss IOs. 36,2 <sele> 10,1,13.1 











OP OF ORG 
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1 
LSPname: Rl-to-R6, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 
Resv style: 1 FF, Label in: 100880, Label out: 3 
Mime ikeires 145, Siameesc mua Now 2 153ssGs03 2004 
Tspec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 48015 protocol 0 
PAW Heer eny ison Olaleles ss ( SiO 01/10/1210) MOM kts 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.1.36.2 (so-0/0/3.0) 10 pkts 
RiGwW wewirwoms IM ,1, 36.2 (so-0/0/3.0) 10 jokes 
pxolee wouces 10.1, S6,2 

Saco mouees IO .1t,13,1 <selx> 10,1,3652 














Total 2 displayed, Up 2, Down 0 


user@R6> show mpls Isp extensive 


Ingress LSP: 1 sessions 


IW. MoO. 2 


From: 10.0.0.6, State: Up, ActiveRoute: 1, LSPname: R6-to-R1 
ActivePath: (primary) 


LoadBalance: Random 





Encoding type: Packet, Switching type: Packet, GPID: IPv4 
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AEE ANEW Stares Ws 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 
LO > 36,18 SF LO .1.1S,i1 § 








Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPr 


IM to Sool MO. .s. 





6 Nov 2 15:41:44 Selected as active path 

| Now 2 lost#iled4a Recor INouwires IOs, SG. IM ,d.15.1 

AS Nove eo AAU 

3 Nov 2 15:41:44 Originate Call 

2 Nov 2 15:41:44 CSPF: computation result accepted 

I NOV eS le Se CSP Hr cHelCdanioOmGrOub om OwelcmlOnmOm Onell iS OG eames 
Created: Tue Nov 2 13:12:21 2004 


Total 1 displayed, Up 1, Down 0 





Egress LSP: 1 sessions 


OR ORIORaG 
From: 10.0.0.1, LSPstate:Up, ActiveRoute: 0 


LSPname: R1-to-R6 , LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Wiig llestes i577, Sameer woe Wor 2 LSg4zZe06 2004 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 48015 protocol 0 
yMnsl wewaceoms IO, 36.1 (so-0/0/S.0) Ii jokes 
Adspec: received MTU 1500 





PATH sentto: localclient 





RESV revfrom: localclient 
necowel ieohees IO .L,tS, i IO... 36,1 «<seikic> 





otal 1 displayed, Up 1, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 


Sample Output 1 from ingress router R1 shows that LSP R1-to-R6 has an active route to R6 and the state 


is up. 


Sample Output 2 from transit router R3 shows that there are two transit LSP sessions, one from R1 to R6 


and the other from R6 to R1. Both LSPs are up. 
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Sample Output 3 from egress router R6 shows that the LSP is up and the active route is the primary route. 
The LSP is now traversing the network along the expected path, from R1 through R3 to R6, and the reverse 
LSP, from R6 through R3 to R1. 


Verify That Node-Link Protection Is Up 


Purpose 


After you configure node-link protection, you must check that bypass paths are up. You can also check 
the number of LSPs protected by the bypass paths. In the network shown in “Node-Link Protection” on 
page 278, two bypass paths should be up: one next-hop bypass path protecting the link between R1 and 
R2 (or next-hop 10.0.12.14), and a next-next-hop bypass path avoiding R2. 


Action 

To verify node-link protection (many-to-one backup), enter the following Junos OS CLI operational mode 
commands on the ingress router. You can also issue the commands on transit routers and other routers 
used in the bypass path for slightly different information. 


show mpls Isp 

show mpls Isp extensive 
show rsvp interface 

show rsvp interface extensive 
show rsvp session detail 


| Sample Output 


user@R1> show mpls Isp 


Ingress LSP: 1 sessions 





To From State Rt ActivePath P LSPname 
192 168}, 5). 1 192,168, 1.1 Up 0 via-r2 ee Isp2-r1-to-r5 
Total 1 displayed, Up 1, Down 0 


Egress LSP: 1 sessions 


To From State Rt Style Labelin Labelout LSPname 
192, 168, il 192 61685551 Up O a we 3 - r5-to-r1 
Total 1 displayed, Up1 =, Down 0 





Transit LSP: 2 sessions 
To From State Rt Style Labelin Labelout LSPname 
192, 168,051 192,168,651 Up 0 1 FF 100464 101952  Isp1-r6-to-rO 
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192 1685651 192 168.0, 1 Up 0 1FF 100448 3 r0-to-t6 
Total 2 displayed, Up 2, Down 0 


Meaning 

Sample output from R1 for the show mpls Isp command shows a brief description of the state of configured 
and active LSPs for which R1 is the ingress, transit, and egress router. All LSPs are up. R11 is the ingress 
router for Isp2-r1-to-r5, and the egress router for return LSP r5-to-r1. Two LSPs transit R1, Isp1-r6-to-r0 
and the return LSP r0-to-t6. For more detailed information about the LSP, include the extensive option 
when you issue the show mpls Isp command. 


Sample Output 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


192,168.51 
From: 192.168.1.1, State: Up , ActiveRoute: 0, LSPname: Isp2-ri-to-r5 
ActivePath: via-r2 (primary) 
Node/Link protection desired 
LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





= 


Primary Vila—r2 State: Up 
SmartOptimizeTimer: 180 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
10,012.14 § 10,0.24.2 § 10,0.45.,2 § 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt) : 








10.0.12.14 (Label=101872) 10.0.24.2 (Label=101360) 10.0.45.2 (Label=3) 
11 Jul 11 14:30:58 Link-protection Up 
10 Jul 11 14:28:28 Selected as active path 
Loo SOMEONE icietiNeSeeecl, . «] 
Created: Tue Jul 11 14:22:58 2006 
Total 1 displayed, Up 1, Down 0 





Egress LSP: 1 sessions 


192) 5 O85 151 
From: 192.168.5.1,  LSPstate:Up, ActiveRoute: 0 
LSPname: r5-to-r1, LSPpath: Primary 
Suggested label received: -, Suggested label sent: 








Recovery label received: , Recovery label sent: 
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Resv style: 1 FF, Label in: 3, Label out: - 
time ieiries 146, Siameecs wus gull di l4és28s36 2006 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 1 receiver 29228 protocol 0 
PA Hee ee rOmaellOpaO rele (re Oi/sle/AOr 0) eS Om kates 
Adspec: received MTU 1500 








PATH sentto: localclient 





RBG sewireome ikeeellell wee 


neverouetcl seeyices 10,0,45.2 10,0242 M0 0,124,104 <sedheS 





otal 1 displayed, Up 1, Down 0 


Transit LSP: 2 sessions 





U2 MOE Oi 
From: 192.168.6.1,  LSPstate:Up, ActiveRoute: 0 


LSPname: Isp1-r6-to-r0, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 101952 
Resv style: 1 SE, Label in: 100464, Label out: 101952 
dime lees IS7, Saiineee mos gull Wil Lassies 2006 








[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 11131 protocol 0 
Node/Link protection desired 
Type: Node/Link protected LSP, using Bypass->10.0.12.14->10.0.24.2 
1 Jul 11 14:31:38 Node protection up, using Bypass->10.0.12.14->10.0.24.2 
PAE eee etOm:mel Om Onehom mm (SO— 01/0/3210) mo Ome kates) 
Adspec: received MTU 1500 sent MTU 1500 
SM Seireos LOO 12,14 (re-O/1/0.0) S56 jokics 
RiGw sccwareoms IO,O.12,14 Ges-—O/i/O.0) S58 jolice 
Dolee womcSes 10,0,12,14 10.0,.24.2 10,0.45.2 10.0.,50.2 
NOcome woueSss LO.0 16.2 <sele> 10),0,12.14 10.0.24>.2 10.0.45.2 10.0.50.2 














OPP eG Crone 
From: 192.168.0.1, LSPstate:Up, ActiveRoute: 0 
LSPname: r0-to-t6, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 
Resv style: 1 FF, Label in: 100448, Label out: 3 
Time leites i147, Saimeee nos gull dil 14ssisse 2006 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 23481 protocol 0 
PATH Ese vercom: lO Oreos are 0)/sl/OmO) esis picts 
Adspec: received MTU 1500 sent MTU 1500 
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PATH sentto: 10.0.16.2 (so-0/0/3.0) 350 pkts 

RiGwy wewarwoms IO,0,16,.2 (so-0/O0/3.0) S23 jokics 

Exolce wources 100,162 

RECO GOUESs LO.0.50,.2 I10.0.45.2 10,0.24,.2 10.0,12,.14 <seli> 10,016.22 








Total 2 displayed, Up 2, Down 0 


Meaning 


Sample output from R1 for the show mpls Isp extensive command shows detailed information about all 
LSPs for which R1 is the ingress, egress, or transit router, including all past state history and the reason 
why an LSP failed. All LSPs are up. The main two LSPs Isp2-r1-to-r5 and Isp1-r6-to-r0 have node-link 
protection as indicated by the Node/Link protection desired field in the ingress and transit sections of 
the output. In the ingress section of the output, the Link-protection Up field shows that Isp2-r1-to-r5 has 
link protection up. In the transit section of the output, the Type: Node/Link protected LSP field shows 
that Isp1-r6-to-rO has node-link protection up, and in case of failure will use the bypass LSP 
Bypass->10.0.12.14->10.0.24.2. 


Sample Output 


user@R1> show rsvp interface 


RSVP interface: 4 active 


Active Subscr-— Static Available Reserved Highwater 
Interface State resv iption BW BW BW mark 
fe-0/1/0.0 Up 2 100% 100Mbps 100Mbps Obps Obps 
eS O)/il/sle Omen al 100% 100Mbps 100Mbps Obps Obps 
fe —0)/ 1/27,0) Up 0 100% 100Mbps 100Mbps Obps Obps 
so-0/0/3.0 Up 1 100% 155.52Mbps 155.52Mbps Obps Obps 


Meaning 


Sample output from R1 for the show rsvp interface command shows four interfaces enabled with RSVP 
(Up). Interface fe-0/1/0.0 has two active RSVP reservations (Active resv) that might indicate sessions for 
the two main LSPs, Isp1-r6-to-r0 and Isp2-r1-to-r5. Interface fe-0/1/0.0 is the connecting interface 
between R11 and R2, and both LSPs are configured with a strict path through fe-0/1/0.0. For more detailed 
information about what is happening on interface fe-0/1/0.0, issue the show rsvp interface extensive 
command. 


Sample Output 
user@R1> show rsvp interface extensive 


RSVP interface: 3 active 
fe-0/1/0.0 Index 67, State Ena/Up 
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NoAuthentication, NoAggregate, NoReliable, LinkProtection 





HelloInterval 9(second) 

Address 10.0.12.13 

ActiveResv 2, PreemptionCnt 0, Update threshold 10% 

Subscription 100%, 

bc0O = ct0O, StaticBW 100Mbps 

ct0: StaticBW 100Mbps, AvailableBW 100Mbps 
MaxAvailableBW 100Mbps = (bc0*subscription) 

0] Obps[1] Obps[2] Obps[3] Obps[4] Obps[5] 


Protection: On, Bypass: 2, LSP: 2, Protected LSP: 2, Unprotected LSP: 0 


ReservedBw Obps[6] Obps[7] Obps 

















2 Jul 14 14:49:40 New bypass Bypass-—>10.0.12.14 
1 Jul 14 14:49:34 New bypass Bypass—>10.0.12.14->10.0.24.2 
Bypass: Bypass->10.0.12.14, State: Up, Type: LP, LSP: 0, Backup: 0 
3 Jul 14 14:49:42 Record Route: 10.0.17.14 10.0.27.1 
2 Jul 14 14:49:42 Up 
1 Jul 14 14:49:42 CSPF: computation result accepted 
Bypass: Bypass->10.0.12.14->10.0.24.2, State: Up, Type: NP, LSP: 2, Backup:0 
4 Jul 14 14:50:04 Record Route: 10.0.17.14 10.0.79.2 10.0.59.1 10.0.45.1 
3 Jul 14 14:50:04 Up 
2 Jul 14 14:50:04 CSPF: computation result accepted 
1 Jul 14 14:49:34 CSPF failed: no route toward 10.0.24.2 


Ls 5 GOWlEfohe iciathoeseScls 5 5 


Meaning 


] 


Sample output from R11 for the show rsvp interface extensive command shows more detailed information 


about the activity on all RSVP interfaces (3). However, only output for fe-0/1/0.0 is shown. Protection is 
enabled (Protection: On), with two bypass paths (Bypass: 2) protecting two LSPs (Protected LSP: 2). All 
LSPs are protected, as indicated by the Unprotected LSP: 0 field. The first bypass Bypass->10.0.12.14is 
a link protection bypass path (Type: LP), protecting the link between R1 and R2 fe-0/1/0.0. The second 
bypass path 10.0.12.14->10.0.24.2 is a node-link protected LSP, avoiding R2 in case of node failure. 


Sample Output 


user@R1> show rsvp session detail 


Ingress RSVP: 2 sessions 


AVA 6 UGS} 5 4 5 AL 


miromes 192, i168. i.i1, 


LSPstate: Up, ActiveRoute: 0 


LSPname: Bypass->10.0.12.14->10.0.24.2 





Suggested label received: -, 


Suggested label sent: 
102000 





Recovery label rec 


ived: -, Recovery label sent: 


Resv style: 1 SE, Label in: -, Label out: 102000 





ispec: 








Wale: ikesirie =, Siimeas woe Jul Il laéssOsss 2006 


rate Obps size Obps peak Infbps m 20 M 1500 


Port number: sender 1 receiver 60120 protocol 0 





Type: Bypass LSP 


Number of data route tunnel through: 2 


Number of RSVP session tunnel through: 0 





Explct 





WY 5 MOS} 


From: 


Record route: 


PATH rcvfrom: localclient 

Adspec: sent MTU 1500 

Path MTU: received 1500 

PATH sentto: 10.0.17.14 (fe-0/1/1.0) 336 pkts 
AoW wewitcoms 10.0.7 .14 (#e-0/1/1.0) S10 ples 


route: 10.0.17.14 10.0.79.2 10.0.59.1 10.0.45.1 


Bry dt 
192.168.1.1, LSPstate:Up, ActiveRoute: 0 


LSPname: Isp2-r1-to-r5, LSPpath: Primary 


<—sele> LO0,17 14 10,.0,.79.2 10.0-59.1 10-0.45.1 





Suggested label received: -, Suggested label sent: 





Recoy 


ry label received: -, Recovery label sent: 101872 


Resv style: 1 SE, Label in: y, Lebel outs LOLS 72 





rSspec: 








Wale: Iereie ¢ =, Siinesee wes Dull Ti T4s28e2res ZOOS 


rate Obps size Obps peak Infbps m 20 M 1500 


Port number: sender 2 receiver 60118 protocol 0 





Node/Link protection desired 
Type: Node/Link protected LSP 








PATH rcevfrom: localclient 

Adspec: sent MTU 1500 

Path MTU: received 1500 

PATH sentto: 10.0.12.14 (fe-0/1/0.0) 344 pkts 

RESV revfrom: 10.0.12.14 (fe-0/1/0.0) 349 pkts 
Explct route: 10.0.12.14 10.0.24.2 10.0.45.2 

Maco GouEees <sellie> 0,0, 12.14 10 ,.0,.44.2 10.0452 


Total 2 displayed, Up 2, Down 0 


Egress RSVP: 1 sessions 


WA 6 MOS) 


From: 


Aa 
192.168.5.1,  LSPstate:Up, ActiveRoute: 0 


LSPname: r5-to-rl, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recov 


ry label received: -, Recovery label sent: 


Resv style: 1 FF, Label in: 3, Label out: - 


1564 


1565 


tage Ikeites i147. Ssineere wos wel Wil Wseese 200K 





Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 1 receiver 29228 protocol 0 
PATH revirom: 10.0.12.14 (fe—-0/71/0.0) 348 pkts 
Adspec: received MTU 1500 








PATH sentto: localclient 





RES VE CE GON melo Cauke immer. 
Necouesl ioices 10,0,4552 10,0,.24,2 lO 012,14 <syeihie> 





Total 1 displayed, Up 1, Down 0 


Transit RSVP: 2 sessions 


192,169 .,0. i 
From: 192.168.6.1,  LSPstate:Up, ActiveRoute: 0 


LSPname: Isp1-r6-to-rO, LSPpath: Primary 
Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 101952 
Resv style: 1 SE, Label in: 100464, Label out: 101952 
titgs ihetes is. Simess woe gui iil d4igsilsss 2006 











Tspec: rate Obps size Obps peak Infbps m 20 M 1500 


Port number: sender 1 receiver 11131 protocol 0 





Node/Link protection desired 
Type: Node/Link protected LSP 
PAT Here verona lOmOnkon an (SO= 0/s0)/ SO) mea ccm pokes 
Adspec: received MTU 1500 sent MTU 1500 
SME Seimeeos LOO 12,14 (re-O/1/0.0) S89 okics 
RiGW wewirwoms 10,0, 12.14 (Gre-—O/1/0.0) BAS jokes 
Explct route: 10.0.12.14 10.0.24.2 10.0.45.2 10.0.50.2 
NOCoORC moweSss LOW .16,2 <sellxe> 10,012.14 10.0.24.2 10,.0.45,.2 10.0.50.2 














192,168 .6.1 
From: 192.168.0.1, LSPstate:Up, ActiveRoute: 0 
LSPname: r0-to-t6, LSPpath: Primary 
Suggested label received: -, Suggested label sent: 








Recovery label received: , Recovery label sent: 3 
Resv style: 1 FF, Label in: 100448, Label out: 3 
Hage lkeires Is. Saineer wos wed dil Wassileae 200s 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 1 receiver 23481 protocol 0 
PATH revirom: 10.0-12.14 (fe-0/1/0-0) 344 pkts 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.0.16.2 (so-0/0/3.0) 337 pkts 

RAY seyacscme IO,O. 16.2 (so-0/0/s.0) Sil0 jolkics 
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ipgollker ieimees 10.0) .19.2 
Sacowel EOucSs LO.O.50,2 10,.0,.45.2 10,0,24,2 100,128.14 <sele> 10.0.16.2 





Total 2 displayed, Up 2, Down 0 


Meaning 


Sample output from R1 shows detailed information about the RSVP sessions active on R1. All sessions are 
up, with two ingress sessions, one egress session, and two transit sessions. 


Within the ingress section, the first session is a bypass path, as indicated by the Type: Bypass LSP field; 
and the second session is a protected LSP (Isp2-r1-to-r5) originating on R1, as indicated by the Type: 
Node/Link protected LSP field. 


Conclusion 


Multiprotocol Label Switching (MPLS) label-switched path (LSP) link protection and node-link protection 
are facility-based methods used to reduce the amount of time needed to reroute LSP traffic. These 
protection methods are often compared to fast reroute—the other Junos OS LSP protection method. 


While fast reroute protects LSPs on a one-to-one basis, link protection and node-link protection protect 
multiple LSPs by using a single, logical bypass LSP. Link protection provides robust backup support for a 

link, node-link protection bypasses a node or a link, and both types of protection are designed to interoperate 
with other vendor equipment. Such functionality makes link protection and node-link protection excellent 
choices for scalability, redundancy, and performance in MPLS-enabled networks. 


Related Information 

For additional information about MPLS fast reroute and MPLS protection methods, see the following: 
e Junos User Guide 

e Junos MPLS Applications Configuration Guide 

e Semeria, Chuck. RSVP Signaling Extensions for MPLS Traffic Engineering. White paper. 2002 

e Semeria, Chuck. [P Dependability: Network Link and Node Protection. White paper. 2002 


e RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP Tunnels 


Verify That Link Protection Is Up 


Purpose 

When you verify link protection, you must check that the bypass LSP is up. You can also check the number 
of LSPs protected by the bypass. In the network shown in Many-to-One or Link Protection, a bypass path 
should be up to protect the link between R1 and R2, or next-hop 10.0.12.14, and the two LSPs traversing 
the link, Isp2-r1-to-r5 and Isp1-r6-to-r0. 


Action 


To verify link protection (many-to-one backup), enter the following Junos OS CLI operational mode 


commands on the ingress router: 


user@host> show mpls Isp extensive 
user@host> show rsvp session detail 
user@host> show rsvp interface 


| Sample Output 


user@R1> show mpls Isp extensive | no-more 


Ingress LSP: 1 sessions 


WSVE g MINE 6S) 5 
From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: Isp2-ri-to-r5 
ActivePath:  via-r2 (primary) 
Link protection desired 


LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





+ 


Primary Vilba=te2 State: Up 


SmartOptimizeTimer: 180 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 


LO M12 oa S 10.0 24.4 8 lO,0.45.2 8 


Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt): 


10.0.12.14(Label=101264) 10.0.24.2(Label=100736) 10.0.45.2(Label=3) 

6 Jun 16 14:06:33  Link-protection Up 

5 Jun 16 14:05:39 Selected as active path 

4 Jun 16 14:05:39 Record Route: 10.0.12.14 (Label1l=101264) 
10.0.24.2 (Label=100736) 10.0.45.2 (Label=3) 

S dlin 16 L4ée@ssss) wa 

2 Jun 16 14:05:39 Originate Call 

1 Jun 16 14:05:39 CSPF: computation result accepted 

Created: Fri Jun 16 14:05:38 2006 

Total 1 displayed, Up 1, Down 0 





Ole PUM EEUneatecdne 5] 


Transit LSP: 2 sessions 





192, 1680.1 
From: 192.168.6.1, LSPstate: Up, ActiveRoute: 0 
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LSPname: Isp1-r6-to-rO, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 101296 
Resv style: 1 SE, Label in: 100192, Label out: 101296 
Time left: Lik, Salineas Mein wii 12) LOs2es32 ZOO 








[spec: rate Obps size Obps peak Infbps m 20 M 1500 


Port number: sender 1 receiver 58739 protocol 0 





Link protection desired 
Type: Link protected LSP, using Bypass->10.0.12.14 

1 Jun 19 10:26:32 Link protection up, using Bypass->10.0.12.14 
PATE enieisOm: ell Orel om 2mm (SO 01/10/30) Meo Omak 
Adspec: received MTU 1500 sent MTU 1500 
PARE Seite tO mi sOn Om 1s 7b (he 0)/all/ Om 0) mA iam olstes) 
RiGy wewsrwoms IO,0,12,14 Gee-O/1/0.0) SO pics 
Bogollet momice?s 100,12 14 10,0242 100,452 10,0 5052 
Bevconec! ig@uiees AO 0 16,2 <selbieS MO 0.1e2 i! 10,0 2452 10,0.45.2 10,0.50.2 
lsc pOUlEOUE. Cietinezcecl. . 4] 














Meaning 

The sample output from ingress router R1 shows that Isp2-r1-to-r5 and Isp1-r6-to-r0 have link protection 
up, and both LSPs are using the bypass path, 10.0.12.14. However, the show mpls Isp command does not 
list the bypass path. For information about the bypass path, use the show rsvp session command. 


Sample Output 


user@R1> show rsvp session detail 
Ingress RSVP: 2 sessions 
U2. WO) 2 5 I 
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0 
LSPname: Bypass->10.0.12.14 
Suggested label received: -, Suggested label sent: 








Recovery label received: -, Recovery label sent: 101456 
Resv style: 1 SE, Label in: , Label out: 101456 
Time left: =, Sime@esr Wri Wey 26 Isss8sOo 2006 











[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 18709 protocol 0 
Type: Bypass LSP 
Number of data route tunnel through: 2 
Number of RSVP session tunnel through: 0 
PANTHescypEcomrmmlocalkeleecit: 


Adspec: sent MTU 1500 
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Path MIU: received 1500 

RNs Seiateeos IO 0 17 et CES-O/il/ iO) SilPse jolesi 

RAW wewieceme IO. L714 (re 0/i/i,@) S5095 jokes 
Explct route: 10.0.17.14 10.0.27.1 

INexcouecl idobhees <Sellie> I 50,714 IO.0.27 ci 





192 1635.5 1 
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0 
LSPname: Isp2-r1-to-r5, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 101264 
Resv style: 1 SE, Label in: , Label out: 101264 
Time left: =, Since: Fri Jun 16 14;05:39 2006 











[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 18724 protocol 0 
Link protection desired 


Type: Link protected LSP 

PATH rcevfrom: localclient 

Adspec: sent MTU 1500 

Path MTU: received 1500 

PATH sentto: 10.0.12.14 (fe-0/1/0.0) 8477 pkts 

RESV revfrom: 10.0.12.14 (fe-0/1/0.0) 8992 pkts 
Epoler wemces LO .0W.12,14 10.0,24.28 10.0.45.2 
RSCORGmEOUC Sich e> OR OTA EASON Or A Ay 2 Or Ome ai: 








Total 2 displayed, Up 2, Down 0 





Egress RSVP: 1 sessions 


192,168, i, 
From: 192.168.5.1, LSPstate: Up, ActiveRoute: 0 





LSPname: r5-to-rl, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Timew Let tcl oO ounces Mone Mayere m2. 08 = G2, 0) 016 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 1 receiver 64449 protocol 0 
Suns wero: IO ,0,17 14 Gre-O/il/il.,) SSi145 pkies 
Adspec: received MTU 1500 








PATH sentto: localclient 





NHN wewsreems Iloecilellaeime 


Nexconacl igouneSe IO 0.59.1 IO.0,7/9,2 10.0,17,14 <seiliS 





Total 1 displayed, Up 1, Down 0 
Transit RSVP: 2 sessions 


192, 168.0. 1 
From: 192.168.6.1, LSPstate: Up, ActiveRoute: 0 
LSPname: Isp1-r6-to-rO, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 101296 
Resv style: 1 SE, Label in: 100192, Label out: 101296 
Time left: 129, Salineas Mei wii 12) IOS2Eesse ZOO 








[spec: rate Obps size Obps peak Infbps m 20 M 1500 


Port number: sender 1 receiver 58739 protocol 0 





Link protection desired 

Type: Link protected LSP 

PAT Herex7e rom llOp Orn ( SO 0/10) SO) mECEEA Srp kates 

Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.0.12.14 (fe-0/1/0.0) 2533 pkts 

RESV revfirom: 10.0.12.14 (fe-0/1/0.0) 2685 pkts 

xqolee wewlees LO. ,12,14 100.2452 1O,0.45.2 10,0,50.2 

NXocome wmoueSss LO.0,16,.2 <sele> 10),0,12 14 10.-0.24>62 10.0.45.2 10.0.50.2 











192,168,651 
From: 192.168.0.1, LSPstate: Up, ActiveRoute: 0 





LSPname: rO0-to-r6, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 
Resv style: 1 FF, Label in: 100128, Label out: 3 
Mate estes Asi, Salimnese ala Wey 25 122 S30sAG ZOO 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 4111 protocol 0 

Suns wewsrwoms IO .0 17 14 Gre-O/i1/i.,O) S7TL6 pies 

Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.0.16.2 (so-0/0/3.0) 54524 pkts 

REIS Wen paar camels On OnmtOrtA mm (SOx 0)/40)/.S010)) OSS Cam oikstas 

bole wouces 10,0,16.2 

Record noumces 10,.0.50.2 1O.0.59.1 1I0,0.79.2 10.0 .17,14 <selxS 10.0.16.2 











Total 2 displayed, Up 2, Down 0 


Meaning 


The sample output from ingress router R1 shows the ingress, egress, and transit LSPs for R1. Some 
information is similar to that found in the show mpls Isp command. However, because link protection is 
an RSVP feature, information about bypass paths is provided. The bypass path appears as a separate RSVP 
ingress session for the protected interface, as indicated by the Type field. 
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The bypass path name is automatically generated. By default, the name appears as Bypass > 
interface-address, where the interface address is the next downstream router’s interface (10.0.12.14). The 
explicit route 10.0.17.14 10.0.27.1 for the session shows R7 as the transit node and R2 as the egress node. 


Within the ingress RSVP section of the output, the LSP originating at R1 (Isp2-r1-to-r5) is shown requesting 
link protection. Since a bypass path is in place to protect the downstream link, Isp2-r1-to-r5 is associated 
with the bypass, as indicated by the Link protected LSP field. 


The egress section of the output shows the return LSP r5-to-r1, which is not protected. 


The transit section of the output shows link protection requested by Isp1-r6-to-r0. Since a bypass path is 
in place to protect the downstream link, Isp1-r6-to-rO is associated with the bypass, as indicated by the 
Link protected LSP field. Also included in the transit section of the output is the return LSP r0-to-r6, which 
is not protected. 


Sample Output 


user@R1> show rsvp interface 


RSVP interface: 4 active 


Active Subscr- Static Available Reserved Highwater 
Interface State resv iption BW BW BW mark 
fe-0/1/0.0 Up 2 100% 100Mbps 100Mbps Obps 35Mbps 
re-O/1/1.0 Ups iL 100% 100Mbps 100Mbps Obps Obps 
fe-0/1/2.0 Up 0 100% 100Mbps 100Mbps Obps Obps 
So> 0/0/73 0m Up il 100% 155.52Mbps 155.52Mbps Obps Obps 
Meaning 


The sample output from ingress router R1 shows the number of LSPs going through the interfaces configured 
on R1. The Active resv field shows the number of LSPs for each interface. For example, interface fe-0/1/0.0 
between R1 and R2 has two active reservations, Isp1-r6-to-rO and Isp2-r1-to-r5; interface fe-0/1/1.0 
between R11 and R7 has one, the bypass (10.0.12.14); interface fe-0/1/2.0 between R6 and R11 has no LSP 
reservations; and interface so-0/0/3.0 between R6 and R11 has one LSP reservation, Isp1-r6-to-r0. 


Verify One-to-One Backup 


Purpose 


You can verify that one-to-one backup is established by examining the ingress router and the other routers 
in the network. 


Action 


To verify one-to-one backup, enter the following Junos OS CLI operational mode commands: 
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user@host> show mpls Isp ingress extensive 
user@host> show rsvp session 


| Sample Output 


The following sample output is from the ingress router R1: 


user@R1> show mpls Isp ingress extensive 


Ingress LSP: 1 sessions 


192 168.551 
Hrom:aelOZ ee oceelet ly ciacdise UO ACO ROUECrmn Omen o bE Maine meae—ts@ 166) 
ActivePath: via-r2 (primary) 
FastReroute desired 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





+ 


Primary Vila tse State: Up 


SmartOptimizeTimer: 180 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
LOO ,12 14 S 10.0.24.2 S 10.0.45.2 8 


ReceivedRRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPr 





10.0.12.14(flag=9) 10.0.24.2(flag=1) 10.0.45.2 
8 May 11 14:51:46 Fast-reroute Detour Up 
7 May 11 14:50:55 Record Route: 10.0.12.14(flag=9) 10.0.24.2(flag=1) 10.0.45.2 





6 May 11 14:50:55 Record Route: 10 ,0,12,14 (flacge9) 10.0,.24.2 10.0.,.45,2 
5 May 11 14:50:52 Selected as active path 
AL Mieny IL 4g a0eo2 inexcorcl iINomieSe 0 sie. 10,0.24.2 10.0.45.2 
5 Mex di léss0sS2 Us 
2 May 11 14:50:52 Originate Call 
1 May 11 14:50:52 CSPF: computation result accepted 
Created: Thu May 11 14:50:52 2006 








Total 1 displayed, Up 1, Down 0 


Meaning 


The sample output from R1 shows that the FastReroute desired object was included in the Path messages 
for the LSP, allowing R1 to select the active path for the LSP and establish a detour path to avoid R2. 


In line 8, Fast-reroute Detour Up shows that the detour is operational. Lines 6 and 7 indicate that transit 
routers R2 and R4 have established their detour paths. 
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R2, 10.0.12.14, includes (flag=9), indicating that node protection is available for the downstream node and 
link. R4, 10.0.24.2, includes (flag=1), indicating that link protection is available for the next downstream 
link. In this case, R4 can protect only the downstream link because the node is the egress router R5, which 
cannot be protected. For more information about flags, see the Junos User Guide. 


The output for the show mpls Isp extensive command does not show the actual path of the detour. To 
see the actual links used by the detour paths, you must use the show rsvp session ingress detail command. 


Sample Output 


The following sample output is from the ingress router R1 in the network shown in One-to-One Backup 
Detours. 


user@R1> show rsvp session ingress detail 


Ingress RSVP: 1 sessions 


LY 5 LOS 5 55 I 


From: 192.168.1.1, LSPstate:Up, ActiveRoute: 0 
ESPname al -vo-ro,, b§obparh:) sPramany 





Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 100848 
Resv style: 1 FF, Label in: -, Label out: 100848 
Time left: =, Simees Daw Wen Til dési7sils 2006 








[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 9228 protocol 0 
FastReroute desired 

PATH rcvfrom: localclient 

Adspec: sent MTU 1500 

Path MTU: received 1500 

PATH sentto: 10.0.12.14 (fe-0/1/0.0) 35 pkts 

RiGwy wewirwons 10,012.14 Gre—0/1/0.,0) 25 jokics 
Exolee wouces IO. 12,14 100,424.28 10,045.48 
RECORGmEOUC Sich a> OO rE EAS SOMO re AAO Omer: 








Detour is Up 

Detour Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Detour adspec: sent MTU 1500 

Path MTU: received 1500 

Decoue DAWs Seiicicos IO.O0,17 14 Gre-—O/il/il.0) 23 mokics 

Deicowie AS seoywitcoms LO,O,17 14 Gee-—O/i/i.O) 20 jokics 
Detour Explct route: 10.0.17.14 10.0.79.2 10.0.59.1 

DScowie INSCOrCl wowlees <SelE> WOW .L7o1e WO.0,7I.2 1O.W.59.1 
Detour Label out: 100848 

Total 1 displayed, Up 1, Down 0 
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Meaning 


The sample output from R1 shows the RSVP session of the main LSP. The detour path is established, 
Detour is Up. The physical path of the detour is displayed in Detour Explct route. The detour path uses 
R7 and R9 as transit routers to reach R5, the egress router. 


Sample Output 


The following sample output is from the first transit router R2 in the network shown in One-to-One Backup 
Detours: 


user@R2> show rsvp session transit detail 


Transit RSVP: 1 sessions 


192 1685.5 1 
Brom: 92.6 el EoPsizdiie ss Up), Act nvyeRoute: 





LSPname: rl-to-r5, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 100448 
Resv style: 1 FF, Label in: 100720, Label out: 100448 
Time left: 126, Since: Wed May 10 16:12:21 2006 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 


Port number: sender 5 receiver 9216 protocol 0 





FastReroute desired 

PAM Here verona Om Orelen ls an (Chea) sle/ Ori) ellen See okctes 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.0.24.2 (so-0/0/1.0) 171 pkts 

RESV revfirom: 10.0.24.2 (so-0/0/1.0) 169 pkts 
olee couees 10.0 .24,2 10.0.45.2 

ReCowe mowtes 1O,0,12,13 <selir> 10,0.24.2 10.0.45.2 











Detour is Up 

Detour Tspec: rate Obps size Obps peak Infbps m 20 M 1500 

Detour adspec: received MTU 1500 sent MTU 1500 

Path MTU: received 1500 

Detour PATH sentto: 10.0.27.2 (so-0/0/3.0) 169 pkts 

Detour RESV reveirom: LOROR275 2) \(so—0// 0/320) lor pkts 

Detour Explct route: 10.0.27.2 10.0.79.2 10.0.59.1 

DScoue Recorcl Eouces LO,0,12.13 «<sele> LOs0.27.2 IO.0.79.2 10.00.5921 
Detour Label out: 100736 

Total 1 displayed, Up 1, Down 0 











Meaning 


The sample output from R2 shows the detour is established (Detour is Up) and avoids R4, and the link 
connecting R4 and R5 (10.0.45.2). The detour path is through R7 (10.0.27.2) and R9 (10.0.79.2) to R5 
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(10.0.59.1), which is different from the explicit route for the detour from R1. R1 has the detour passing 
through the 10.0.17.14 link on R7, while R1 is using the 10.0.27.2 link. Both detours merge at RY through 
the 10.0.79.2 link to R5 (10.0.59.1). 


Sample Output 


The following sample output is from the second transit router R4 in the network shown in One-to-One 
Backup Detours: 


user@R4> show rsvp session transit detail 


Transit RSVP: 1 sessions 


WO 6 MOS Bo db 
From: 192.168.1.1, LSPstate:Up, ActiveRoute: 1 


LSPname: r1-to-r5, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 
Recovery label received: , Recovery label sent: 3 





Resv style: 1 FF, Label in: 100448, Label out: 3 
Time left: 155, Since: Wed May 10 16:15:38 2006 





Tspec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 5 receiver 9216 protocol 0 
FastReroute desired 

PATH revfirom: 10.0.24.1 (so-0/0/1.0) 178 pkts 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.0.45.2 (so-0/0/2.0) 178 pkts 

RES Veen ison melOM OMA aim (SO O/i0)/22en0)) ela, Sioa 
Explect route: 10.0.45.2 

Nocore! moweSss WO.O.1e 13s LO.W.24.1 «<seie> 10 .0.,45.2 











Detour is Up 
Detour Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Detour adspec: received MTU 1500 sent MTU 1500 
Path MIU: received 1500 
Detour PATH sentto: 10.0.49.2 (so-0/0/3.0) 176 pkts 
Detour RESV revirom: 10.0.49.2 (so-0/0/3.0) 175 pkts 
Detour Explct route: 10.0.49.2 10.0.59.1 
Detour Recor womcSes LO.0.12.i15 LO .0.24.1 <sele> 10.0,.49.2 10.0.59.1 
Detour Label out: 100352 
Total 1 displayed, Up 1, Down 0 





Meaning 


The sample output from R4 shows the detour is established (Detour is Up) and avoids the link connecting 
R4 and R5 (10.0.45.2). The detour path is through R9 (10.0.49.2) to R5 (10.0.59.1). Some of the information 


is similar to that found in the output for R1 and R2. However, the explicit route for the detour is different, 
going through the link connecting R4 and R9 (so-0/0/3 or 10.0.49.2. 


Sample Output 


The following sample output is from R7, which is used in the detour path in the network shown in 
One-to-One Backup Detours: 


user@R7> show rsvp session transit detail 


Transit RSVP: 1 sessions, 1 detours 


192.168.5.1 
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 1 


LSPname: r1-to-r5, LSPpath: Primary 








Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 100368 
Resv style: 1 FF, Label in: 100736, Label out: 100368 
Time left: 135, Since: Wed May 10 16:14:42 2006 

[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 5 receiver 9216 protocol 0 
Detour branch from 10.0.27.1, to skip 192.168.4.1, Up 


Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Adspec: received MTU 1500 





Path MTU: received 0 

SMusl senarcems LO,0,27.1 (so-0/0/S.0) 179) jokes 

Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.0.79.2 (so-0/0/1.0) 177 pkts 

RESV revfirom: 10.0.79.2 (so-0/0/1.0) 179 pkts 

Ippolee eoures LO.W.79.2 1.0.59 51 
REGO wowitSes 10 ,0,12.13 10.0.27.1 <sele> 10,.0,.79.2 10.0,58.1 
Label in: 100736, Label out: 100368 

Detour branch from 10.0.17.13, to skip 192.168.2.1, Up 


Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Adspec: received MTU 1500 











Path MTU: received 0 

amos wewircoms IO ,O0 1/135 (e-O/i1/1.0) 179 pokes 

Adspec: received MTU 1500 

PATH sentto: 10.0.79.2 (so-0/0/1.0) 0 pkts 

RESV revfirom: 10.0.79.2 (so-0/0/1.0) 0 pkts 

loulet wouces 10.0.7/952 10.0,59,1 
RECoOrG eOUIES?s 100,17 13 <selr> 1Os0,.79.2 10.0 .59o1 
Label in: 100752, Label out: 100368 

Total 1 displayed, Up 1, Down 0 
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Meaning 


The sample output from R7 shows the same information as for a regular transit router used in the primary 
path of the LSP: the ingress address (192.168.1.1), the egress address (192.168.5.1 ), and the name of the 
LSP (r1-to-r5). Two detour paths are displayed; the first to avoid R4 (192.168.4.1) and the second to avoid 
R2 (192.168.2.1). Because R7 is used as a transit router by R2 and R4, R7 can merge the detour paths 
together as indicated by the identical Label out value (100368) for both detour paths. Whether R7 receives 
traffic from R4 with a label value of 100736 or from R2 with a label value of 100752, R7 forwards the 
packet to R5 with a label value of 100368. 


Sample Output 


The following sample output is from RY, which is a router used in the detour path in the network shown 
in One-to-One Backup Detours: 


user@R9> show rsvp session transit detail 


Transit RSVP: 1 sessions, 1 detours 


192,168. 5.1 
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 1 





LSPname: rl—to-r5, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 
ReSvarsiye Cla laeH bye aloe eins 527 ee lialoclerotites ss S 
Time left: 141, Since: Wed May 10 16:16:40 2006 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 5 receiver 9216 protocol 0 
Detour branch from 10.0.49.1, to skip 192.168.5.1, Up 

Tspec: rate Obps size Obps peak Infbps m 20 M 1500 





Adspec: received MTU 1500 

Path MTU: received 0 

PATH revfrom: 10.0.49.1 (so-0/0/3.0) 183 pkts 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.0.59.1 (so-0/0/0.0) 182 pkts 

RES VErewr rom mel OmOi 59 eel (SO= 0/0) OPO) maleSmp kts 
ipgollet womcer 10.0.59 1 

Recor cotees LOW, 12.13 10,0. 24.1 10.0.49.1 <selie> 10.,0.59.1 
Label in: 100352, Label out: 3 

Detour branch from 10.0.27.1, to skip 192.168.4.1, Up 

Tspec: rate Obps size Obps peak Infbps m 20 M 1500 











Adspec: received MTU 1500 

Path MIU: received 0 

Detour branch from 10.0.17.13, to skip 192.168.2.1, Up 

Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Adspec: received MTU 1500 
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Path MTU: received 0 

PATH revfrom: 10.0.79.1 (so-0/0/1.0) 181 pkts 

Adspec: received MTU 1500 

PATH sentto: 10.0.59.1 (so-0/0/0.0) 0 pkts 

RESVErew i roms lOm On 5 9eeln(SO— 0/0/00) mOmplcts 

Explct route: 10.0.59.1 

Score MOUESS LO.O.I2.13 LOO .27.1 I.0,.79.1 «<selx> 10.0,59.1 
Label in: 100368, Label out: 3 

Total 1 displayed, Up 1, Down 0 











Meaning 

The sample output from RY shows that R9 is the penultimate router for the detour path, the explicit route 
includes only the egress link address (10.0.59.1), and the Label out value (3) indicates that R9 has performed 
penultimate-hop label popping. Also, the detour branch from 10.0.27.1 does not include path information 
because R7 has merged the detour paths from R2 and R4. Notice that the Label out value in the detour 
branch from 10.0.17.13 is 100368, the same value as the Label out value on R7. 


Sample Output 


The following sample output is from the egress router R5 in the network shown in One-to-One Backup 


Detours: 


user@R5> show rsvp session egress detail 


Egress RSVP: 1 sessions, 1 detours 





192,168.54 1 
From: 192.168.1.1, LSPstate: Up, ActiveRoute: 0 





LSPname: rl-to-r5, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Time left: 119, Since: Thu May 11 14:44:31 2006 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 9230 protocol 0 
FastReroute desired 

PATH revirom: 10.0.45.1 (so-0/0/2.0) 258 pkts 
Adspec: received MTU 1500 





PATH sentto: localclient 





RESV sevircom: localiclitent 

Record route: 10.0.12.13 10.0.24.1 10.0.45.1 <self> 

Detour branch from 10.0.49.1, to skip 192.168.5.1, Up 

Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
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Adspec: received MTU 1500 

Path MIU: received 0 

Detour branch from 10.0.27.1, to skip 192.168.4.1, Up 

Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Adspec: received MTU 1500 

Path MIU: received 0 
Detour branch from 10.0.17.13, to skip 192.168.2.1, Up 

Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Adspec: received MTU 1500 
Path MTU: received 0 
PARE rev, t roms OmOm oom (SO = O/.0/10l ON mea kts 
Adspec: received MTU 1500 





PATH sentto: localclient 





RESV rcevfrom: localclient 

Neco wopiess UO,0 12513 10.0,24.1 10,0,.49.1 LO.0,59.2 <selie> 
Label in: 3, Label out: - 

Total 1 displayed, Up 1, Down 0 





Meaning 


The sample output from R5 shows the main LSP in the Record route field and the detours through the 
network. 


Verify That the Primary Path Is Operational 


Purpose 

Primary paths must always be used in the network if they are available, therefore an LSP always moves 
back to the primary path after a failure, unless the configuration is adjusted. For more information on 
adjusting the configuration to prevent a failed primary path from reestablishing, see “Preventing Use of a 
Path That Previously Failed” on page 284. 


Action 


To verify that the primary path is operational, enter the following Junos OS command-line interface (CLI) 
operational mode commands: 


user@host> show mpls Isp extensive ingress 
user@host> show rsvp interface 


| Sample Output 1 


user@R1> show mpls Isp extensive ingress 


Ingress LSP: 1 sessions 


192, 168.5. 1 
From: 192.168.1.1, State: Up, ActiveRoute: 0, 


ActivePath: via-r2 (primary) 


LoadBalance: Random 








LSPname: rl-to-r5 








Encoding type: Packet, Switching type: Packet, GPID: IPv4 
*Primary via-r2 State: Up 
Priorities: 6 6 
Bandwidth: 35Mbps 
SmartOptimizeTimer: 180 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 11) 
LOW .12 14 S$ 10,.0,24.2 § 
ReceivedRRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt) : 
10.0.12.14 10.0.24.2 
5 Apr 29 14:40:43 Selected as active path 
4 Apr 29 14:40:43 Record Route: 10.0.12.14 10.0.24.2 
3 Apr 29 14:40:43 Up 
2 Apr 29 14:40:43 Originate Call 
1 Apr 29 14:40:43 CSPF: computation result accepted 
Standby WaLei=ie 7] State: Dn 
SmartOptimizeTimer: 180 
No computed ERO. 
Created: Sat Apr 29 14:40:43 2006 
Total 1 displayed, Up 1, Down 0 
| Sample Output 2 
user@R1> show rsvp interface 
RSVP interface: 3 active 
Active Subscr- Static Available Reserved Highwater 
Interface State resv iption BW BW BW mark 
te-O/1/0.0 Up 2 100% 100Mbps 100Mbps Obps Obps 
te-O/1/i1.,.0 Up 1 100% 100Mbps 100Mbps Obps Obps 
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SO = 0/10) 2m OmmUO il 100% 155.52Mbps 155.52Mbps Obps Obps 


Meaning 

Sample output 1 shows that the LSP is operational and is using the primary path (via-r2) with R2 (10.0.12.14) 
and R4 (10.0.24.2) as transit routers. The priority values are the same for setup and hold, 6 6. Priority O is 
the highest (best) priority and 7 is the lowest (worst) priority. The Junos OS default for setup and hold 
priority is 7:0. Unless some LSPs are more important than others, preserving the default is a good practice. 
Configuring a setup priority that is better than the hold priority is not allowed, resulting in a failed commit 
in order to avoid preemption loops. 


Verify That the Secondary Path Is Established 


Purpose 


When the secondary path is configured with the standby statement, the secondary path should be up but 
not active; it will become active if the primary path fails. A secondary path configured without the standby 
statement will not come up unless the primary path fails. To test that the secondary path is correctly 
configured and would come up if the primary path were to fail, you must deactivate a link or node critical 
to the primary path, then issue the show mpls Isp Isp-path-name extensive command. 


Action 


To verify that the secondary path is established, enter the following Junos OS CLI operational mode 
command: 


Sample Output 


user@R1> show mpls Isp extensive 


Sample Output 


The following sample output shows a correctly configured secondary path before and after it comes up. 
In the example, interface fe-0/1/0 on R2 is deactivated, which brings down the primary path via-r2. The 
ingress router R1 switches traffic to the secondary path via-r7. 
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user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


U2 2 GS 455 
From: 192.168.1.1, State: Up, ActiveRoute: 0, LSPname: rl-to-r5 
ActivePath: via-r2 (primary) 


LoadBalance: Random 





Encoding type: Packet, Switching type: Packet, GPID: IPv4 
*Primary via-r2 State: Up 
Pigi@eiicdless 6 
Bandwidth: 35Mbps 
SmartOptimizeTimer: 180 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 
10.0.12.14 S 10.0.24.2 S 10.0.45.2S 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt) : 





IG .0.12.14 10.,.0,24.2 10,0,45.2 
Apr 29 14:40:4 
Apr 29 14:40:4 
Apr 29 14:40:4 
Apr 29 14:40:4 
Apr 29 14:40:4 


Selected as active path 

Record Route: 10.0.12.14 10.0.24.2 
Up 

Originate Call 





fey tee) Sy (Ga) 
WWW WwW WwW 


CSPF: computation result accepted 
Secondary via-r7 State: Dn 
SmartOptimizeTimer: 180 
No computed ERO. 


Created: Sat Apr 29 14:40:43 2006 
Total 1 displayed, Up 1, Down 0 


[edit interfaces] 


user@R2# deactivate fe-0/1/0 


[edit interfaces] 

user@R2# show 

inactive: fe-0/1/0 { 

winaice © 4 
family inet { 
aickceess 10.0 ,12.,14/ 30s 

} 
family iso; 


family mpls; 


user@R1> show mpls Isp name r1-to-r4 extensive 


IMC EASS IS! 


AVA 6 AOS) 6 4h 5 AL 
me 12, Los) oil. dl, 


Fro 


1 sessions 


State: Up, ActiveRoute: 0, LSPname: rl-to-r4 


ActivePath: via-r7 (secondary) 





LoadBalance: 


Encoding type: 


Primary via-r2 


Priorities: 


Bandwidth: 


Random 


Packet, Switching type: Packet, GPID: IPv4 


6 6 
35Mbps 


State: Dn 


SmartOptimizeTimer: 180 


Will be enqueued for recomputation in 14 second(s). 


10 
2) 


hey (G3) HSS (Gl fen) Se) 


dl 


Apr 
Apr 
Apr 
Apr 
ADE 
Apr 
hoe 
Apr 
Apr 
ADE 


*Standby 
SmartOptimizeTimer: 180 


Computed ERO 


10.0.17.14 S 10.0.47.1S 
Received RRO 


5) 
4 
5 
2 
il 


Cre 


Apr 
Apr 
BpE 
Apr 
ADE 


ated: 


Meaning 


29 
29 
29 
Zo) 
29 
2S) 
29 
29 
29 
29 


14: 
14: 
14: 
14: 
14: 


14 


Lace 


14 


ace 


14 


via-r7 


Dz 8 
42: 
42: 
42: 
42: 
240: 
40: 
240: 
40: 
Aor 


33 
4 
4 


q 


Ss 
COROT SOO COCO CONIC: 





(S 


CSPF failed: no route toward 10.0.12.1 4[21 times] 
Clear Call 

Deselected as active 

Session preempted 

Down 

Selected as active path 

Record Route: 10.0.12.14 10.0.24.2 





Up 
Originate Call 


CSPF: computation result accepted 


State: Up 


[L] denotes strict [loose] hops): (CSPF metric: 11) 


(ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPr 





IM -Oclyoile WO sO064 7 cal 


Zo 
29 
29 
29 
29) 


14: 
14: 
14: 
14: 
14: 


42: 
41: 
41: 
41: 
41: 


48 
2 
12 
2 
U2 


Sere More 29) 
Total 1 displayed, 


Up 


Selected as active path 

Record INowres LO ,0,L7.14 10,047.14 
Up 

Originate Call 

CSPF: computation result accepted 
14:40:43 2006 

1, Down 0 
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qjone}) 3 


The sample output from egress router R1 shows a correctly configured standby secondary path in a down 


state because the primary path is still up. Upon deactivation of an interface (interface fe-0/1/0 on R2) 


critical to the primary path, the primary path via-r2 goes down and the standby secondary path via-r7 


comes up, allowing R1 to switch traffic to the standby secondary path. 
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Verifying the Physical Layer 


Purpose 


After you have configured the LSP, issued the show mpls Isp extensive command, and determined that 
there is an error, you can start investigating the problem at the physical layer of the network. 


Figure 128 on page 1584 illustrates the physical layer of the layered MPLS model. 


Figure 128: Verifying the Physical Layer 





traceroute host-name 
show bgp summary 
BGP Layer show configuration protocols bgp 
show route destination-prefix detail 
show route receive protocol bgp neighbor-address 





show mpls Isp 

show mpls Isp extensive 

show route table mpls.0 

show route address 
traceroute address 

ping mpls rsvp /sp-name detail 


MPLS Layer 





show rsvp session 


RSVP Layer show rsvp neighbor 
show rsvp interface 





- IGP and IP Layers Functioning aa 








OSPF Layer IS-IS Layer 

show ospf neighbor show isis adjacency 

show configuration protocols ospf show configuration protocols isis 
show ospf interface show isis interface 

IP Layer IP Layer 

show ospf neighbor extensive show isis adjacency extensive 
show interfaces terse show interfaces terse 








show interfaces extensive 





Data Link Layer 
noe "JUNOS Interfaces Operations Guide" 
A show interfaces 
Physical Layer show interfaces terse 


ping host 








g015543 





With this layer, you must ensure that the routers are connected, and that the interfaces are up and 
configured correctly on the ingress, egress, and transit routers. 


If the network is not functioning at this layer, the label-switched path (LSP) does not work as configured. 


Figure 129 on page 1585 illustrates the MPLS network and the problem described in this topic. 
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Figure 129: MPLS Network Broken at the Physical Layer 
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The network shown in Figure 129 on page 1585 is a fully meshed configuration where every directly connected 


interface can receive and send packets to every other similar interface. The LSP in this network is configured 


to run from ingress router R1, through transit router R3, to egress router R6. In addition, a reverse LSP is 


configured to run from R6 through R3 to R1, creating bidirectional traffic. 


However, in this example, traffic does not use the configured LSP. Instead traffic uses the alternate route 
from R1 through R2 to R6, and in the reverse direction, from R6 through R5 to R1. 


When you become aware of a situation where an alternate route is used rather than the configured LSP, 


verify that the physical layer is functioning correctly. You might find that routers are not connected, or 


that interfaces are not up and configured correctly on the ingress, egress, or transit routers. 


The cross shown in Figure 129 on page 1585 indicates where the LSP is broken because of a configuration 


error on ingress router R1. 


To check the physical layer, follow these steps: 


1. Verify the LSP | 1585 

2. Verify Router Connection | 1587 
3. Verify Interfaces | 1588 

4. Take Appropriate Action | 1589 
5. Verify the LSP Again | 1590 
Verify the LSP 

Purpose 


Typically, you use the show mpls Isp extensive command to verify the LSP. However, for quick verification 


of the LSP state, use the show mpls Isp command. If the LSP is down, use the extensive option (show mpls 


Isp extensive) as a follow-up. If your network has numerous LSPs, you might consider specifying the name 
of the LSP, using the name option (show mpls Isp name name or show mpls Isp name name extensive). 


Action 


To determine whether the LSP is up, enter the following command from the ingress router: 


user@ingress-router> show mpls Isp extensive 


| Sample Output 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


KOR OF OenG 
From: 10.0.0.1, State: Up, ActiveRoute: 1, LSPname: R1-to-R6 
ActivePath: (primary) 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





= 


Primary Stace: We 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 
10.1.12.2 § 10.1.26.2 S 





Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPr 


LO st oles2 lO, .2652 
99 Sep 18 14:19:04 CSPF: computation result accepted 
98 Sep 18 14:19:04 CSPF: link down/deleted 
10.1.13.1(R1.00/10.0.0.1)->10.1.13.2(R3.00/10.0.0.3) 
Sy Sejo is) lee igedil mecoicl ewes WOoh.I2.2 10,1. 26.2 
96 Sep 18 14:19:01 Up 
95 Sep 18 14:19:01 Clear Call 
94 Sep 18 14:19:0 
93 Sep 18 14:19:0 
92 Sep 18 14:19:01 Down 
91 Aug 17 12:22:52 Selected as active path 
M0 Awig, 17 l2gaze52 ineoorwe Roures LO 1.13.2 IO.d 8652 
SS oc Ly Leg22e52 wis) 


1 CSPF: computation result accepted 


1 MPLS label allocation failure 








[Pe OUe OU mneraINC cic Clem] 
Created: Sat Jul 10 18:18:44 2004 
Total 1 displayed, Up 1, Down 0 





Egress LSP: 1 sessions 
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OPO R Ore 
From: 10.0.0.6, LSPstate: Up, ActiveRoute: 0 
LSPname: R6-to-R1l, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Time left: 144, Since: Tue Aug 17 12:23:14 2004 





Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 1 receiver 39024 protocol 0 
DNs weyaems IO, 1, 15,2 (So-0/0/1.,0) GISSS jolacs 
Adspec: received MTU 1500 








PATH sentto: localclient 





RESV revfrom: localclient 
Record route: 10.1.56.2 10.1.15.2 <self> 
otal 1 displayed, Up 1, Down 0 





Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 


The sample output from ingress router R1 shows that the LSP is using an alternate path rather than the 
configured path. The configured path for the LSP is R1 through R3 to Ré6, and for the reverse LSP, R6 
through R3 to R1. The alternate path used by the LSP is R1 through R2 to R6, and for the reverse LSP, R6 
through R5 to R1. 


Verify Router Connection 


Purpose 


Confirm that the appropriate ingress, transit, and egress routers are functioning by examining whether 
the packets have been received and transmitted with 0% packet loss. 


Action 


To determine that the routers are connected, enter the following command from the ingress and transit 
routers: 


user@host> ping host 
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| Sample Output 


user@R1> ping 10.0.0.3 count 3 

PING 10.0.0.3 (10.0.0.3): 56 data bytes 

64 bytes from 10.0.0.3: icmp_seq=0 tt1l=254 time=0.859 ms 
64 bytes from 10.0.0.3: icmp_seq=1 tt1l=254 time=0.746 ms 
64 bytes from 10.0.0.3: icmp_seq=2 tt1l=254 time=0.776 ms 


=== 10.0,.0.3 Pimg Statisties =—— 
3 packets transmitted, 3 packets received, 0% packet loss 
round-trip min/avg/max/stddev = 0.746/0.794/0.859/0.048 ms 


user@R3>_ ping 10.0.0.6 count 3 

PING 10.0.0.6 (10.0.0.6): 56 data bytes 

64 bytes from 10.0.0.6: icmp_seq=0 tt1l=255 time=0.968 ms 
64 bytes from 10.0.0.6: icmp_seq=1 tt1l=255 time=3.221 ms 
64 bytes from 10.0.0.6: icmp_seq=2 tt1l=255 time=0.749 ms 


=== 10.0,.0.6 jlmg Statistics —-— 
3 packets transmitted, 3 packets received, 0% packet loss 


round-trip min/avg/max/stddev = 0.749/1.646/3.221/1.117 ms 


Meaning 


The sample output shows that ingress router R11 is receiving packets from transit router R3, and that the 
transit router is receiving packets from the egress router. Therefore, the routers in the LSP are connected. 


Verify Interfaces 


Purpose 


Confirm that the interfaces are configured correctly with the family mpls statement. 


Action 


To determine that the relevant interfaces are up and configured correctly, enter the following commands 
from the ingress, transit, and egress routers: 


user@host> show interfaces terse 
user@host> show configuration interfaces type-fpc/pic/port 
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| Sample Output 


user@R1> show interfaces so* terse 


Interface Admin Link Proto Local Remote 

so-0/0/0 up up 

so-0/0/0.0 up up ime 10, 1,12 .1/30 
iso 
mpls 

so-0/0/1 up up 

so-0/0/1.0 up up mace LO), 1 LS, 1/30 
iso 
mpls 

so-0/0/2 up up 

SO 0/107: 2na0) up up dime 10, 1,18,1/30 


iso <<< family mpls is missing 
so-0/0/3 up down 


user@R1> show configuration interfaces so-0/0/2 
pinaic O ff 
family inet { 
ackeicess 10,1, 13), 1/309 
} 


family iso; <<< _ family mpls is missing 


Meaning 

The sample output shows that interface so-0/0/2.0 on the ingress router does not have the family mpls 
statement configured at the [edit interfaces type-fpc/pic/port] hierarchy level, indicating that the interface 
is incorrectly configured to support the LSP. The LSP is configured correctly at the [edit protocols mpls] 

hierarchy level. 


The output from the transit and egress routers (not shown) shows that the interfaces on those routers are 
configured correctly. 


Take Appropriate Action 


Problem 

Description: Depending on the error you encountered in your investigation, you must take the appropriate 
action to correct the problem. In the example below, the family mpls statement, which was missing, is 
included in the configuration of ingress router R1. 


Solution 


To correct the error in this example, enter the following commands: 
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[edit interfaces type-fpc/pic/port] 
user@R1# set family mpls 
user@R1# show 

user@R1# commit 


Sample Output 


[edit interfaces so-0/0/2 unit 0] 


user@R1# set family mpls 


edit interfaces so-0/0/2 unit 0] 
user@R1# show 

family inet { 

access U0,1,13.,1/308 





family iso; 


family mpls; 


[edit interfaces so-0/0/2 unit 0] 
user@R1# commit 


commit complete 


Meaning 
The sample output from ingress router R1 shows that the family mpls statement is configured correctly 
for interface so-0/0/2.0, and that the LSP is now functioning as originally configured. 


Verify the LSP Again 


Purpose 
After taking the appropriate action to correct the error, the LSP needs to be checked again to confirm that 
the problem in the physical layer has been resolved. 


Action 


To verify that the LSP is up and traversing the network as expected, enter the following command: 


user@host> show mpls Isp extensive 
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| Sample Output 1 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


NOFA Oe Oreo 
From: 10.0.0.1, State: Up, ActiveRoute: 1, LSPname: R1-to-R6 
ActivePath: (primary) 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


be 





Primary Staces Ws 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 
10.1.13.2 S 10.1.36.2 S 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt) : 








IM Lets s2 ID 1. 3652 
12 Se Z2il Wee27ess Recor iIouces; IO.1ots.2 10.1.39.2 
iil See 21 Loes27ss3 we 
110 Sep 21 16:27:33 CSPF: computation result accepted 
109 Sep 21 16:27:33 CSPF: link down/deleted 
1.1.12. 1 (RL, 00/10 0.0.1) -210,1.,12.2 (22 .00/10,0.0.2) 
108 Sep 21 16:27:33 CSPF: link down/deleted 
10 ,1,15,1 (RL .00/10.0.0.1) S10 .1,15,.2 (25.00/10 .0.0.5) 








Output truncated...] 
Created: Sat Jul 10 18:18:44 2004 
Total 1 displayed, Up 1, Down 0 





Egress LSP: 1 sessions 


NOLO Oren!s 
From: 10.0.0.6, LSPstate: Up, ActiveRoute: 0 
LSPname: R6-to-Rl, LSPpath: Primary 
Suggested label received: -, Suggested label sent: 








Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Time left: 149, Since: Tue Sep 21 16:29:43 2004 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 2 receiver 39024 protocol 0 
PMs meyeroms NO 1.13.2 (so-0/0/2,0) 7 kes 
Adspec: received MTU 1500 





PATH sentto: localclient 





RESV revfrom: localclient 
Record route: 10.1.36.2 10.1.13.2 <self> 
Total 1 displayed, Up 1, Down 0 
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Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


| Sample Output 2 


[edit protocols mpls] 

user@R1# show 

label-switched-path R1-to-R6é { 
wo 0.05057 


} 
interface fxp0.0 { 


disable; 
} 
inactive: interface so-0/0/0.0; 


inactive: interface so-0/0/1.0; 
interface so-0/0/2.0; 


Meaning 


Sample Output 1 from ingress router R1 shows that the LSP is now traversing the network along the 
expected path, from R1 through R3 to R6, and the reverse LSP, from R6 through R3 to R1. 


Sample Output 2 from ingress router R1 shows that the LSP is forced to take the intended path because 
MPLS is deactivated on R1 interfaces so-0/0/0.0 and so-0/0/1.0. If these interfaces were not deactivated, 
even though the configuration is now correct, the LSP would still traverse the network through the alternate 
path. 


Checking the Data Link Layer 


Purpose 


After you have configured the label-switched path (LSP), issued the show mpls Isp extensive command, 
and determined that there is an error, you might find that the error is not in the physical layer. Continue 
investigating the problem at the data link layer of the network. 


Figure 130 on page 1593 illustrates the data link layer of the layered MPLS model. 


Figure 130: Checking the Data Link Layer 
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. show interfaces 
Physical Layer show interfaces terse 
ping host 


015544 











With this layer, you must check the encapsulation mode, for example, Point-to-Point Protocol (PPP) or 
Cisco High-Level Data Link Control (HDLC); PPP options, for example, header encapsulation; frame check 
sequence (FCS) size; and whether keepalive frames are enabled or disabled. Also, check the ingress, egress, 
and transit routers. 


Figure 131 on page 1593 illustrates the MPLS network used in this topic. 


Figure 131: MPLS Network Broken at the Data Link Layer 
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The network shown in Figure 131 on page 1593 is a fully meshed configuration where every directly connected 


interface can receive and send packets to every other similar interface. The LSP in this network is configured 


to run from ingress router R1, through transit router R3, to egress router R6. In addition, a reverse LSP is 


configured to run from R6 through R3 to R1, creating bidirectional traffic. 


However, in this example, the LSP is down without a path in either direction, from R1 to R6 or from R6 


to R1. 


When you verify that the data link layer is not functioning correctly, you might find a mismatch with PPP 


or Cisco HDLC encapsulation, PPP options, or keepalive frames. 


The cross shown in Figure 131 on page 1593 indicates where the LSP is broken because of a configuration 


error on ingress router R1 that prevents the LSP from traversing the network as expected. 


To check the data link layer, follow these steps: 


1. 


Verify the LSP | 1594 


2. Verify Interfaces | 1595 

3. Take Appropriate Action | 1600 
4. Verify the LSP Again | 1601 
Verify the LSP 

Purpose 


Typically, you use the show mpls Isp extensive command to verify the LSP. However for quick verification 


of the LSP state, use the show mpls Isp command. If the LSP is down, use the extensive option (show mpls 


Isp extensive) as a follow-up. If your network has numerous LSPs, you might consider specifying the name 


of the LSP, using the name option (show mpls Isp name name or show mpls Isp name name extensive). 


Action 


To determine whether the LSP is up, enter the following command from the ingress router: 


user@host> show mpls Isp extensive 


| Sample Output 1 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


10.0.0.6 


From: 10.0.0.1 , State: Dn, ActiveRoute: 0, LSPname: R1-to-R6 
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ActivePath: (none) 
LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





Primary State: Dn 

Will be enqueued for recomputation in 15 second(s). 

140 Sep 30 12:01:12 CSPF failed: no route toward 10.0.0.6[26 times] 

139 Sep 30 11:48:57 Deselected as active 

138 Sep 30 11:48:56 CSPF failed: no route toward 10.0.0.6 
137 “Sep S07 P4856 (Cllear Call 

136 Sep 30 11:48:56 CSPF: link down/deleted 

IO sl. 36,1 (R300 /10 .©.0. 3) S10 .1, 36.2 (26, 00/10.0.0.6) 

135 Sep 30 11:48:56 ResvTear received 

134 Sep 30 11:48:56 Down 

133 Sep 30 11:48:56 CSPF failed: no route toward 10.0.0.6 
132 Sep 30 11:48:56 10.1.13.2: No Route toward dest 








ye OUEDU bE EaUmeate csr) | 
Created: Sat Jul 10 18:18:44 2004 


Total 1 displayed, Up 0, Down 1 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 

The sample output from ingress router R1 shows the LSPs within which it participates. The ingress LSP is 
down, without a path from R1 to R6. Because a reverse LSP is configured in the network shown in “MPLS 
Network Broken at the Data Link Layer” on page 1593, we would expect an egress LSP session to be up. 
However, R1 does not have any egress LSPs, indicating that the LSP from R6 to R11 is not functioning. 


Verify Interfaces 


Purpose 

From your network topology, determine the adjacent interfaces through which the LSP is meant to traverse, 
and examine the output for the encapsulation type, PPP options, FCS size, and whether keepalive frames 
are enabled or disabled 


NOTE: Before you proceed with this step, check the physical layer to ensure that the problem 
is not in the physical layer. 
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Action 


To verify the functioning of adjacent interfaces, enter the following commands from the relevant routers: 


user@host> show interfaces type-fpc/pic/port extensive 
user@host> show interfaces type-fpc/pic/port 


| Sample Output 1 


user@R6> show interfaces so-0/0/3 extensive 
Physical interface: so-0/0/3, Enabled, Physical link is Up 
Interface index: 131, SNMP ifIndex: 27, Generation: 14 


Link-level type: Cisco-HDLC , MTU: 4474, Clocking: Internal, SONET mode, Speed: OC3, 





Loopback: None, 


FCS:16 , Payload scrambler: Enabled 





Device flags : Present Running 

Interface flags: Link-Layer-Down Point-To-Point SNMP-Traps 16384 

Link flags : Keepalives 
Hold-times : Up 0 ms, Down O ms 
Keepalive settings: Interval 10 seconds, Up-count 1, Down-count 3 
Keepalive statistics: 

Input : 0 (last seen: never) 

Output: 357 (last sent 00:00:04 ago) 
CoS queues : 4 supported 
Last flapped § ZOOA-—O7—21 ISsOsges Poe (Owe O7 sO acre) 
Statistics last cleared: Never 


WeAieicske Sieenesasicsles's 


Ibeyobie JONES —-S 203368873 0 bps 
Output bytes : 186714992 88 bps 
Input packets: 3641808 0 pps 
Output packets: S297 DSS) 0 pps 


Igoe, Sherelonas} § 





merors; O, Dreess OW, wremime Gemoras O, kumtss @, Caamess 0, Buckec cheojoss 0, 


Policed discards: 1770, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch 
timeouts: 0, 
BS, Ilninke (RC eierorese OW, iiS iIlitiale iiinO) owercllows3s 


Output errors: 





Carrier transitions: 1, Errors: 0, Drops: 0, Aged packets: 0, HS link FIFO 
underflows: 0, 


MTU errors: 0O 


Queue 
0 be 
1 ex 
2 Bs 


3 ne 


Counters: 
st-effort 
pedited-fo 
sured-forw 


twork-cont 


SONET alarms : None 


SONET 


SONET 


defects : None 


Blaine g 


PLL Lock 








PHY Light 
SONET section: 
Bip -s 





SEF 

LOS 

LOF 

SSS 
SHIGEO 
SEE S=S 

SONET line: 

Ae = 1By2, 


















































Queued packets 
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PrP PP FP PO 


se SS e&= FP PrP es S&F S&S S&S ec S&S 


SF | oS ec ec Sc &S S& Ss 


ECMO REZ 
0 
0 
SHOWS Sy; 


Transmitted packets 


Count 


i — Co © 


Sy > SS 


oO 








State 
OK 
OK 


OK 
OK 
OK 


OK 
OK 
OK 
OK 


OK 
OK 
OK 
OK 
OK 


LYWIO U2 
0 
0 
SLOOSS 7 


Dropped packets 
0 


0 
0 
0 
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ES>PEE 0 
SS eis 0 
UAS-PFE 0 








Received SONET overhead: 
0x00, JO 
OscVOF ee 
0x00, Z4 
SONET 
0x00, 
0x00, 
0x00 
Received path trace: R3 so-0/0/3 


Bz 
00 


Fil 
Sil 
Z3 


0x00, 
Obaoue , 
0x00, 


Kl 

C2 (cmp) 
Sia(emp)) 
overhead: 
Jo 

€2 





Transmitted 
Fl 
Si 
Z4 


0x01, 
Osohiny 


Kl 
F2 


3S) 
00 
00 00 00 00 00 00 00 O00 O00 
00 00 00 00 00 00 00 O00 OOD 
Transmitted path trace: R6 so-0/0/3 
52 
00 


20 
00 


Ws 
00 


6f 
00 


2d 
00 


30 
00 


2 
00 


30 
00 


eae 
00 
00 
00 


BS 
00 
00 
00 


00 
00 
00 
00 


es ey eS! 
oS 2 2S ©} 


36 
00 
00 00 00 00 00 00 
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HDC Me Om to Uaeckeelko ties 


20 
00 


Ws 
00 


6f 
00 


2d 
00 


30 
00 
00 
00 


Ae 
00 
00 
00 


30 
00 
00 
00 


(aie 
00 
00 
00 


BS 
00 
00 
00 


00 
00 
00 
00 








a ese 
So S&S &] 


Policing bucket: 
Shaping bucket 
Giant threshold: 


Packet Forwarding 


Destination slot: 


CoS transmit queue 


0 best-effort 


Disabled 
Disabled 


4484, Runt threshold: 





Engine configuration: 


OW, Pine Joyrces iL (O00) 


ale 


bps 
147744000 


Bandwidth 


3 network-control Va OOO 


Logical interface so-0/0/3.0 (Index 71) 
Flags: Device-Down 


WiEue IS SHECSic asic ses < 


Input bytes 406737746 
Output bytes 186714992 
Input packets: 7283616 
Output packets: 349) TSS) 
Loci SeaeasicLes s 

Input bytes 203368873 
Output bytes 186714992 
Input packets: 3641808 
Output packets: 3491 568) 


0x0 
Oxc 
0x0 


0x0 
0x0 


00 
00 
00 
Od 


00 
00 
00 
00 


oe 


Point-To-Point SNMP-Traps 


f, 





00 
00 
00 


Oa 


00 
00 
00 
00 





K2 
F2 


K2 
Z3 


(SNMP ifIndex 28) 
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0x00 
0x00 


0x00 
0x00 


R3 so-0/0/3. . 


Buffer Priority Iga MILIE 
bytes 
0 low none 
0 low none 


(Generation 16) 


Encapsulation: Cisco-HDLC 
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TEeaMSsiic Sitaicasic ies 
Input bytes 203368873 0 bps 
Output bytes 0 0 bps 
Input packets: 3641808 0 pps 
Output packets: 0 0 pps 
Protocol inet, MTU: 4470, Generation: 46, Route table: 0 


Flags: None 


Addresses, Flags: 


Dest-route-down Is-Preferred Is-Primary 








Destination: 10.1.36.0/30, Local: 10.1.36.2, Broadcast: 10.1.36.3, Generation: 38 
Protocol iso, MTU: 4469, Generation: 47, Route table: 0 
Flags: None 
Protocol mpls, MTU: 4458, Generation: 48, Route table: 0 
Flags: None 
| Sample Output 2 
user@R3> show interfaces so-0/0/3 
Physical interface: so-0/0/3, Enabled, Physical link is Up 
Interface index: 131, SNMP afindex: 24 
Link-level type: PPP , MTU: 4474, Clocking: Internal, SONET mode, Speed: OC3, 
Loopback: None, FCS:16 , 
Payload scrambler: Enabled 


Device flags 


Interface flags: 


Link flags 


Keepalive settings: 





Present Running 


Point-—To-Point SNMP-Traps 


: Keepalives 


Interval 10 seconds, Up-count 1, Down-count 3 














Keepalive: Input: 736827 (00:00:03 ago), Output: 736972 (00:00:05 ago) 
LCP state: Opened 

NCP stat inet: Opened, inet6: Not-configured, iso: Opened, mpls: Opened 
CHAP state: Not-configured 

CoS queues 4 supported 

Last flapped AWWA=O7—21l ISsOssOl wwe (LOmScl LDeS7 acto) 

Input rate 40 bps (0 pps) 

Output rate 48 bps (0 pps) 

SONET alarms one 

SONET defects one 








Logical interface so-0/0/3.0 (Index 70) 


Flags: 


Point ]Lo= 


(SNMP ifIndex 51) 


Point SNMP-Traps_ Encapsulation: PPP 


1600 


Protocol inet, MTU: 4470 
Flags: None 





Addresses, Flags: Is-Preferred Is—Primary 
DESicimeiciome LO,1,36,.0/50, woecals I0.1,.36.1, Beoaceasics 10.1.356.38 
Protocol iso, MTU: 4470 
Flags: None 
Protocol mpls, MTU: 4458 
Flags: None 


Meaning 

Sample Output 1 from egress router R6 shows that there are no SONET alarms or defects (none), the 
states are all OK, and the path trace shows the distant end (R3 so-0.0.0), indicating that the physical link 
is up. However, the logical link is down, and the link-level type is Cisco HDLC. 


Sample Output 2 from transit router R3 shows that the link-level type is PPP, indicating that the 
encapsulation types are mismatched, resulting in the LSP going down. 


Take Appropriate Action 


Problem 
Description: Depending on the error you encountered in your investigation, you must take the appropriate 
action to correct the problem. In the example below, the encapsulation types are mismatched. 


Solution 


To correct the error in this example, enter the following commands: 


[edit interfaces so-0/0/3] 
user@R1# show 

user@R1# delete encapsulation 
user@R1# show 

user@R1# commit 


Sampel Output 


[edit interfaces so-0/0/3] 
user@R6# show 
encapsulation cisco-hdlc; 
wince O 4 
family inet { 
ACEreSsS W0.1L.36,2/ 308 
} 


family iso; 


family mpls; 


[edit interfaces so-0/0/3] 


user@R6# delete encapsulation 


[edit interfaces so-0/0/3] 
user@R6# show 
pinaic O ff 
family inet { 
acizess 10,1,36,2/ 30s 
} 


family iso; 


family mpls; 


[edit interfaces so-0/0/3] 
user@R6# commit 


commit complete 


Meaning 

The sample output from egress router R6 shows that the Cisco HDLC was incorrectly configured on 
interface so-0/0/3 which prevented the LSP from using the intended path. The problem was corrected 
when the encapsulation statement was deleted and the configuration committed. 


Verify the LSP Again 


Purpose 
After taking the appropriate action to correct the error, the LSP needs to be checked again to confirm that 
the problem in the data link layer has been resolved. 


Action 
From the ingress, egress, and transit routers, verify that the LSP is up and traversing the network as 


expected: 


user@host> show mpls Isp extensive 


1601 


1602 


| Sample Output 1 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


10.0.0.6 
From: 10.0.0.1 , State: Up, ActiveRoute: 1, LSPname: R1-to-R6 
ActivePath: (primary) 


LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





= 


Primary Staces Wis 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 
10.1.13.2 S 10.1.36.2 S 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt) : 








IM Lets s2 10.1. 36.2 
145 Sep 30 12:25:01 Selected as active path 
14a Sei 30 I2s25s0il Recor momees IG sLots.2 10,1.56.2 
IANS) Sisjo S10) Ase esol Wis) 
142 Sep 30 12:25:01 Originate Call 
141 Sep 30 12:25:01 CSPF: computation result accepted 
140 Sep 30 12:24:32 CSPF failed: no route toward 10.0.0.6[74 times] 
139 Sep 30 11:48:57 Deselected as active 
138 Sep 30 11:48:56 CSPF failed: no route toward 10.0.0.6 
iS VScom SOM Me ee bio eleareealel 
136 Sep 30 11:48:56 CSPF: link down/deleted 
10.1, 36.1 (RS ,.00/10 0.0.3) -S10.1. 96.2 (R26. 00/10.0.0.6) 
co COMcjohe wicbinesicSel., . = ]| 
Created: Sat Jul 10 18:18:43 2004 





Total 1 displayed, Up1 , Down 0 





Egress LSP: 1 sessions 


10.0.0.1 
From: 10.0.0.6 , LSPstate: Up, ActiveRoute: 0 
LSPname: R6-to-R1l, LSPpath: Primary 
Suggested label received: -, Suggested label sent: 











Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Time left: 134, Since: Thu Sep 30 12:24:56 2004 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 6 receiver 39024 protocol 0 
BAW westerns ID.L,13,2 (se-0/0/2.0) 7 jets 


Adspec: received MTU 1500 


PATH sentto: localcl 





IGSW wewarw@enng Jhecadle 


Record route: 10.1.36.2 10.1.13.2 <self> 


Transit LSP: 





0 session 


| Sample Output 2 


ient 


lient 


Total 1 displayed, Up 1, Down 0 


Ss 


Total 0 displayed, Up 0, Down 0 


user@R6> show mpls Isp extensive 


LiMGieess IySI2)e 


10.0.0.1 


1 session 


s 


From: 10.0.0.6, State: Up, ActiveRoute: 1, LSPname: R6-to-R1 


ActivePath 





= 


Primary 
Computed 
10.1.36.1 S 10. 


Received 


: (primar 


LoadBalance: Random 


Encoding type: Packe 


ERO (S [L 
1.13.1 S 





RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt) : 


y) 


t, Switching type: Packet, GPID: IPv4 
State: Up 
] denotes strict [loose] hops): (CSPF metric: 20) 





Isto SGOol Woks lgs i 


Oo 


Ss 
oy (3) SS Gn eh Se) Me SI 


Sep 30 
Sep 30 
Sep 30 
Sep 30 
Sep 30 
Sep 30 
Sep 30 
Sep 30 
Sep 30 
IO. 1. 36.2 (RG 


Ss 


Ss 


q 





q 


Ae ALS Ie 
LEZ 8 eae IL 
Lea wale Ie 
eee Aas Ile) 
1 BAA IL 
WAS AS BAS 
JEL Baie) GIL 
sates IL 
JEAL 3 Gite) IL 
sO0/10.050 





Selected as active path 

ReaGorG INoucSs LO sso. 10 ,161Ssi 

Up 

Originate Call 

CSPF: computation result accepted 

CSPF failed: no route toward 10.0.0.1[73 times] 
Deselected as active 

CSPF failed: no route toward 10.0.0.1 

CSPF: link down/deleted 

—6) =S1L0, 1.36.1 ORF. 00/10.0.053) 


[= -OUEDUE Erunicatedy. | 
Created: Tue Aug 17 12:18:34 2004 
Total 1 displayed, Up 1, Down 0 





Homessm inst 


1 sessions 
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10.0.0.6 


From: 10.0.0.1 , LSPstate: Up, ActiveRoute: 0 
LSPname: R1l-to-R6, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Time left: 159, Since: Thu Sep 30 12:24:16 2004 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 19 receiver 44251 protocol 0 
PA reeeewer Om: allO les Grrl (SO 0)/10)3 10) mea kites 
Adspec: received MTU 1500 








PATH sentto: localclient 





RES VaEG Cae OMmmel oO Canlkeleincints 
Record route: 10.1.13.1 10.1.36.1 <self> 
otal 1 displayed, Up 1, Down 0 





Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


| Sample Output 3 


user@R3> show mpls Isp extensive 


Ingress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Transit LSP: 2 sessions 


10.0.0.1 


From: 10.0.0.6 , LSPstate: Up, ActiveRoute: 1 
LSPname: R6-to-R1l, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 
Resv style: 1 FF, Label in: 100176, Label out: 3 
Iimew Letts 4 SP Suimcers Thum Seon SON An Zale? Sa? 0104 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 6 receiver 39024 protocol 0 
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PAT rece verrcOm sllO i lees Onan (SIO— 01/0) Se 0) mlO mmoles 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.1.13.1 (so-0/0/2.0) 9 pkts 
UWS wewrteems IO, 13,1 (se-0/0/2,0) 9 jalzes 
pole emcees 10, i, 1S), il 

Record route: 10.1.36.2 <self> 10.1.13.1 











10.0.0.6 


From: 10.0.0.1 , LSPstate: Up, ActiveRoute: 1 
LSPname: R1l-to-R6, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 
Resv style: 1 FF, Label in: 100192, Label out: 3 
Time left: 148, Since: Thu Sep 30 12:21:30 2004 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 19 receiver 44251 protocol 0 
PATH re vjiecom lO deals (SO— 0/0/20) me Opies 
Adspec: received MTU 1500 sent MTU 1500 
PATH sentto: 10.1.36.2 (so-0/0/3.0) 9 pkts 
RiGw wewirwoms IO il, 36.2 (Se-0/0/3.0) 9 jakics 
Exolee couces 1.1. S652 

Record route: 10.1.13.1 <self> 10.1.36.2 
Total 2 displayed, Up 2, Down O 














Sample Output 4 


user@R1> show configuration protocols mpls 
label-switched-path R1-to-R6é { 

io LOO. OiG. 
} 


inactive: interface so-0/0/0.0; 








inactive: interface so-0/0/1.0; 


interface so-0/0/2.0; 


user@R6> show configuration protocols mpls 
label-switched-path R6-to-R1 { 

to LO,0.0.i¢ 
} 


inactive: interface so-0/0/0.0; 





inactive: interface so-0/0/1.0; 








inactive: interface so-0/0/2.0; 


interface so-0/0/3.0; 


user@R3> show configuration protocols mpls 
interface fxp0.0 { 

disable; 
} 


inactive: interface so-0/0/0.0; 








inactive: interface so-0/0/1.0; 
interface so-0/0/2.0; 
interface so-0/0/3.0; 


Meaning 

Sample Outputs 1 and 2 from ingress router R1 and egress router R6, respectively, show that the LSP is 
now traversing the network along the expected path, from R1 through R3 to R6, and the reverse LSP, 
from R6 through R3 to R1. 


Sample Output 3 from transit router R3 shows that there are two transit LSP sessions, one from R1 to R6 
and the other from R6 to R1. 


Sample Output 4 shows the interfaces that were deactivated on the ingress, egress, and transit routers, 
forcing the LSP to take the intended path. If these interfaces were not deactivated, even though the 
configuration is now correct, the LSP would still traverse the network through the alternate path. 


Verifying the IP and IGP Layers 


Problem 

Description: After you have configured the label-switched path (LSP), issued the show mpls Isp extensive 
command, and determined that there is an error, you might find that the error is not in the physical or data 
link layers. Continue investigating the problem at the IP and IGP layers of the network. 


Figure 132 on page 1607 illustrates the IP and IGP layers of the layered MPLS model. 
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Figure 132: IP and IGP Layers 





traceroute host-name 
show bgp summary 
BGP Layer show configuration protocols bgp 
show route destination-prefix detail 
show route receive protocol bgp neighbor-address 





show mpls Isp 

show mpls Isp extensive 

show route table mpls.0 

show route address 
traceroute address 

ping mpls rsvp /sp-name detail 


MPLS Layer 





show rsvp session 


RSVP Layer show rsvp neighbor 
show rsvp interface 





¢-— _ !GP and IP Layers Functioning al 














OSPF Layer IS-IS Layer 
show ospf neighbor show isis adjacency 
show configuration protocols ospf show configuration protocols isis 
show ospf interface show isis interface 
IP Layer IP Layer 
show ospf neighbor extensive show isis adjacency extensive 
show interfaces terse show interfaces terse 
Data Link Layer show interfaces extensive 


"JUNOS Interfaces Operations Guide" 





. show interfaces 
Physical Layer show interfaces terse 
ping host 


015545 











Solution 
At the IP and IGP layers, you must check the following: 
e Interfaces have correct IP addressing, and the IGP neighbors or adjacencies are established. 


e Open Shortest Path First (OSPF) or Intermediate System-to-Intermediate System (IS-IS) protocols are 
configured and running correctly. 


e If the OSPF protocol is configured, check the IP layer first, then the OSPF configuration, making sure 
that the protocol, interfaces, and traffic engineering are configured correctly. 


e If the IS-IS protocol is configured, it doesn’t matter whether you check IS-IS or IP first because both 
protocols are independent of each other. Verify that IS-IS adjacencies are up, and that the interfaces 
and IS-IS protocol are configured correctly. 


~ NOTE: The IS-IS protocol has traffic engineering enabled by default. 


If the network is not functioning at the IP or IGP layers, the LSP does not work as configured. 


Figure 133 on page 1608 illustrates the MPLS network used in this topic. 
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Figure 133: MPLS Network Broken at the IP and IGP Layers 


AS 65432 


(aa J oat? s0-0/0/3 Zits 
24.1 24.2 
50-0/0/0 | RA) so-0/0/2 
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122 we 

so-0/0/2 so-0/0/0 4 


45.1 
so-0/0/1 26.1 B49 | so-0/0/1 
23.1 46.1 



















so-0/0/0 s0-0/0/2 
12.1 ‘452 


Ri 30-0/0/1 


































Ingress 154 oe 1 
lo0: .1 is ‘e a a 1D: 
—— so-0/0/1 so-0/0/1 
so0-0/0/0 0-0/0/2 
so-0/0/2 mtg 34.1 26.2 46.2 so-0/0/0 
13.1 7 — 56.1 
R6 
Ff LK jee ORO, 0" 2 so-0/0/0 2 
ao ele xX | Egress | 56.2 E 
STE s0-0/0/3 s0-0/0/3 Cae B, 
36.1 36.2 
Key: 
so-0/0/X: 10.1.x.x/30 ——— Physical connection 
100: 10.0.0.x/32 - - -  LSP-bidirectional traffic 








NOTE: The IGP is IS-IS or OSPF 





The network shown in Figure 133 on page 1608 is a fully meshed configuration where every directly connected 
interface can receive and send packets to every other similar interface. The LSP in this network is configured 
to run from ingress router R1, through transit router R3, to egress router R6. In addition, a reverse LSP is 
configured to run from R6, through R3, to R1, creating bidirectional traffic. The crosses in 


Figure 133 on page 1608 indicate where the LSP is not working because of the following problems at the IP 
and IGP layer: 


e An IP address is configured incorrectly on the ingress router (R1). 


e The OSPF protocol is configured with a router ID (RID) but without the loopback (loO) interface, and 
traffic engineering is missing from the transit router (R3). 


e Levels in the IS-IS network are mismatched. 


Verifying the IP Layer 


Purpose 


You can check the IP layer before or after you check the interior gateway protocol (IGP) layer, depending 
on whether you have OSPF or IS-IS configured as the IGP. If your MPLS network is configured with OSPF 
as the IGP, you must first verify the IP layer, checking that the interfaces have correct IP addressing and 
that the OSPF neighbors are established before you check the OSPF layer. 


If you have IS-IS configured as the IGP in your MPLS network, you can verify either the IP layer or the 
IS-IS protocol layer first. The order in which you check the IP or IS-IS layer does not affect the results. 
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Figure 134: MPLS Network Broken at the IP Layer 











AS 65432 
/ *) soos so-001a “ #1 \ 
fem 24.1 24.2 | \ 
$0-0/0/0 | tap. 9 | | as ; so-O/0/2 
122 \ TT / \ pom 45.1 
por ZA mn. Ie ae 
A  y—- So 00/2 so0/iv0 ——— ee 
ee erry a so-0/0/1 26.1. 34.2 so-0/0/1 so-0/0/2 an 
/ No 23.1 awe 4 46.1 452 ¥ 2 
f h RI \_ so-0/0/1 / so-0/0/1 i; R5 \ 
\ mr “| 15.1 rae 15.2 A 100:.5-/ 
\ “ ™_- so-0/0/1 < Ngo so-0/0/1 a nin. 4 
———— ~~ so-0/0/0 'so-0/0/2 ~~ g0-W/0/0 
so-002 232 | 344 22 . 462 56.1 
A131 Sen a NZ \/ir~ Pe 
<a x Y \- 
Y \ / R6_..\ go. a 
perl a a | Egress 62 if 
13.2 \eeelQ0edm=/ 56. c/0/3 50-0103 \Hgpegn=/ 3 
NEW 361 2 STS 
Key: 
so-O/0/X: 10.1.x.x/30 —— Physical connection 
100: 10.0.0.x/32 - - -  LSP-bidirectional traffic 


NOTE: The IGP is IS-IS or OSPF 


The cross in Figure 134 on page 1609 indicates where the LSP is broken because of the incorrect configuration 
of an IP address on ingress router R1. 


1. Verify the LSP | 1609 

2. Verify IP Addressing | 1610 

3. Verify Neighbors or Adjacencies at the IP Layer | 1612 
4. Take Appropriate Action | 1617 

5. Verify the LSP Again | 1618 


Verify the LSP 


Purpose 


After configuring the LSP, you must verify that the LSP is up. LSPs can be ingress, transit, or egress. Use 

the show mpls Isp command for quick verification of the LSP state, with the extensive option (show mpls 
Isp extensive) as a follow-up if the LSP is down. If your network has numerous LSPs, you might consider 
specifying the name of the LSP, using the name option (show mpls Isp name name or show mpls Isp name 
name extensive). 


Action 


To verify that the LSP is up, enter the following command from the ingress router: 


user@host> show mpls Isp extensive 
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| Sample Output 1 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


OPO Orc 
From: 10.0.0.1, State: Dn, ActiveRoute: 0, LSPname: R1l-to-R6é 


ActivePath: (none) 


LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





Primary State: Dn 

Will be enqueued for recomputation in 25 second(s). 

44 Oct 15 16:56:11 CSPF failed: noroute toward 10.0.0.6 [2685 times] 
AS VOC cA oe OT OR elkcaraee anlale 

42 Oct 14 19:06:56 Deselected as active 

Al Octet T4190 356 TOs. i221: MPS label allocation farluie 

40 Oct 14 19:06:56 Down 

39 Oct 14 18:43:43 Selected as active path 

33 Oe 14 isgiiseds Recor inooees IO ots .2 IO, 36.42 

CV Oce eMac Ae ASUS 











Loo -Oibicjoinne iexbineeiceel., . 5 | 
Created: Thu Oct 14 16:04:33 2004 


Total 1 displayed, Up 0, Downl1 





Egress LSP: 0 sessions 


Total O displayed , Up 0, Down 0 


Transit LSP: 0 sessions 


TotalO displayed , Up 0, Down 0 


Meaning 


The sample output from ingress router R1 shows that an MPLS label allocation failure occurred and the 
Constrained Shortest Path First (CSPF) algorithm failed, resulting in no route to destination 10.0.0.6 on 
Ré. 


Verify IP Addressing 


Purpose 


When you investigate the IP layer, you verify that interfaces have correct IP addressing, and that OSPF 
neighbors or IS-IS adjacencies are established. In this example, an IP address is configured incorrectly on 
the ingress router (R1). 


Action 
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To verify IP addressing, enter the following command from the ingress, transit, and egress routers: 


user@host> show interfaces terse 


| Sample Output 


user@R1> show interfaces terse 


Interface Admin Link Proto Local Remote 

so-0/0/0 up up 

so-0/0/0.0 up up dmee 10), 1, 12.10/30 
iso 
mpls 

so-0/0/1 up up 

so-0/0/1.0 up up mace IO, 1 LS, 1/30 
iso 
mpls 

so-0/0/2 up up 

so-0/0/2.0 up up inet 10.1.13.2 <<< Incorrect IP address 
iso 
mpls 

100 up up 

100.0 up up dmgeic 10),0 0.1 


iso 49.0004.1000.0000.0001.00 


user@R3> show interfaces terse 


Interface Admin Link Proto Local Remote 
so-0/0/0 up up 
so-0/0/0.0 up up mace 0), 1 SA. 1 y/ 30 
iso 
mpls 
so-0/0/1 up up 
so-0/0/1.0 up up dmeie 10), 1,23.2/30 
iso 
mpls 
so-0/0/2 up up 
so-0/0/2.0 up up inet 10.1.13.2/30 <<< Identical to R1 
iso 
mpls 
so-0/0/3 up up 
so-0/0/3.0 up up mace 10), 1,36, 1/30 


LO) 


100 
100.0 


up 
up 


user@R6> show interfaces terse 


Interface 
so-0/0/0 
so-0/0/0.0 


Sm OV IOV al 
so-0/0/1.0 


so-0/0/2 
so-0/0/2.0 


so-0/0/3 
So 0)/10/ S20 


100.0 


Meaning 


Admin 
up 
up 


up 
up 


up 
up 


up 
up 


up 


up 
up 


Link 
up 
up 


up 
up 


up 
up 


up 
up 


up 


mpls 


inet 


iso 


PIE CHES) 


inet 
iso 


mpls 


inet 
iso 


mpls 


inet 
iso 


mpls 


inet 
iso 

mpls 
inet 


iso 


LO). 
49. 


ORIORrS: 
0004.1000.0000.0003.00 


Local Remote 


LO. 


LO 5 


GOR, 


LO, 


GOR, 
49. 


1,56 .2/ 30 


1.46.2/30 


1,26 ,.2/ 30 


1, 3652/30 


ORICERG 
0004.1000.0000.0006.00 


The sample output shows that the IP addresses for interface so-0/0/2.0 on R1 and interface so-0/0/2.0 
on R3 are identical. Interface IP addresses within a network must be unique for the interface to be identified 


correctly. 


Verify Neighbors or Adjacencies at the IP Layer 


Purpose 


If the IP addressing is configured incorrectly then the OSPF neighbors or IS-IS adjacencies both need to 


be checked to determine if one or both of them are established. 


Action 


To verify neighbors (OSPF) or adjacencies (IS-IS), enter the following commands from the ingress, transit, 


and egress routers: 


user@host> show ospf neighbor extensive 


user@host> show isis adjacency extensive 
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| Sample Output 1 


user@R1> show ospf neighbor extensive 
Address Interface State ID iDieaL 
IO. .12 2 so-0/0/0.0 Full 10,002 128 
aces: O.0,0.0, oot Ox42, DR O.0.0.0, BOR O.0.0.0 
Up 1d 04:45:20, adjacent 1d 04:45:20 
10 ,i,15.2 so-0/0/1.0 Full HOO Oh 128 
area O.0.0.0, oot Ux4Z2, DR O.0.0.0, BOR 0.0.0.0) 
Up 1d 04:45:20, adjacent 1d 04:45:10 <<< noadjacency with R3 so-0/0/2 


user@R3> show ospf neighbor extensive 

Address Interface State ILD) ireaL 

10 1.2341 SOm /A0Y/ ele Full L10.050.,2 128 
area W.0.0.0, ooc Ux, DR O.0,0.0, BOR 0.0.0.0 
Up lw2d 04:54:30, adjacent lw2d 04:54:21 

IO .1. 36608 so-0/0/3.0 iFBLLIL 10,.0.0.6 1A 
ares: O50,.0.0, oot Ox42, DR O.0.0,0, BOR O.0,0.0 


Up 1lw2d 04:54:30, adjacent lw2d 04:54:30 <<< noadjacency with R1 so-0/0/2 


user@R6> show ospf neighbor extensive 
Address Interface State ID Beal 
10 .1.56,1 $O=0/0/ 0.0 iP YoLL IL 10.,.0.0.5 128 
ase O50.0.0, oo O42, IDR O.0,0,0, BOR 0.00.0 
Ue el OZ2sS9335, aciaceme icl 02659355 
10.1 BGs il Som A020 Full 10.0.0.,2 128 
area O.0.0.0, oo Ox4t2, DR O.0,.0.0, BOR 0.0.0.0 
Up lw2d 04:57:30, adjacent lw2d 04:57:30 
LO Ls 3G 1 SO-0/0/3.0 Full 10..0.0.3 128 
aces O-0.0.0, oot Ox42, DR O.0.0.0, BOR O.0.,0.0 
Up lw2d 04:56:11, adjacent 1lw2d 04:56:11 


| Sample Output 2 


user@R1> show isis adjacency extensive 
R2 


Interface: so-0/0/0.0, Level:2, State:Up , Expires in 23 secs 





Picioeiieys O, Wo/DOwa cxanericaomss I, Waste eimeaasiicloms OFsS7siG ace 


Circuit type: 2, Speaks:IP , IPv6 


Dead 


34 


SS) 


Dead 


39) 


3g 


Dead 


3g 


36 


36 
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Topologies: Unicast 
Yes 
IP addresses: 10.1.12.2 


AeeumSjalicaLein Iheyeys 


Restart capable: 
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WES SOSS2 acio 


Expires in 26 secs 


ODE SIC Sago) 


When State Reason 
wea Oct 1S lasses 35 Up Seenself 
R5 
Interface: so-0/0/1.0, Level:2, State:Up, Expires in 26 secs 
Peioriicys O, Uo/Down Ereiasiicloms?s 1, iIesic tmainsilicdo@me 
Circuit type: 2, Speaks:IP , IPvé6 
Topologies: Unicast 
Restart capable: Yes 
IP addresses: 10.1.15.2 
practi pintelA@ 1mlk@ cas 
When State Reason 
pra, Ocr 15 IAs S9eOo Up Seenself 
R3 
linceriraces So-O/0/2.0, ewes 2, Siceiess Us, 
Priority: 0, Up/Down transitions: 1, Last transition: 
Circuit type: 2, Speaks:IP , IPv6 
Topologies: Unicast 
Restart capable: Yes 
IP addresses: 10.1.13.2 
WeeuMSsicsLein Ikexe;s 
When State Reason 
wren Or 15 ae59<il Up Seenself 


user@R3> show isis adjacency extensive 








R4 
Interface: so-0/0/0.0, Level:2, State:Up , 
Priority: 0, Up/Down transitions: 1, Last transition: 
Circuit type: 2, Speaks:IP , IPv6 
Topologies: Unicast 
Restart capable: Yes 
IP addresses: 10.1.34.2 
Mecns thon hoc = 
When Sia Reason 
Wags Oleic Zi IS)9 il s\6 Up Seenself 
R2 
Interface: so-0/0/1.0, Level:2, State:Up , Expires 








Expires in 25 secs 


lwild 00:22:51 ago 


in 25) sees 
































Priority: 0, Up/Down transitions: 1, Last transition: 2w2d 18:02:48 ago 
Circuit type: 2, Speaks:IP , IPv6 
Topologies: Unicast 
Restart capable: Yes 
IP addresses: 10.1.23.1 
eeinsiicaeimn Ikereys 
When State Reason 
TUCMOC te OM nes Sias5 Up Seenself 
R1 
Interface: so-0/0/2.0, Level:2, State:Up , Expires in 22 secs 
Diaioreiieys O, WeDo cmeinsiesomss i, ieSic temensslicdG@ms 22! I/324306 ago 
Circuit type: 2, Speaks:IP , IPv6 
Topologies: Unicast 
Restart capable: Yes 
IP addresses: 10.1.13.1 
IeeMgilciem kee, 
When State Reason 
Tue Oeic 1 22eililes7/ Up Seenself 
R6 
Interface: so-0/0/3.0, Level:2, State:Up , Expires in 21 secs 
Piclomitty:: Oey Downet rans aeons le last stannic elon eZwilLe OO ON 00macge 
Circuit type: 2, Speaks:IP , IPvé6 
Topologies: Unicast 
Resitaremcapobkerm ves 
IP addresses: 10.1.36.2 
WieeumSjalicaLein Ikeyeys 
When State Reason 
Ua Oee LiL 15s29303 Up Seenself 
user@R6> show isis adjacency extensive 
R5 
Interface: so-0/0/0.0, Level:2, State:Up , Expires in 23 secs 
Pieionugibtiy.: 0) US DOWMmtacanisitedons telecomms tel onc lw2 Ole AOiOS mace 
Circuit type: 2, Speaks:IP , IPvé6 
Topologies: Unicast 
Restart capable: Yes 
IP addresses: 10.1.56.1 
WeeuMSalicalLein keys; 8 
When Sia Reason 
Wed @ct 27 14335232 Up Seenself 


R4 


Interface: 


Praoei 


Gime cua 


Topologies: 


Restar 


so-0/0/1.0, 
0, 


Level:2, State: Up , 
Up/Down transitions: 1, 
& esses Speaks: IP , 


Unicast 


Ey? 
in IPv6 


t capable: Yes 


IP addresses: 10.1.46.1 


Transi 
When 
Ways Oye 





R2 


Interface: 


Priori 


Caeeua 


Topologies: 


Restar 


Eso lheyes 
State 





o 2 Legileeas Up 


so-0/0/2.0, 
0, 


Level:2, State: Up , 
Up/Down transitions: 1, 
& wees Speaks: IP , 


Unicast 


ty: 
2p IPv6 


t capable: Yes 


IP addresses: 10.1.26.1 


Transi 
When 
aa Oe 





R3 


Interface: 


iDeaL @)ie aL 


Cima ctuas 


Topologies: 


Restar 


tion log: 


State 





oil ils¢sssho Up 


so-0/0/3.0, 
0, 


Level:2, State: Up , 
Up/Down transitions: 1, 
t type: Speaks: IP , 


Unicast 


ty: 
Be IPv6 


t capable: Yes 


IP addresses: 10.1.36.1 


Transi 
When 
Wage Oye 





Meaning 


EaGin Ike~es 
State 





& ib LSoesseaS Up 
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Last transition: 


Reason 


Expires in 25 secs 


lwild 00:26:50 ago 


Seenself 





Last transition: 


Reason 


Last transition: 


Reason 


Expires in 24 secs 


2wid 00:11:40 ago 


Seenself 





Expires in 19 secs 


2wild 00:11:40 ago 


Seenself 


Sample Output 1 from the ingress, transit, and egress routers shows that R1 and R3 are not established 

OSPF neighbors. Considering that the two interfaces so-0/0/2.0 (R1 and R3) are configured with identical 
IP addresses, you would expect this. The OSPF protocol routes IP packets based solely on the destination 
IP address contained in the IP packet header. Therefore, identical IP addresses in the autonomous system 
(AS) result in neighbors not establishing. 


Sample Output 2 from the ingress, transit, and egress routers shows that R1 and R3 have established an 
IS-IS adjacency despite the identical IP addresses configured on interfaces so-0/0/2.0 on R1 and R3. The 
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IS-IS protocol behaves differently from the OSPF protocol because it does not rely on IP to establish an 
adjacency. However, if the LSP is not up, it is still useful to check the IP subnet addressing in case there 
is a mistake in that layer. Correcting the addressing error might bring the LSP back up. 


Take Appropriate Action 


Problem 
Description: Depending on the error you encountered in your investigation, you must take the appropriate 
action to correct the problem. In this example, the IP address of an interface on transit router R2 is 


incorrectly configured. 


Solution 


To correct the error in this example, enter the following commands: 


[edit interfaces so-0/0/2] 

user@R1# show 

user@R1# rename unit 0 family inet address 10.1.13.2/30 to address 10.1.13.1/30 
user@R1# show 

user@R1# commit 


Sample Output 


[edit interfaces so-0/0/2] 
user@R1# show 
binaic O ff 
family inet { 
address 10.1.13.2/30; <<< Incorrect IP address 
} 
fe ITTileel aes Oy 


family mpls; 


[edit interfaces so-0/0/2] 
user@R1# rename unit 0 family inet address 10.1.13.2/30 to address 10.1.13.1/30 


[edit interfaces so-0/0/2] 
user@R1# show 
wince O 4 
family inet { 
address 10.1.13.1/30; <<< Correct IP address. 
} 
family iso; 


family mpls; 
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[edit interfaces so-0/0/2] 
user@R1# commit 


commit complete 


Meaning 

The sample output shows that interface so-0/0/2 on ingress router R1 is now configured with the correct 
IP address. This correction results in unique subnet IP addresses for all interfaces in the MPLS network in 
“MPLS Network Broken at the IP and IGP Layers” on page 1608, and the possibility that the LSP might come 


up. 
Verify the LSP Again 


Purpose 
After taking the appropriate action to correct the error, the LSP needs to be checked again to confirm that 
the problem in the OSPF protocol has been resolved. 


Action 


To verify the LSP again, enter the following command on the ingress, transit, and egress routers: 


user@host> show mpls Isp extensive 


| Sample Output 1 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


ORO RI Orr6 
From: 10.0.0.1, State: Up, ActiveRoute:1 , LSPname: R1-to-R6 
ActivePath: (primary) 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





*Primary State: Up 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 
10.1.13.2 S 10.1.36.2 S 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt) : 








IOcdelss2 WO. So,” 
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54 Oct 15 21:28:16 Selected as active path 

53 Oc 15 Zilsaseile Record inowrces IO .lo.1s.2 IO.1,36.2 
S52 Oe 1S Zile2Zssils Wyo 

Gi Ooi 15 Zis28elG 1O1.15,1 
50 Oce 1S Zilg2eeiil CSRs cehijouie 
AS Occ 15 2Zis2z7ea2 LO. 1o.13 


PLS label allocation failure[2 times] 
a 
i 
48 Oct 15 21:27:42 CSPF: computation result accepted 
P 
al 
a 


tion result accepted 


LS label allocation failure 


AW Oce TS Zis2yesil 10. i, i5.i¢ 
AGMOC teow. eo MOrelGEniciscm Gal 
Aly Oe IS Zile2Z/sils CSPae Comoe 


LS label allocation failure[4 times] 














tion result accepted 
Loo eOibicjoinne icxewINeZcSel., » = | 
Created: Thu Oct 14 16:04:34 2004 


Total 1 displayed, Up1 =, Down 0 





Egress LSP: 1 sessions 


10.0.0 4 i 
From: 10.0.0.6,  LSPstate:Up , ActiveRoute: 0 


LSPname: R6-to-R1 , LSPpath: Primary 





Suggested label received: -, Suggested label sent: 
Recovery label received: -, Recovery label sent: -— 

Resv style: 1 FF, Label in: 3, Label out: - 

Tame ikeiteg 149) Sameer wien Oce Is Bilseeecils 2004 





[Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 13 receiver 39024 protocol 0 
Mire wemitzems IO, 13,2 (se-O0/0/2,0) 10 pkes 
Adspec: received MTU 1500 








PATH sentto: localclient 





RESV revfrom: localclient 


Record route: 10.1.36.2 10.1.13.2 <self> 





otal 1 displayed, Upi1=, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


| Sample Output 2 


user@R3> show mpls Isp extensive 
Ingress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 
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To 


Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 2 sessions 


LO @.@ 4d 


From: 10.0.0.6,  LSPstate:Up , ActiveRoute: 1 


LSPname: R6-to-R1 , LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 
Resv style: 1 FF, Label in: 100336, Label out: 3 
Hage iIkeires 156, Saineer wien Oce 1S BilgiSsaly 2004 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 13 receiver 39024 protocol 0 
syns wewareoms IO, 36.2 (so-0/0/S.0) Li pikes 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.1.13.1 (so-0/0/2.0) 11 pkts 

SW weyeroms IO... (so-0/0/2,0) Ii pees 
logollicte, ounces 10. i. 1s}. il 


Record route: 10.1.36.2 <self> 10.1.13.1 











OR OnEG 
From: 10.0.0.1,  LSPstate:Up , ActiveRoute: 1 


LSPname: R1-to-R6 , LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 
Resv style: 1 FF, Label in: 100352, Label out: 3 
Wiig leite: 159 Sameer iin Oce 1S ZilgiSssso 2004 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 5 receiver 47901 protocol 0 
PATHiEe Viton: Ones Sorel (Slo — 0/1 01/210) Mla oksts 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.1.36.2 (so-0/0/3.0) 11 pkts 
RES VEEe Eom a llOr lens Ona (SIO— 01/01/2310) melalmolkctes 
Eoolee woumcee LO.L. 366.2 

Record route: 10.1.13.1 <self> 10.1.36.2 


tal 2 displayed, Up2 _, Down 0 
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| Sample Output 3 


user@R6> show mpls Isp extensive 


Ingress LSP: 1 sessions 


10 .O,0.i 
From: 10.0.0.6, State:Up , ActiveRoute: 1, LSPname: R6-to-R1 
ActivePath: (primary) 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





be 


Primary Seaces Wis 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 
10.1.36.1 S 10.1.13.1S 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt) : 








Ice Sood AO. iL .tlsis Wl 














187 Oct 15 21:20:05 Selected as active path 
186 Oce 1s Zils2o0s0s Recorc Rowmees IGsl.S6.L I0,tetsoi 
13s Occ LH Zils2ZocOs Wie 
184 Oce is Ziles2osos Cilceue cell 
183 Oct 15 21:20:05 CSPF: computation result accepted 
182 Oct 15 21:20:05 CSPF: link down/deleted 

IO ,1,13,2 (R39 .00/10.0.0.3) =-S10.1,13,.2 (1. 00/10.0.0.1) 

-Output truncated... ] 


Created: Tue Aug 17 12:18:33 2004 
Total 1 displayed, Up1 =, Down 0 





Egress LSP: 1 sessions 


10-0 ,0.6 
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 0 
LSPname: R1-to-R6 , LSPpath: Primary 





Suggested label received: -, Suggested label sent: 








Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
ime ikeiries i144, Sameec mien Oce 15 2Zils20s08 2004 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 5 receiver 47901 protocol 0 
PAs! secxcicome IO ,L.36.,1 (so-0/0/3.0)) til jalees 
Adspec: received MTU 1500 








PATH sentto: localclient 





INDSW wecwaccoems Ihocazllellieive 


Record route: 10.1.13.1 10.1.36.1 <self> 
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Total 1 displayed, Up1 =, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 


Sample Output 1 from ingress router R1 shows that LSP R1-to-Ré6 has an active route to R6 and the state 
is up. The output shows that the egress LSP session R6-to-R1 received and sent a recovery label. 


Sample Output 2 from transit router R3 shows that there are two transit LSP sessions, one from R1 to R6 
and the other from R6 to R1. Both LSPs are up. 


Sample Output 3 from egress router R6 shows that the LSP is up and the active route is the primary route. 
The LSP is now traversing the network along the expected path, from R1 through R3 to R6, and the reverse 
LSP, from R6 through R3 to R1. 


Verify the LSP Again 


Purpose 


After taking the appropriate action to correct the error, the LSP needs to be checked again to confirm that 
the problem in the IS-IS protocol has been resolved. 


Action 
To verify that the LSP is up and traversing the network as expected, enter the following command from 
the ingress, egress, and transit routers: 


user@host> show mpls Isp extensive 


| Sample Output 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


Oe OROnEG 
From: 10.0.0.1, State:Up , ActiveRoute: 1, LSPname:R1-to-R6 
ActivePath: (primary) 


LoadBalance: Random 





Encoding type: Packet, Switching type: Packet, GPID: IPv4 


Ae EINE SieacSes Wis 





Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Nod 


IO .L1S.2 WO. 3G.2 
4 Oct 19 21:22:54 Selected as active path 
3 Oe 19 Zigzzeos Recowe INowrSss IO. .s.2 1M .1.35.2 
4 Occ 19 2ZigZ2353 We 
il O@et 12) Zigaeess Cwigiimeies Cell 
Ceeeieecls UMS Oc 19 BZile2ze5s ZOO 


Total 1 displayed, Up1 =, Down 0 





Egress LSP: 1 sessions 


OPO Ohee 
From: 10.0.0.6,  LSPstate:Up , ActiveRoute: 0 
LSPname: R6-to-R1 , LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
dime lkeities IL7, Saimeee mas Occ 19 Bilsiysde? 2004 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 2 receiver 39064 protocol 0 
DN weyeroems IO,1 13,2 (Se-0/0/2,0) 10 kes 
Adspec: received MTU 1500 





PATH sentto: localclient 





Rag wewireems locale liaLemic 


Necowel mouices IM i, S62 10,1 .,1S,2 <sedlic> 





otal 1 displayed, Upi1 =, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


user@R3> show mpls Isp extensive 
Ingress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 2sessions 





10.0.0, 
From: 10.0.0.6, LSPstate: Up, ActiveRoute: 1 


10=SoftPreempt) : 


1623 


LSPname: R6-to-R1 , LSPpath: Primary 





Suggested label received: -, Suggested label sent: 
Recovery label received: , Recovery label sent: 3 





Resv style: 1 FF, Label in: 100416, Label out: 3 
Time leitcs i139, Sameer rue Oce 19 2Zilg@Ssiil 2004 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 2 receiver 39064 protocol 0 
SNe weirs IO, 36.2 (so-0/0/5.0) il jokes 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.1.13.1 (so-0/0/2.0) 11 pkts 
RES Vee viecOns mel Oh ersleo sla (slo— 01/10/2210) Meeker 
lpolkeic iaewncees 110), iL, Is), il 











neoomel ieohees IOs. S6.2 <sellics 10), 1.13}. i 


10.0 ,0.6 
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1 
LSPname: R1-to-R6 , LSPpath: Primary 


Suggested label received: -, Suggested label sent: 
Recovery label received: , Recovery label sent: 3 








Resv style: 1 FF, Label in: 100448, Label out: 3 


time ikeities 135, Simees woe Oce 19 ZilsiGs22 2004 





Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 1 receiver 47951 protocol 0 
PATH revirom: 10.1.13.1 (so-0/0/2.0) 4 pkts 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.1.36.2 (so-0/0/3.0) 4 pkts 

RiGw wewiewoms IO, 36.2 (So-0/0/3.0) 4 jakics 

RECORC Bowes LO.1 13,1 <sele> 10,1.,36.2 














Total 2 displayed, Up2 _, Down 0 


user@R6>  runshow mpls Isp extensive 


Ingress LSP: 1 sessions 


NOPE Or Oren! 
From: 10.0.0.6, State: Up, ActiveRoute: 1, LSPname: R6-to-R1 
ActivePath: (primary) 
LoadBalance: Random 


+ 





Primary 


Computed E 





Encoding type: Packet, Switching type: Packet, GPID: IPv4 


State: Up 


LO Lo SGod S LO NelZol § 


Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Nod 


RO (S [L] denotes strict [loose] hops): (CSPF metric: 2) 





Isto SGol WO, bots. i 


10=SoftPreempt) : 


1624 


19 Oct 19 21:09:52 Selected as active path 

18 Oe is) Zils09ses2 Record inouces IO .to.SG.1 IO.dotsel 

iy Gee 19 ZigO9s52 Us 

16 Oe 1s) ZilsOGsS2 Creugiimais Cazllil 

iS Gee 1S) 2ZilsOG9ses2 CPN s CeMISMIEeicLEm mesulle aeesjocrac! 
Cxeacecds mae Oe 19) ISeSOso 200d 


Total 1 displayed, Up1 =, Down 0 





Egress LSP: 1 sessions 


OR OR ORaG 
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 0 
LSPname: R1-to-R6 , LSPpath: Primary 
Suggested label received: -, Suggested label sent: 








Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Tig lleire: IP0, Sameer rue Oce 19 2ilgiSses0s 2004 





[Tspec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 47951 protocol 0 
YM iwewscwoms IO il, S61 (Se-0/0/3.0) 4 jakics 
Adspec: received MTU 1500 





PATH sentto: localclient 





RESV revfrom: localclient 
necowel iowkeSes WO .L.tS oi IO... 36,1 «<seilic> 





Total 1 displayed, Upi1=, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 

The sample output from ingress router R1 and egress router R6 shows that the LSP is now traversing the 
network along the expected path, from R1 through R3 to R6, and the reverse LSP, from R6 through R3 to 
R1. In addition, the sample output from transit router R3 shows that there are two transit LSP sessions, 
one from R11 to R6, and the other from R6 to R1. 


Checking the RSVP Layer 


Purpose 

After you have configured the label-switched path (LSP), issued the show mpls Isp extensive command, 
and determined that there is an error, you might find that the error is not in the physical, data link, or 
Internet Protocol (IP) and interior gateway protocol (IGP) layers. Continue investigating the problem at 
the RSVP layer of the network. 
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Figure 135 on page 1626 illustrates the RSVP layer of the layered MPLS model. 


Figure 135: Checking the RSVP Layer 





traceroute host-name 
show bgp summary 
BGP Layer show configuration protocols bgp 
show route destination-prefix detail 
show route receive protocol bgp neighbor-address 





show mpls Isp 

show mpls Isp extensive 

show route table mpls.0 

show route address 
traceroute address 

ping mpls rsvp /sp-name detail 


MPLS Layer 





show rsvp session 
RSVP Layer show rsvp neighbor 
show rsvp interface 





f-— _ IGP and IP Layers Functioning — 














OSPF Layer IS-IS Layer 
show ospf neighbor show isis adjacency 
show configuration protocols ospf show configuration protocols isis 
show ospf interface show isis interface 
IP Layer IP Layer 
show ospf neighbor extensive show isis adjacency extensive 
show interfaces terse show interfaces terse 
Data Link Layer show interfaces extensive 


"JUNOS Interfaces Operations Guide" 





| show interfaces 
Physical Layer show interfaces terse 
ping host 


9015546 











With this layer, you check that dynamic RSVP signaling is occurring as expected, neighbors are connected, 
and interfaces are configured correctly for RSVP. Check the ingress, egress, and transit routers. 


If the network is not functioning at this layer, the LSP does not work as configured. 


Figure 136 on page 1627 illustrates the MPLS network used in this topic. 
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Figure 136: MPLS Network Broken at the RSVP Layer 





































AS 65432 
so-0/0/3 so-0/0/3 
24,1 24.2 
s0-0/0/0 ae ’ i 4) so-o/ore 
12.2 we ett 45.1 
: so-0/0/2 s0-0/0/0 
re so-0/0/1 26.1 94.2 30-0/0/1 50-0/0/2 
—s .23.1 46.1 45.2 
Ri s0-0/0/1 $0-0/0/1 
Ingress 154 152 
lo0: .1 ae 
oe so-0/0/1 s0-0/0/0 0-0/0/2 so-0/0/1 
so-0/0/2 cae 34.4 26.2 
13.1 7 
so-o/0o/2 ; MWY \. - - - - BoE $ 
Egress 56.2 8 
132 s0-0/0/3 30-0/0/3 \ 190:.6 3 
36.1 36.2 
Key: 
so-0/0/X: 10.1.x.x/30 ——— Physical connection 
100: 10.0.0.x/32 - - -  LSP-bidirectional traffic 








NOTE: The IGP is OSPF or IS-IS 





The network shown in Figure 136 on page 1627 is a fully meshed configuration where every directly connected 
interface can receive and send packets to every other similar interface. The LSP in this network is configured 
to run from ingress router R1, through transit router R3, to egress router R6. In addition, a reverse LSP is 
configured to run from R6 through R3 to R1, creating bidirectional traffic. 


However, in this example, the LSP is down without a path in either direction, from R1 to R6 or from R6 
to R1. 


The crosses shown in Figure 136 on page 1627 indicate where the LSP is broken. Some possible reasons the 
LSP is broken might include that dynamic RSVP signaling is not occurring as expected, neighbors are not 
connected, or interfaces are incorrectly configured for RSVP. 


In the network in Figure 136 on page 1627, a configuration error on transit router R3 prevents the LSP from 
traversing the network as expected. 


To check the RSVP layer, follow these steps: 


1. Verify the LSP | 1627 

2. Verify RSVP Sessions | 1629 

3. Verify RSVP Neighbors | 1632 

4. Verify RSVP Interfaces | 1633 

5. Verify the RSVP Protocol Configuration | 1635 
6. Take Appropriate Action | 1636 

7. Verify the LSP Again | 1638 


Verify the LSP 


Purpose 
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Typically, you use the show mpls Isp extensive command to verify the LSP. However for quick verification 
of the LSP state, use the show mpls Isp command. If the LSP is down, use the extensive option (show mpls 
Isp extensive) as a follow-up. If your network has numerous LSPs, you might consider specifying the name 
of the LSP, using the name option (show mpls Isp name name or show mpls Isp name name extensive). 


Action 


To determine whether the LSP is up, enter the following command from the ingress router: 


user@host> show mpls Isp extensive 


Sample Output 1 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


100.046 
From: 10.0.0.1, State: Dn, ActiveRoute: 0, LSPname: R1-to-R6 
ActivePath: (none) 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





Primary State: Dn 
2 Oct 27 15:06:05 10.1.13.2: NoRoutetowarddest [4 times] 
INOCE SZ MUS 0S) Son Ontc inate Cala: 
Created: Wed Oct 27 15:05:55 2004 

Total 1 displayed, Up 0, Downi1 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


user@R3> show mpls Isp extensive 
Ingress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Transit LSP: 0 sessions 
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Total 0 displayed, Up 0, Down 0 


user@R6> show mpls Isp extensive 


Ingress LSP: 1 sessions 


10 60.@.1 
From: 10.0.0.6, State: Dn, ActiveRoute: 0, LSPname: R6-to-R1 
ActivePath: (none) 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





Primary State: Dn 
Will be enqueued for recomputation in 22 second(s). 
1 Oct 27 14:59:12 CSPF failed: no route toward 10.0.0.1 [4 times] 
Created: Wed Oct 27 14:57:44 2004 

Total 1 displayed, Up 0, Downli 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 

The sample output shows that the LSP is down in both directions, from R1 to R6, and from R6 to R1. The 
output from R1 shows that R1 is using a no-cspf LSP since it tried to originate the call without being able 
to reach the destination. The output from R6 shows that the Constrained Shortest Path First (CSPF) 
algorithm failed, resulting in no route to destination 10.0.0.1. 


Verify RSVP Sessions 


Purpose 


When an RSVP session is successfully created, the LSP is set up along the paths created by the RSVP 
session. If the RSVP session is unsuccessful, the LSP does not work as configured. 


Action 
To verify currently active RSVP sessions, enter the following command from the ingress, transit, and egress 
routers: 


user@host> show rsvp session 
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| Sample Output 1 


user@R1> show rsvp session 
Ingress RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Egress RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


user@R3> show rsvp session 
Ingress RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Egress RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


user@R6> show rsvp session 
Ingress RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Egress RSVP: O sessions 


Total 0 displayed, Up 0, Down 0 


Transit RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


| Sample Output 2 


user@R1> show rsvp session 


Ingress RSVP: 1 sessions 


To From State Rt Style Labelin Labelout LSPname 
LeOP OPO nG TOPO MOREL Up idk pig = 100768 R1-to-R6 
Total 1 displayed, Up1 =, Down 0 








Egress RSVP: 1 sessions 


TO From 

OP OR Opn OOM ORG 
Total 1 displayed, Up1 
Transit RSVP: 0 sessions 


Total 0 displayed, Up 0, 





user@R3> show rsvp session 
Ingress RSVP: 0 sessions 


Total 0 displayed, Up 0, 





Egress RSVP: O sessions 


Total 0 displayed, Up 0, 


Transit RSVP: 2sessions 


To From 
10,050.61 OPO ORG 
LOMO ORIG 10.0 50.1 





Total 2 displayed, Up2 


user@R6> show rsvp session 
Ingress RSVP: 1 sessions 


TO From 


10,050.61 IDO U.6 





Total 1 displayed, Up1 





Egress RSVP: 1 sessions 


© From 

OPO ROG OPO One) 
Total 1 displayed, Up1 
Transit RSVP: 0 sessions 


Total 0 displayed, Up 0, 





Meaning 


Sample Output 1 from all routers shows that no RSVP sessions were successfully created, even though 


the LSP R6-to-R11 is configured. 


In contrast to Sample Output 1and to illustrate correct output, Sample Output 2 shows the output from 
the ingress, transit, and egress routers when the RSVP configuration is correct, and the LSP is traversing 


State Rt Style Labelin Labelout LSPname 


Up 0 
, Down 0 
Down 0 
Down 0 
Down 0 
State Rt 
Up il 
Up it 
, Down 0 
State Rt 
Up iL 
, Down 0 
State Rt 
Up 0 
, Down 0 
Down 0 


ie 


Style 
EGE: 


pe 


Style 
dL ieee 


Style 
EGE 


3 


Labelin Labelout 


100784 
100768 


Labelin Labelout 


Labelin Labelout 


3 


3 
3 


100784 


R6-to-R1 


LSPname 
R6-to-R1 
R1-to-R6 


LSPname 


R6-to-R1 


LSPname 


R1-to-R6 
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the network as configured. R1 and R6 both show an ingress and egress RSVP session, with the LSP R1-to-R6, 
and the reverse LSP R6-to-R1. Transit router R3 shows two transit RSVP sessions. 


Verify RSVP Neighbors 


Purpose 

Display a list of RSVP neighbors that were learned dynamically when exchanging RSVP packets. Once a 
neighbor is learned, it is never removed from the list of RSVP neighbors unless the RSVP configuration is 
removed from the router. 


Action 


To verify RSVP neighbors, enter the following command from the ingress, transit, and egress routers: 


user@host> show rsvp neighbor 


| Sample Output 1 


user@R1> show rsvp neighbor 
RSVP neighbor: 1 learned 
Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd 


LO ods 4 10 1/0 GisZi2 9) 64/64 32 


user@R3> show rsvp neighbor 
RSVP neighbor: 2 learned 


Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd 
IO. , 1S, il OeA0 AS 3 A 9 190/190 41 
10 .1.36.2 16:50 1/1 IDs 37 9 105/78 38 


user@R6> show rsvp neighbor 
RSVP neighbor: 1 learned 
Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd 


LO) 5 Mg BOo ab 17s 30 1/1 L@gis 9) 104/78 39) 


| Sample Output 2 


user@R3> show rsvp neighbor 
RSVP neighbor: 2 learned 


Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd 
10. i. 135i 5 1/0 ea 9 63/63 33 
10.1. S662 5 1/0 M305 9 62/62 Be 


user@R6> show rsvp neighbor 
RSVP neighbor: 1 learned 


Address Idle Up/Dn LastChange HelloInt HelloTx/Rx MsgRcvd 
10k. 3Go1 5 1/0 8:54 9 61/61 32 
Meaning 


Sample Output 1 shows that R1 and R6 have one RSVP neighbor each, R3. However, the values in the 
Up/Dn field are different. R1 has a value of 1/0 and R6 has a value of 1/1, indicating that R1 is an active 
neighbor with R3, but R6 is not. When the up count is one more than the down count, the neighbor is 
active; if the values are equal, the neighbor is down. The values for R6 are equal, 1/1, indicating that the 
neighbor R3 is down. 


Transit router R3 knows about two neighbors, R1 and R6. The Up/Dn field indicates that R1 is an active 
neighbor and R6 is down. At this point it is not possible to determine if the problem resides with R3 or R6, 
because both neighbors are not active. 


In contrast to Sample Output 1 and to illustrate correct output, Sample Output 2 shows the correct neighbor 
relationship between transit router R3 and egress router R6. The Up/Dn field shows the up count to be 
one more than the down count, 1/0, indicating that the neighbors are active. 


Verify RSVP Interfaces 


Purpose 


Display the status of each interface on which RSVP is enabled to determine where the configuration error 
occurred. 


Action 


To verify the status of RSVP interfaces, enter the following command from the ingress, transit, and egress 
routers: 


user@host> show rsvp interface 
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| Sample Output 1 


user@R1> show rsvp interface 


RSVP interface: 3 active 

Active 
Interface State resv iption 
so-0/0/0.0 Up 0 100% 
SO= 0/10) Ale Ome 0 100% 
so-0/0/2.0 Up 0 100% 


user@R3> show rsvp interface 
RSVP interface: 3 active 


Active 
Interface State resv iption 
so-0/0/0.0 Up 0 100% 
sO-O/O/1.0 Up 0 100% 
so-0/0/2.0 Up 0 100% 


<<< Missing interface so-0/0/3.0 


user@R6> show rsvp interface 
RSVP interface: 4 active 


Active 
Interface State resv iption 
so-0/0/0.0 Up 0 100% 
Sm OV 0/0 mUD 0 100% 
Som 0/0 2i50 UD 0 100% 
so-0/0/3.0 Up 0 100% 


| Sample Output 2 


user@R1> show rsvp interface 


RSVP interface: 3 active 

Active Subscr— 
Interface State resv iption 
Sm OOF ORO mu 0 100% 
so-O/0/1,.0 Wis 0 100% 


SUloise ts molsc ene! 


BW 
TSS o2Miops 
155.52Mbps 


155.52Mbps 


Sulssexr— Sirarcrie 


BW 
LBS), SAMlsyorS 
[Soe Mbps 


ono! Maes 


SUlisers moc ene! 


BW 
LSS), SAMS OS 
155.52Mbps 
LOS), SAMISTOS 


155.52Mbps 


Stabe 

BW 
155.52Mbps 
155.52Mbps 


Available 
BW 

155, SAulgyos 
oro A Minos 


155.52Mbps 


Available 

BW 
155.52Mbps 
155.52Mbps 


155.52Mbps 


Available 
BW 
liso, a2 Mbps 
lion Mbps 
lio. 2 Mbps 


155.52Mbps 


Available 
BW 

155.52Mbps 
155). SAMloyors) 


Reserved 
BW 
Obps 
Obps 
Obps 


Reserved 
BW 
Obps 
Obps 
Obps 


Reserved 
BW 
Obps 
Obps 
Obps 
Obps 


Reserved 
BW 

Obps 
Obps 
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Highwater 
mark 
Obps 
Obps 
Obps 


Highwater 
mark 
Obps 
Obps 
Obps 


Highwater 


mark 
Obps 
Obps 
Obps 
Obps 


Highwater 
mark 
Obps 
Obps 


so—0/0/2.0' Up 1 100% 


user@R3> show rsvp interface 
RSVP interface: 4 active 


Active Subscr- Static 


Interface State resv iption BW 
so-0/0/0.0 Up 0 100% 155.52Mbps 
SO 0/10/ela OMS 0 100% 155.52Mbps 
SO-0/O/2.0 Ue 1 100% 155.52Mbps 
so-0/0/3.0 Up 1 100% 155.52Mbps 


user@R6> show rsvp interface 


RSVP interface: 4 active 
Active Subser-— Static 

Interface State resv iption BW 

SO> 0/10/00 MUS 0 100% 155.52Mbps 

SO 0/10 yale Ome 0 100% 155.52Mbps 

so-0/0/2.0 Up 0 100% 155.52Mbps 

so-0/0/3.0 Up 1 100% 155.52Mbps 
Meaning 


ono! Maas 


155.52Mbps 


Available 
BW 

155. SAvloyos) 
155.52Mbps 


155 5 SAMiloyos) 


1359) 5 SAMOS 


Available 
BW 

155.52Mbps 
155.52Mbps 
155), SAulyoOS 


[Soe Miles 


Obps 


Reserved 

BW 

Obps 

Obps 
Obps 


Obps 


Reserved 

BW 

Obps 

Obps 

Obps 
Obps 
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Obps 


Highwater 
mark 
Obps 
Obps 
Obps 


Obps 


Highwater 
mark 
Obps 
Obps 
Obps 
Obps 


Sample Output 1 shows that even though each router has interfaces that are up and have RSVP active, 


there are no reservations (Active resv) on any of the routers. In this example, we would expect at least 


one reservation on the ingress and egress routers, and two reservations on the transit router. 


In addition, interface so-0/0/3 on transit router R3 is not included in the configuration. The inclusion of 


this interface is critical to the success of the LSP. 


In contrast to Sample Output 1 and to illustrate correct output, Sample Output 2 shows the relevant 


interfaces with active reservations. 


Verify the RSVP Protocol Configuration 


Purpose 


After you have checked RSVP sessions, interfaces, neighbors, and determined that there might be a 


configuration error, verify the RSVP protocol configuration. 


Action 


To verify the RSVP configuration, enter the following command from the ingress, transit, and egress routers: 
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user@host> show configuration protocols rsvp 


| Sample Output 


user@R1> show configuration protocols rsvp 
interface so-0/0/0.0; 
interface so-0/0/1.0; 
interface so-0/0/2.0; 
interface fxp0.0 { 
disable; 


user@R3> show configuration protocols rsvp 
interface so-0/0/0.0; 
interface so-0/0/1.0; 
interface so-0/0/2.0; <<< Missing interface so-0/0/3.0 
interface fxp0.0 { 
disable; 


user@R6> show configuration protocols rsvp 

interface so-0/0/0.0; 

interface so-0/0/1.0 

interface so-0/0/2.0; 

interface so-0/0/3.0 

interface fxp0.0 { 
disable; 


Meaning 


The sample output shows that R3 has interface so-0/0/3.0 missing from the RSVP protocol configuration. 
This interface is critical for the correct functioning of the LSP. 


Take Appropriate Action 


Problem 
Description: Depending on the error you encountered in your investigation, you must take the appropriate 
action to correct the problem. In this example, an interface is missing from the configuration of router R3. 


Solution 
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To correct the error in this example, follow these steps: 


1. Include the missing interface in the configuration of transit router R3: 


user@R3> edit 

user@R3# edit protocols rsvp 

[edit protocols rsvp] 

user@R3# show 

user@R3# _ set interface so-0/0/3.0 


2. Verify and commit the configuration: 


[edit protocols rsvp] 
user@R3# show 
user@R3# commit 


Sample Output 


user@R3> edit 





Entering configuration mode 


[edit] 


user@R3# edit protocols rsvp 


[edit protocols rsvp] 
user@R3# show 
interface so-0/0/0.0; 
interface so-0/0/1.0; 
interface so-0/0/2.0; <<< Missing interface so-0/0/3.0 
interface fxp0.0 { 
disable; 
} 
[edit protocols rsvp] 


user@R3# set interface so-0/0/3.0 


[edit protocols rsvp] 

user@R3# show 

interface so-0/0/0.0; 

interface so-0/0/1.0; 

interface so-0/0/2.0; 

interface fxp0.0 { 
disable; 
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} 
interface so-0/0/3.0; <<< _ Interface now included in the configuration 


[edit protocols rsvp] 
user@R3# commit 


commit complete 


Meaning 

The sample output shows that the missing interface so-0/0/3.0 on transit router R3 is now correctly 
included at the [edit protocols rsvp] hierarchy level. This results in the possibility that the LSP might come 
up. 


Verify the LSP Again 


Purpose 
After taking the appropriate action to correct the error, the LSP needs to be checked again to confirm that 
the problem in the MPLS layer has been resolved. 


Action 


To verify the LSP again, enter the following command on the ingress, transit, and egress routers: 


user@host> show mpls Isp extensive 


| Sample Output 1 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


10 .0.0.56 
From: 10.0.0.1, State: Up, ActiveRoute: 1, LSPname: R1-to-R6 
ActivePath: (primary) 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


be 





Primary Staces We 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt) : 





AD stolss2 lO-l 36.52 
5 Oct 27 15:28:57 Selected as active path 
4 Oct 27 15:28:57 Record Route: 10.1.13.2 10.1.36.2 


3 Oce 27 IlSsZ2eso7 Wye 
2 Oct 27 15:28:44 10.1.13.2: No Route toward dest[35 times] 
l O@t 27 IScOS5e56 Originates Call 

Cyeerecls Wecl O@e 27 ISeO0Sss6 Z2OO4 


Total 1 displayed, Up 1, Down 0 





10.0.0.2 


From: 


Egress LSP: 1 sessions 


10.0.0.6, LSPstate: Up, ActiveRoute: 0 


LSPname: R6-to-Rl, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recov 


ry label received: -, Recovery label sent: 


Resv style: 1 FF, Label in: 3, Label out: - 





Ispecs 











Koyeciil il 


Transit 


Total 0 


Transit 





Total 0 


tilime iheitiec i136, Siamese wec Occ 27 15329s20 2004 


rate Obps size Obps peak Infbps m 20 M 1500 


Port number: sender 1 receiver 39092 protocol 0 
PAE ee engiacOmis ell pelo hm (SO 01/10/20) Gm kates 
Adspec: received MTU 1500 





PATH sentto: localclient 
RES Var CV ise Omen Oo Cankelmncints 
Necouel sources IO, 36.2 10,1, 13,2 <sellic> 


displayed, Up 1, Down 0 


LSP: O sessions 


displayed, Up 0, Down 0 


LSP: O sessions 


displayed, Up 0, Down 0 


| Sample Output 2 


user@R3> show mpls Isp extensive 


Ingress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 








Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 2 sessions 
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ORO R Oe 
From: 10.0.0.6, LSPstate: Up, ActiveRoute: 1 
LSPname: R6-to-Rl, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 
Resv style: 1 FF, Label in: 100672, Label out: 3 
ime lleites I52, Sameee Wee Oce 27 15siles3s 2004 





Tspec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 39092 protocol 0 
PAC HeeewertcOmi: sll Olas Grin (SO=01/10)/3 10) Mave kites 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.1.13.1 (so-0/0/2.0) 7 pkts 

SW wewtrems 1,1 13,1 (so-0/0/2,0) 7 jalzes 
legollete, mounees WO. i. is}, i 

RECOM Gove? LOL. 36,28 <seile> 10), 1,135.0 











ROP AOPOREG) 
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1 
LSPname: Rl-to-R6, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 
Resv style: 1 FF, Label in: 100656, Label out: 3 
Wiig llestes i129, Sameer wee Oce 27 I4égsgcia 2004 





Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 1 receiver 47977 protocol 0 
PATH revfirom: 10.1.13.1 (so-0/0/2.0) 40 pkts 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 10.1.36.2 (so-0/0/3.0) 7 pkts 

RE GWeeeeE GoM lO ls Gru SO= 01/10) 310) Mey kites 

Recoil mouees IO Lois. i <Seilke>S 10,1. 36,2 














Total 2 displayed, Up 2, Down 0 


| Sample Output 3 


user@R6> show mpls Isp extensive 


Ingress LSP: 1 sessions 


10.0.0. 1 
From: 10.0.0.6, State: Up, ActiveRoute:1 , LSPname: R6-to-R1 
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ActivePath: (primary) 
LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





= 


Primary State: Up 
Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 
10,1 536.1 S$ 10,1,13.1 § 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt) : 





10.21.36. 1O.t,13,1 
Oct 27 15:22:06 Selected as active path 
Oee 27 1Ss22°906 Reco iINomees IW,1o. 36.1 I@.1.tsel 
c 2Y laeZ2Z2206 We 
Gee 27 1Ss22506 OxeueilinatcSe Callil 
Oct 27 15:22:06 CSPF: computation result accepted 
ISOce 27 521i SouCSPH eamiled: = nomcoute Eoward ONO ;0n (S0meamesi 
Created: Wed Oct 27 14:57:45 2004 
Total 1 displayed, Up 1, Down 0 


DS COn eS Ci) 
(iS) 
Q 
t 








Egress LSP: 1 sessions 


10 .0.0.6 
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 0 
LSPname: Rl-to-R6, LSPpath: Primary 
Suggested label received: -, Suggested label sent: 








Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
time leites IG, Saimeee Wec Occ 27 153sBileds 2004 





Tspec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 47977 protocol 0 
PATH rev comsslO mes Gerla (SO> 01/10) 3210) eevmep kites 
Adspec: received MTU 1500 





PATH sentto: localclient 





RAG wewaraems docile llaveimnic 
Necomel inouices IO i, IS. TO,1,.S6,1 <seilic> 





otal 1 displayed, Up 1, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 


Sample Output 1 from ingress router R1 shows that LSP R1-to-Ré6 has an active route to R6 and the state 
is up. 
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Sample Output 2 from transit router R3 shows that there are two transit LSP sessions, one from R1 to R6 
and the other from R6 to R1. Both LSPs are up. 


Sample Output 3 from egress router R6 shows that the LSP is up and the active route is the primary route. 
The LSP is now traversing the network along the expected path, from R1 through R3 to R6, and the reverse 
LSP, from R6 through R3 to R1. 


Determining LSP Statistics 


Purpose 


Display detailed information about RSVP objects to assist the diagnosis of an LSP problem. 


Action 


To verify RSVP objects, enter the following Junos OS CLI operational mode command: 


user@host> show rsvp session detail 


| Sample Output 


user@R1> show rsvp session detail 


Ingress RSVP: 1 sessions 


10.0.0.6 
From: 10.0.0.1, LSPstate: Up, ActiveRoute: 1 
LSPname: Ri1-to-R6 , LSPpath: Primary 





Suggested label received: -, Suggested label sent: 
Recovery label received: -, Recovery label sent: 100064 
Resv style: 1 FF, Label in: -, Label out: 100064 

Time left: =, Simees wus Aug 17 I2s22652 2004 











[spec: rate Obps size Obps peak Infbps m 20 M 1500 


Port number: sender 12 receiver 44251 protocol 0 





PATH rcvfrom: localclient 

Adspec: sent MTU 1500 

PATH sentto: 10.1.13.2 (so-0/0/2.0) 182 pkts 
RES Vee nissOmMs ello r 2mm (Slo— Or/i0) een 0)) eles Oma kates 
ole mousse LO L.Itso2 LO... 364 

NoCome wows: <Selli> WO ,1,1s.2 LW,1. 56.2 











Total 1 displayed, Up 1, Down 0 





Egress RSVP: 1 sessions 


10.0.0.1 
From: 10.0.0.6 , LSPstate: Up, ActiveRoute: 0 
LSPname: R6-to-Rl, LSPpath: Primary 
Suggested label received: -, Suggested label sent: 








Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 

aime leities iIS5, Siimees woe Moi 17 I2srsoil4! 2004! 
Tspec: rate Obps size Obps peak Infbps m 20 M 1500 








Port number: sender 1 receiver 39024 protocol 0 
Nive weyers IO 15.2 (Se-0/0/i 0) Wag jokes 
Adspec: received MTU 1500 





PATH sentto: localclient 





RAG wewsreome llhoeallelaveimic 
Necouel iouices IO i, 56.2 10,1, 15,2 <seillic> 





Total 1 displayed, Up 1, Down 0 


Transit RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 


The sample output shows that there is one ingress and one egress RSVP session. The ingress session has 
a source address of 10.0.0.1 (R1), and the session is up, with one active route. The LSP name is R1-to-R6 
and it is the primary path for the LSP. 


The recovery label (100064) is sent by a graceful restart router to its neighbor to recover a forwarding 
state. It is probably the old label that the router advertised before it went down. 


This session is using the fixed filter (FF) reservation style (Resv style). Since this is an ingress router, there 
is no inbound label. The outbound label (provided by the next downstream router) is 100064. 


The Time Left field provides the number of seconds remaining in the RSVP session, and the Tspec object 
provides information about the controlled load rate (rate) and maximum burst size (peak), an infinite value 
(Infbps) for the guaranteed delivery option, and the indication that packets smaller than 20 bytes are 
treated as 20 bytes, while packets larger than 1500 bytes are treated as 1500 bytes. 


The port number is the IPv4 tunnel ID, while the sender/receiver port number is the LSP ID. The IPv4 
tunnel ID is unique for the life of the LSP, while the sender/receiver LSP ID can change, for example, with 
an SE style reservation. 


The PATH rcvfrom field includes the source of the path message. Since this is the ingress router, the local 
client originated the path message. 
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The PATH sentto field includes the path message destination (10.1.13.2) and outgoing interface (so-0/0/2.0). 
The RESV rcvfrom field includes both the source of the Resv message received (10.1.13.2) and the incoming 
interface (so-0/0/2.0). 


The RSVP explicit route and the route record values are identical: 10.1.13.2 and 10.1.36.2. In most cases, 
the explicit route and the record route values are identical. Differences indicate that some path rerouting 
has occurred, typically during Fast-Reroute. 


The Total fields indicate the total number of ingress, egress, and transit RSVP sessions, with the total being 
equal to the sum of the up and down sessions. In this example, there is one ingress session, one egress 
session, and no transit RSVP sessions. 


Verifying LSP Use in Your Network 


Purpose 


When you verify the valid use of an LSP on the ingress and transit routers in your network, you can 

determine if there is a problem with Multiprotocol Label Switching (MPLS) in your network. 

Figure 137 on page 1644 describes the example network used in this topic. 
Figure 137: MPLS Topology for Verifying LSP Use 

AS 65432 
a dD 50-0/0/3 s0-0/0/3 I> 
R2 | 24,1 24.2 | R4 
Tr oT 3 
(0/2 so-0/0/0 










































' so-0/ l 
ae $0-0/0/1 26 1 34.2 so-0/0/1 so-0/0/2 
ne 23.1 46.1 
= re s0-0/0/1 s0-0/0/1 R5 
or _ AB 15.2 100: .5 
~~ s0-0/0/1 s0-0/0/1 
-0/0/2 so-0/0/0 so-0/0/2 
ae 23,2 34.1 26.2 Lotte 
50-0/0/2 dora Re 
13.2 


015527 


Transit | | Egress 
lo0: .3 so-0/0/3 s0-0/0/3 \ Igg : | 
36.1 36.2 

Key: 


so-0/0/X: 10.1.x.x/30 
100: 10.0.0.x/32 








Physical connection 
- _LSP-bidirectional traffic 
Note: The IGP is IS-IS or OSPF 











The MPLS network in Figure 137 on page 1644 illustrates a router-only network with SONET interfaces that 
consist of the following components: 


e A full-mesh interior Border Gateway Protocol (IBGP) topology, using AS 65432 
e MPLS and Resource Reservation Protocol (RSVP) enabled on all routers 
e Asend-statics policy on routers R1 and Ré that allows a new route to be advertised into the network 


e An LSP between routers R1 and R6 
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The network shown in Figure 137 on page 1644 is a Border Gateway Protocol (BGP) full-mesh network. 
Since route reflectors and confederations are not used to propagate BGP learned routes, each router must 
have a BGP session with every other router running BGP. 


To verify LSP use in your network, follow these steps: 


1. Verifying an LSP on the Ingress Router | 1645 
2: Verifying an LSP ona Transit Router | 1646 


Verifying an LSP on the Ingress Router 


Purpose 


You can verify the availability of an LSP when it is up by examining the inet.3 routing table on the ingress 
router. The inet.3 routing table contains the host address of each LSP's egress router. This routing table 
is used on ingress routers to route BGP packets to the destination egress router. BGP uses the inet.3 
routing table on the ingress router to help resolve next-hop addresses. 


Action 
To verify an LSP on an ingress router, enter the following Junos OS command-line interface (CLI) operational 


mode command: 


user@host> show route table inet.3 


Sample Output 


user@R1> show route table inet.3 


inet.3: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 


10 .0.0.6/ 32 SIRSVE/ Te Aw cdieZ 2240S -eemet crclez0 
> via so-0/0/2.0, label-switched-path R1-to-R6 


Meaning 

The sample output shows the inet.3 routing table. By default, only BGP and MPLS virtual private networks 
(VPNs) can use the inet.3 route table to resolve next-hop information. One destination is listed in the route 
table, 10.0.0.6. This destination (10.0.0.6) is signaled by RSVP, and is the current active path, as indicated 
by the asterisk (*). The protocol preference for this route is 7, and the metric associated with it is 20. The 
label-switched path is R1-to-R6, through interface so-0/0/2.0, which is the physical next-hop transit 
interface. 


Typically, the penultimate router in the LSP either pops the packet’s label or changes the label to a value 
of O. If the penultimate router pops the top label and an IPv4 packet is underneath, the egress router routes 
the IPv4 packet, consulting the IP routing table inet.0 to determine how to forward the packet. If another 
type of label (such as one created by Label Distribution Protocol (LDP) tunneling or VPNs, but not IPv4) 
is underneath the top label, the egress router does not examine the inet.0 routing table. Instead, it examines 
the mpls.0 routing table for forwarding decisions. 


If the penultimate router changes the packet's label to a value of O, the egress router strips off the O label, 
indicating that an IPv4 packet follows. The packet is examined by the inet.O routing table for forwarding 
decisions. 


When a transit or egress router receives an MPLS packet, information in the MPLS forwarding table is 
used to determine the next transit router in the LSP or whether this router is the egress router. 


When BGP resolves a next-hop prefix, it examines both the inet.0O and inet.3 routing tables, seeking the 
next hop with the lowest preference; for example, RSVP preference 7 is preferred over OSPF preference 
10. The RSVP signaled LSP is used to reach the BGP next hop. This is the default when the BGP next hop 
equals the LSP egress address. Once the BGP next hop is resolved through an LSP, the BGP traffic uses 
the LSP to forward BGP transit traffic. 


Verifying an LSP ona Transit Router 


Purpose 


You can verify the availability of an LSP when it is up by examining the mpls.0 routing table on a transit 
router. MPLS maintains the mpls.0 routing table, which contains a list of the next label-switched router in 
each LSP. This routing table is used on transit routers to route packets to the next router along an LSP. 


Action 


To verify an LSP on a transit router, enter the following Junos OS CLI operational mode command: 


user@host> show route table mpls.0 


Sample Output 


user@R3> show route table mpls.0O 


mpls.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) 








+ = Active Route, Last Active, * = Both 
0 * [MPLS/0] 7w3d 22:20:56, metric 1 
Receive 





1 * [MPLS/0] 7w3d 22:20:56, metric 1 
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Receive 


2 * [MPLS/0] 7w3d 22:20:56, metric 1 
Receive 

100064 * [RSVP/7] 2wld 04:17:36, metric 1 
> via so-0/0/3.0, label-switched-path R1-to-R6 

100064 (S=0) * [RSVP/7] 2wld 04:17:36, metric 1 


> via so-0/0/3.0, label-switched-path R1-to-R6 


Meaning 


The sample output from transit router R3 shows route entries in the form of MPLS label entries, indicating 
that there is only one active route, even though there are five active entries. 


The first three MPLS labels are reserved MPLS labels defined in RFC 3032. Packets received with these 
label values are sent to the Routing Engine for processing. Label O is the IPv4 explicit null label. Label 1 is 
the MPLS equivalent of the IP Router Alert label and Label 2 is the IPvé6 explicit null label. 


The two entries with the 100064 label are for the same LSP, R1-to-R6. There are two entries because the 
stack values in the MPLS header may be different. The second entry, 100064 (S=0), indicates that the 
stack depth is not 1 and additional label values are included in the packet. In contrast, the first entry of 
100064 has an inferred S=1 which indicates a stack depth of 1 and makes it the last label in the packet. 
The dual entry indicates that this is the penultimate router. For more information on MPLS label stacking, 
see RFC 3032, MPLS Label Stack Encoding. 


The incoming label is the MPLS header of the MPLS packet, and is assigned by RSVP to the upstream 
neighbor. Juniper Networks routers dynamically assign labels for RSVP traffic-engineered LSPs in the range 
from 100,000 through 1,048,575. 


The router assigns labels starting at label 100,000, in increments of 16. The sequence of label assignments 
is 100,000, 100,016, 100,032, 100,048, and so on. At the end of the assigned labels, the label numbers 
start over at 100001, incrementing in units of 16. Juniper Networks reserves labels for various purposes. 
Table 36 on page 1647 lists the various label range allocations for incoming labels. 


Table 36: MPLS Label Range Allocations 


Incoming Label Status 

0 through 15 Reserved by IETF 

16 through 1023 Reserved for static LSP assignment 

1024 through 9999 Reserved for internal use (for example, CCC 
labels) 


10,000 through 99,999 Reserved for static LSP assignment 
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Table 36: MPLS Label Range Allocations (continued) 


Incoming Label Status 


100,000 through 1,048,575 Reserved for dynamic label assignment 


Verify That Load Balancing Is Working 


Purpose 

After configuring load balancing, check that traffic is load-balanced equally across paths. In this section, 
the command output reflects the load-balancing configuration of the example network shown in 
“Load-Balancing Network Topology” on page 167. The clear commands are used to reset LSP and interface 
counters to zero so that the values reflect the operation of the load-balancing configuration. 


Action 


To verify load balancing across interfaces and LSPs, use the following command on the ingress router: 


user@host# show configuration 


To verify load balancing across interfaces and LSPs, use the following commands on a transit router: 


user@host# show route 

user@host# show route forwarding-table 
user@host# show mpls Isp statistics 
user@host# monitor interface traffic 
user@host# clear mpls Isp statistics 
user@host# clear interface statistics 


| Sample Output 


The following sample output is for the configuration on ingress router R1: 


user@R1> show configuration | no-more 
Ls oo OWlcfowle, ciewiAGeEScl, . «| 
EO Misi OMe ko mnsan, 
Loc pOUNEE eieteioeeneScl. 4 « || 
forwarding-table { 


export Ibpp; 


Loc pOUlEOuIE eictioeacecl. . .] 
policy-options { 
policy-statement Ibpp { 
then { 


load-balance per-packet; 


Meaning 


The sample output for the show configuration command on ingress router R1 shows that load balancing 
is correctly configured with the lbpp policy statement. Also, the Ibpp policy is exported into the forwarding 
table at the [edit routing-options] hierarchy level. 


Sample Output 


The following sample output is from transit router R2: 


user@R2> show route 192.168.0.1 terse 


inet.0: 25 destinations, 27 routes (25 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 
A Destination I \2ieie Metric 1 Metric 2 Next hop AS path 
“ 192), 168.0. 1/32 © ie 5 so-0/0/1.0 


>so-0/0/2.0 
Loc cOWUlcjoule eieloezIcSCl. 5. | 


Meaning 

The sample output for the show route command issued on transit router R2 shows the two equal-cost 
paths (so-0/0/1 and so-0/0/2) through the network to the loopback address to RO (192.168.0.1). Even 
though the right angle bracket (>) usually indicates the active route, in this instance it does not, as shown 
in the following four sample outputs. 


Sample Output 


The following sample output is from transit router R2: 


user@R2> monitor interface traffic 


R2 Seconds: 65 Wimes iie Ail gaa 
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Interface 
so-0/0/0 
Som aOvell 
SO=—0/ O72 
so-0/0/3 
fe-0/1/0 
fe-0/1/1 
fe-0/1/2 
fe-0/1/3 
loo pOUNEOuIE icine aicecl. ..] 


Meaning 


Link 


U 








U 


me} lo} te} Mo} Mo} te} Tt) 


p 


Input packets 
0 

LAG 

a2 18) 

0 

328954 

0 

0 

0 
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Output packets (pps) 
0 (0) 

164659 G28) 

164598 (2128) 

0 (0) 

85475 (1094) 

0 (0) 

0 (0) 

0 (0) 


The sample output for the monitor interface traffic command issued on transit router R2 shows that 


output traffic is evenly distributed across the two interfaces so-0/0/1 and so-0/0/2. 


Sample Output 


The following sample output is from transit router R2: 


user@R2> show mpls Isp statistics 


LinGieess IS) 


0 sessions 


Total 0 displayed, Up 0, Down 0 








Meaning 





Transit 
To 

192,168. 
192,168. 
AOD 5 WOKS) 
1925168). 
1925168. 
Total 5 


Cees ISIS 


IbyS2 2 


Cr oe es 
PoP RP PR 


5 dl 


0 sessions 


Total 0 displayed, Up 0, Down 0 


5 sessions 


From 


LZ 
LQ2 
12 
192. 
126 


168. 
168. 
168. 
IGS) 5 
IGS 5 


Or FPF FP RB 
PoP RP PR 


5 dl 


displayed, Up 5, Down 0 


State 
Up 
Up 
Up 
Up 
Up 


PEGIREte S) 
87997 
87997 
87997 
87997 

0 


Bytes LSPname 
17951388 Isp1 
17951388 Isp2 
17951388 Isp3 
17951388 Isp4 
ORO ral: 


The sample output for the show mpls Isp statistics command issued on transit router R2 shows that output 


traffic is evenly distributed across the four LSPs configured on ingress router R6. 
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Sample Output 


The following sample output is from transit router R2: 


user@R2> show route forwarding-table destination 10.0.90.14 


Routing table: inet 





LIMESNEINEIC 8 
Destination Type RtRef Next hop Type Index NhRef Netif 
OPO peo OP e293 10) user 0 ulst 262144 6 
ucst 345 5so0-0/0/1.0 
ucst 339 2s0-0/0/2.0 
Meaning 


The sample output for the show route forwarding-table destination command issued on transit router R2 
shows ulst in the Type field, which indicates that load balancing is working. The two unicast (ucst) entries 
in the Type field are the two next hops for the LSPs. 


Sample Output 


The following sample output is from transit router R2: 


user@R2> show route forwarding-table | find mpls 


Routing table: mpls 








MPLS 

Destination Type RtRef Next hop Type Index NhRef Netif 

default perm 0 dscd Se 1 

0 user 0 recv 37 3 

Ws cus 0 recv 31 3 

oD user 0 recv 37 3 

OOM user 0 Swap 100032 so-0/0/1.0 

100128 user 0 Swap 100048 Som OV AOL alee) 

100144 user © 10,0,.12.,13 Swap 100096 fe-0/1/0.0 

100160 user 0 Swap 100112 so-0/0/2..0 

100176 user 0 Swap 100128 Son Oy 0720 
Meaning 


The sample output for the show route forwarding-table | find mpls command issued on transit router R2 
shows the MPLS routing table that contains the labels received and used by this router to forward packets 
to the next-hop router. This routing table is used mostly on transit routers to route packets to the next 
router along an LSP. The first three labels in the Destination column (Label 0, Label 1, and Label 2) are 
automatically entered by MPLS when the protocol is enabled. These labels are reserved MPLS labels 
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defined in RFC 3032. Label O is the IPv4 explicit null label. Label 1 is the MPLS equivalent of the IP Router 
Alert label, and Label 2 is the IPv6 explicit null label. 


The remaining five labels in the Destination column are nonreserved labels that the router uses to forward 
traffic, and the last column Netif, shows the interfaces used to send the labeled traffic. For nonreserved 
labels, the second Type column shows the operation performed on matching packets. In this example, all 
non-reserved packets are swapped for outgoing packet labels. For example, packets with the label 100112 
have their label swapped for 100032 before they are pushed out of interface so-0/0/1.0. 


Verify the Operation of Uneven Bandwidth Load Balancing 


Purpose 


When a router is performing unequal-cost load balancing between LSPs paths, the show route detail 
command displays a balance field associated with each next hop being used. 


Action 


To verify that an RSVP LSP is unevenly load-balanced, use the following Junos OS CLI operational mode 
commands: 


user@host> show route protocol rsvp detail 
user@host> show mpls Isp statistics 


| Sample Output 


user@R1> show route protocol rsvp detail 


inet.0: 25 destinations, 25 routes (25 active, 0 holddown, O hidden) 
OM OR SORA So (ier entery ae leanmouneed)) 
State: <FlashAll> 


*RSVP Preference: 7 





Next-hop reference count: 7 

Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 10% 
Label-switched-path Isp1 

Label operation: Push 100768 

Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 20% 
Label-switched-path Isp2 

Label operation: Push 100736 





Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 _ balance 30%, 


selected 


Label-switched-path Isp3 


aLIMSIE 4 SIE 


1 destinations, 
192,168 .0,1/32 
Sieciees 
ARG W/P 
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Label operation: Push 100752 
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 40% 
Label-switched-path Isp4 
Label operation: Push 100784 
State: <Active Int> 
Local AS: 65432 
Age: 8:03 Metric: 4 
WZSIe8 NSW?’ 
Announcement bits (2): O-KRT 4-Resolve tr 1 
AS jORNcIAg I 
1 routes (1 active, 0 holddown, O hidden) 


(1 entry, 1 announced) 
<FlashAll> 
Preference: 7 


Coumes 7 





Next-hop referenc 
Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 10 
Label-switched-path lspl 

Label operation: Push 100768 

Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0xl balance 20 
Label-switched-path lsp2 

Label operation: Push 100736 

Next hop: 10.0.12.14 via fe-0/1/0.0 weight 0x1 balance 30 
Label-switched-path lsp3 

Label operation: Push 100752 


Next hop: 10.0.12.14 via fe-0/1/0.0 weight Oxl balance 40%, 








Label-switched-path l1sp4 


Label operation: Push 100784 





user@R1> show mpls Isp statistics 


INS SSSis} ISIE? 


fe) 

LZ. 
LQ) 5 
12. 





Total 4 


168. 
168. 
168. 
192 Les. 


0 
0 
0 
0 


displayed, Up 4, 


PoP oR 


o dl 


z 


© 


z 


© 


z 


© 


selected 


State: <Active Int> 

Local AS: 65432 

Age: 8:03 Metric: 4 

WASIe8 NS Wile’ 

Announcement bits (1): 1-Resolve tree 1 

NS jOeNEIAg IE 

4 sessions 

From State Packets Bytes LSPname 

192,168,151 Up 10067 845628 Isp1i 

192 UGS}, . 1 Up 20026 1682184 Isp2 

12, 158} 1 A Up 29796 2502864 Isp3 

192, 1O) 5 i, 1 Up 40111 3369324 Isp4 
Down 0 


Egress LSP: 1 sessions 





To From State 
192,168. 1.1 192, 168.0. 1 Up 
Total 1 displayed, Up 1, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 


Packets 
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Bytes LSPname 
INFACT OS tale 


The sample output from ingress router R1 shows that traffic is distributed according to the LSP bandwidth 
configuration, as indicated by the Balance: xx% field. For example, Isp1 has 10 Mbps of bandwidth 


configured, as reflected in the Balance: 10% field. 


Use the traceroute Command to Verify MPLS Labels 


Purpose 


You can use the traceroute command to verify that packets are being sent over the LSP. 


Action 


To verify MPLS labels, enter the following Junos OS CLI operational mode command, where host-name is 


the IP address or the name of the remote host: 


user@host> traceroute host-name 


| Sample Output 1 


user@R1> traceroute 100.100.6.1 


ERACSEOUrC EO LOO MOOG (LOO L0OMGe)F sO hops 


do UMol,las2 ClO ,tstIa.2) OWs8Gl ms O. 7s ims 
MPLS Label=100048 CoS=0 TTL=1 S=1 
A Ae 2h, 2 COs 24oA) W.tee is 
MPLS Label=100016 CoS=0 TTL=1 S=1 


3 UO LAG 2 CLO.1,.46.42) OW.S7l ims UN 


O.73L ims 


0.547 


max, 40 byte packets 


sO 7S) ims 


PO Cmins 


WN O.532 mis VIN 
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| Sample Output 2 


user@R1> traceroute 10.0.0.6 

traceroute to 10.0.0.6 (10.0.0.6), 30 hops max, 40 byte packets 
Lt dOeto.ts.2 (20,1,13.2) 0,605 ms O,549 ms 0.505 ms 

2 10.0,.0.6 (10.0.0,6) O.761 ms 0,676 ms O.675 ms 


Meaning 

Sample Output 1 shows that MPLS labels are used to forward packets through the network. Included in 
the output is a label value (MPLS Label=100048), the time-to-live value (TTL=1), and the stack bit value 
(S=1). 


The MPLS Label field is used to identify the packet to a particular LSP. It is a 20-bit field, with a maximum 
value of (2**20-1), or approximately 1,000,000. 


The TTL value contains a limit on the number of hops that this MPLS packet can travel through the network 
(1). It is decremented at each hop, and if the TTL value drops below one, the packet is discarded. 


The bottom of the stack bit value (S=1) indicates that is the last label in the stack and that this MPLS packet 
has one label associated with it. The MPLS implementation in the Junos OS supports a stacking depth of 
3 on the M-series routers and up to 5 on the T-series platforms. For more information on MPLS label 
stacking, see RFC 3032, MPLS Label Stack Encoding. 


MPLS labels appear in Sample Output 1 because the traceroute command is issued to a BGP destination 
where the BGP next hop for that route is the LSP egress address. The Junos OS default behavior uses 
LSPs for BGP traffic when the BGP next hop equals the LSP egress address. 


Sample Output 2 shows that MPLS labels do not appear in the output for the traceroute command. If the 
BGP next hop does not equal the LSP egress address or the destination is an IGP route, the BGP traffic 
does not use the LSP. Instead of using the LSP, the BGP traffic is using the IGP (IS-IS, in this case) to reach 
the egress address (R6). 


Troubleshooting GMPLS and GRE Tunnel 


Problem 

Description: The logical control channel for GMPLS must be a point-to-point link and must have some 
form of IP reachability. On broadcast interfaces or when there are multiple hops between control channel 
peers, use a GRE tunnel for the control channel. For more detailed information on GMPLS and GRE tunnels 
see the Junos MPLS Applications Configuration Guide and the Junos User Guide. 

A tunnel PIC is not required to configure a GRE tunnel for the GMPLS control channel. Instead, use the 
software-based gre interface, rather than the hardware-based gr-fpc/pic/port interface. 
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, 


4 

CAUTION: Due to restrictions to the software-based gre interface, the GMPLS control 

A channel is the only supported use of the software-based gre interface. Any other use 
is expressly unsupported and might cause an application failure. 


The following example shows a basic gre interface configuration. In this case, the tunnel source is the 
loopback address of the local router and the destination address is the loopback destination of the remote 
router. Traffic that has a next hop of the tunnel destination will use the tunnel. The tunnel is not 
automatically used by all the traffic passing through the interface. Only traffic with the tunnel destination 
as the next hop uses the tunnel. 


Sample Output 


user@R1> show configuration interfaces 


lsc pOUEOUIE icine Acecl. . 4] 


gre { 
Binaic O 4 
tunnel { 
source 100 i271 Ss. 
CSsietineicaem 10) ,12, las 
} 
family inet { 
aACceasS 10.35.11 .,6/ 30 
} 
family mpls; 
} 
} 
Sample Output 


The following sample output for the show interfaces command shows the encapsulation type and header, 
the maximum speed, packets through the logical interface, the destination, and logical address. 


user@R1> show interfaces gre 
Physical interface: gre, Enabled, Physical link is Up 
Interface index: 10, SNMP ifIndex: 8 





Type: GRE, Link-level type: GRE, MTU: Unlimited, Speed: Unlimited 





Device flags : Present Running 

Interface flags: Point-To-Point SNMP-Traps 
Input packets : 0 
Output packets: 0 
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Logical interface gre.0 (Index 70) (SNMP ifIndex 47) 
Flags: Point-To-Point SNMP-Traps 0x4000 
IP-Header 10.0.12.14:10.0.12.13:47:df:64:0000000000000000 


Encapsulation: GRE-NULL 

Input packets : 171734 

Output packets: 194560 

POteo C Oleic iter mM Ui AUIIG 
Flags: None 





Addresses, Flags: Is-Preferred Is—Primary 
Destination: 10.35.1.4/30, Local: 10.35.1.6, Broadcast: 10.35.1.7 
Protocol mpls, MTU: 1464 
Flags: None 


The following are various requirements when you configure a GMPLS LSP using a GRE tunnel: 


e The data channel must start and end on the same type of interface. 
e The control channel can be a GRE tunnel that starts and ends on the same or different interface type. 


e The GRE tunnel must be configured indirectly with the peer-interface peer-name statement at the [edit 
protocol ospf] hierarchy level. 


e The GRE interface must be disabled at the [edit protocols ospf] and [edit protocols rsvp] hierarchy levels. 
e Data and control channels must be defined correctly in the LMP configuration . 


e It is optional to disable Constrained Shortest Path First (CSPF) with the no-cspf statement. 


This case focuses on the incorrect configuration of the endpoints of the GRE tunnel. However, you can 
use a similar process and commands to diagnose other GRE tunnel problems. Figure 138 on page 1657 
illustrates a network topology with MPLS tunneled through a GRE interface. 


Figure 138: GMPLS Network Topology 
90.90.90.90 te-tester2 100.100.100.100 103.103.103.103 te-tester3 93.93.93.93 
oO ie S20 I 1a pK. 8000/1, 242 Date Channel 
Ri 112.13 fe-0/1/0 12.14 R2 24.13 fe-0/1/2 .24.13/ R3 
Ingress Transit Egress 
Ts ee pen Selo SOT. ete aan, ee @ Control Channel 


Isp: gmpls-r1-to-r3 














Key: 

100: 192.168.x.1 
xX-X/X/x: 10.0.X.X 
gre.x: 10.35.1.x 


016760 


The MPLS network topology in Figure 138 on page 1657 shows Juniper Networks routers configured with 
a GRE tunnel that consists of the following components: 
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e A strict GMPLS LSP path from the ingress router to the egress router. 


e On the ingress router, CSPF disabled with the no-cspf statement at the [edit protocol mpls 
label-switched-path Isp-name] hierarchy level. 


e Traffic-engineering links and control channels within the peer statement at the [edit protocols 
link-management] hierarchy level on all routers. 


e OSPF and OSPF traffic engineering configured on all routers. 
e Areference to the peer-interface in both OSPF and RSVP on all routers. 


e Aswitching-type problem between R2 and R3. 


Symptom 

The LSP in the network shown in Figure 138 on page 1657 is down, as indicated by the output from the 
show mpls Isp and show rsvp session commands, which display very similar information. The show mpls 
Isp command shows all LSPs configured on the router, as well as all transit and egress LSPs. The show rsvp 
session command displays summary information about RSVP sessions. You can use either command to 
verify the state of the LSP. In this case, LSP gmpls-r1-to-r3 is down (Dn). 


Sample Output 


user@R1> show mpls Isp 


Ingress LSP: 1 sessions 


To From State Rt ActivePath P LSPname 
192.168.4.1 192.168.1.1 Dn 0O- gmpls-ri-to-r3 
Bidir 


Total 1 displayed, Up 0, Down 1 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


user@R1> showrsvp session 


Ingress RSVP: 1 sessions 


To From State Rt Style Labelin Labelout LSPname 
192.168.4.1 192168.1.1 Dn OO- - - gmpls-ri-to-r3 
Bidir 


Total 1 displayed, Up 0, Down 1 





Egress RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Cause 


The cause of the problem with the GMPLS LSP is the configuration of different interface types at both 
ends of the GMPLS data channel. 


Troubleshooting Commands 


The Junos OS includes commands that are useful when troubleshooting a problem. This topic provides a 
brief description of each command, followed by sample output, and a discussion of the output in relation 
to the problem. 


You can use the following commands when troubleshooting a GMPLS problem: 


user@host> show mpls Isp extensive 
user@host> show rsvp session detail 
user@host> show link-management peer 
user@host> show link-management te-link 
user@host> show configuration protocols mpls 
user@host> monitor start filename 

user@host> show log filename 


Sample Output 


Use the show mpls Isp extensive command on transit router R1 to display detailed information about all 
LSPs transiting, terminating, and configured on the router. 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


UG 5 AGS) 64g AL 
weoeme IZ iGo, Sireices win, ANclesweiommees 0, Insieimeimes copiisilecqwil—ice@ ie 3} 
Bidirectional 
ActivePath: (none) 

LoadBalance: Random 


Encoding type: SDH/SONET, Switching type: PSC-1, GPID: IPv4 








Primary pl State: Dn 
SmartOptimizeTimer: 180 

8 Dec 20 18:08:02 192.168.4.1: MPLS label allocation failure [3 times] 
7 wee 20 ISsO07sas Oracaimece Cail 

6 Dee 20 IseW7ess Clear Cail 

5 Dec 20 18:07:53 Deselected as active 
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4 Dec 20 18:06:13 Selected as active path 
3 Dee 2OQ LesOosls Recowe Reouwces  LOO.1O0O.100.100 93.93.93 .92 
2 Dec 20 IssO@sis Ue 
1 Dec 20 18:06:13 Originate Call 
Created: Wed Dec 20 18:06:12 2006 
Total 1 displayed, Up 0, Down 1 





Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 

The sample output for the show mpls Isp extensive command shows an error message (MPLS label 
allocation failure) in the log section of the output. This LSP event indicates that the MPLS protocol or the 
family mpls statement were not configured properly. When the LSP event is preceded by an IP address, 
the address is typically the router that has the MPLS configuration error. In this case, it appears that the 
router with the loO address of 192.168.4.1 (R3) has an MPLS configuration error. 


Sample Output 


Use the show rsvp session detail command to display detailed information about RSVP sessions. 


user@R1> show rsvp session detail 


Ingress RSVP: 1 sessions 


192,168.41 
From: 192.168.1.1, LSPstate:Dn, ActiveRoute: 0 
LSPname: gmpls-r1-to-r3, LSPpath: Primary 
Bidirectional, Upstream label in: 21253, Upstream label out: - 





Suggested label received: -, Suggested label sent: 21253 





Recovery label received: , Recovery label sent: 








Resv style: 0 , inate ame =, ialoel @uies = 
Time left: 7 Silimeas Wee Wee 20 ISsO7s53 LOWS 
Tspec: rate Obps size Obps peak 155.52Mbps m 20 M 1500 








Port number: sender 2 receiver 46115 protocol 0 





PATH revfrom: localclient 

Adspec: sent MTU 1500 

Path MIU: received 0 

PAGH Sento UOn comin om(tesicen2 MS e pies 


Explct route: 100.100.100.100 93.93.93.93 
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Record route: <self> ...incomplete 
Total 1 displayed, Up 0, Down 1 


Egress RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Transit RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 

The sample output for the show rsvp session detail command shows that LSP gmpls-r1-to-r3 is down 
(LSPstate: Dn). The route record is incomplete, indicating a problem with the explicit route 100.100.100.100 
93.93.93.93. The address 100.100.100.100 is the data channel on R2 so-0/0/0, and the address 93.93.93.93 
is the data channel on R3. 


Sample Output 


Use the show link-management peer command to display MPLS peer link information. 


user@R1> show link-management peer 
Peer name: tester2, System identifier: 48428 


State: Up, Control address: 10.35.1.5 


Control-channel State 
gre.0 Active 
ama, Ilalialesse 

tester2 





user@R2> show link-management peer 
Peer name: tester2, System identifier: 48428 


State: Up, Control address: 10.35.1.6 


Control-channel State 
gre.0 Active 
im, ILalinkes\€ 





te-tester2 


Peer name: tester3 , System identifier: 48429 
Stave Up, Conte roladdnesis= OM sole 


Control-channel State 
ieee Active 
im, ILalinkes\¢ 





te-tester3 
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user@R3> show link-management peer 
Peer name: tester3, System identifier: 48429 


State: Up, Control address: 10.35.1.1 


Control-channel State 
gre.0 Active 
ibm, Ialinesy< 





te-tester3 


Meaning 

The sample output from all routers in the example network in Figure 138 on page 1657 for the show 
link-management peer command shows that all control channels are up and active. A detailed analysis of 
the output shows the following information: 


e Name of the peer, tester2 or tester3, which is the same on neighboring routers for ease of troubleshooting. 


e Internal identifier for the peer, 48428 for tester2 and 48429 for tester3. The internal identifier is a range 
of values from O through 64,000. 


e The state of the peer, which can be up or down. In this case, all peers are up. 
e The address to which a control channel is established, for example, 10.35.1.5. 
e The state of the control channel, which can be up, down, or active. 


e The traffic-engineered links that are managed by their peer, indicating that control channel gre.0 is 
managed by tester3. 


Sample Output 


Use the show link-management te-link command to display the resources used to set up Multiprotocol 
Label Switching (MPLS) traffic-engineered forwarding paths. 


user@R1> show link-management te-link 


TE link name:  tester2, State: Up 

Local identifier: 2005, Remote identifier: 21253, Local address: 90.90.90.90, 
Remouesaddize sisi HOOF 10.00 OF 0 0} 

Encoding: SDH/SONET, Switching: PSC-1, Minimum bandwidth: 155.52Mbps, Maximum 
bandwidth: 155.52Mbps, Total bandwidth: 155.52Mbps, 

Available bandwidth: Obps 














Name State Local ID Remote ID Bandwidth Used LSP-name 
so-0/0/0 Up 21253 21253 155.52Mbps Yes gmpls-ri-to-r3 


user@R2> show link-management te-link 
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TE link name:  te-tester2, State: Up 
Local identifier: 7002, Remote identifier: 22292, Local address: 100.100.100.100, 








Remote address: 90.90.90.90, 
Encoding: SDH/SONET, Switching: PSC-1, Minimum bandwidth: 155.52Mbps, Maximum 





bandwidth: 155.52Mbps, Total bandwidth: 155.52Mbps, 
Available bandwidth: Obps 





Name State Local ID Remote ID Bandwidth Used LSP-name 
so-0/0/0 Up 2125 3} 2258 155.52Mbps Yes Gujoils—e il cei s} 


TE link name:  te-tester3, State: Up 
Local identifier: 7003, Remote identifier: 21254, Local address: 103.103.103.103, 








Remote address: 93.93.93.93, 
Encoding: SDH/SONET, Switching: PSC-1, Minimum bandwidth: 155.52Mbps, Maximum 





bandwidth: 155.52Mbps, Total bandwidth: 155.52Mbps, 
Available bandwidth: Obps 





Name State Local ID Remote ID Bandwidth Used LSP-name 
so-0/0/1 Up 2252 2252 155.52Mbps Yes gmpls-ri-to-r3 


user@R3> show link-management te-link 


TE link name: te-tester3, State: Up 





Local identifier: 7003, Remote identifier: 21254, Localaddress: 93.93.93.93, 





Remote address: 103.103.103.103, 
Encoding: SDH/SONET, Switching: PSC-1, Minimum bandwidth: Obps, Maximum bandwidth: 








Obps, Total bandwidth: Obps, 
Available bandwidth: Obps 


Name State Local ID Remote ID Bandwidth Used LSP-name 
so-0/0/1 Dn BIDE DIADBS2 155.52Mbps No 
Meaning 


The sample output for the show link-management te-link command issued on the three routers in the 
network in Figure 138 on page 1657 shows the resources allocated to the traffic-engineered links te-tester2 
and te-tester3. The resources are the SONET interfaces so-0/0/0 and so-0/0/1. On R1 and R2, the SONET 
interfaces are used for the LSP gmpls-r1-to-r3, as indicated by Yes in the Used field. However, the SONET 
interface so-0/0/1 on R3 is down (Dn) and is not used for the LSP (Used No). Further investigation is 
required to discover why the SONET interface on R3 is down. 


Sample Outut 


Use the show log filename command to display the contents of the specified log file. In this case, the log 
file rsvp.log is configured at the [edit protocols rsvp traceoptions] hierarchy level. When the log file is 


configured, you must issue the monitor start filename command to begin logging messages to the file. 


user@R1> show configuration protocols rsvp 
traceoptions { 
file rsvp.log size 3m world-readable; 
flag state detail; 
flag error detail; 


flag packets detail; 


user@R1> monitor start rsvp.log 


NOTE: The find Error option entered after the pipe (|) searches the output for an instance of 
the term Error. 


Sample Output 


user@R3> 
show log rsvp.log | find Error 


Dec 28 17:23:32 Error Len 20 Session preempted flag 0 by 192.168.4.1 TE-link 
1035103. 103.103 





[Our DUE ME rEunecatedt s| 


Dec 28 17:23:32 RSVP new resv state,session 192.168.4.1(port/tunnel ID 46115 Ext-ID 





Loo 168.1 1) Proto 0 
Dee Zoey eZ s i352 RSVP-LMP reset LMP request for gmpls-rl-to-r3 
Deer Zo e2832 RSVP->LMP request ASS CUES IOs IWS Cpqjolliss—se ll lee —ie 3} 





Dec 28 17:23:32 LMP->RSVP resource request gmpls-r1-to-r3 failed cannot find resource encoding type 


SDH/SONET remote label 21252 bandwidth bw[0 

Dec 28 17:23:32 RSVP-LMP reset LMP request for gmpls-r1-to-r3 

Dec 28 17:23:32 RSVP originate PathErr 192.168.4.1->192.168.2.1 MPLS label allocation failure LSP 
gmpls-r1-to-r3(2/46115) 

Dec 28 17:23:32 RSVP send PathErr 192.168.4.1->192.168.2.1 Len=196 tester3 


DES 28 17325832 Session7 Len 16 192.168.4.1(port/tunnel ID 46115 Ext-ID 
1 os: Ly) ee rore: 10 











DEC 28 LISA S8 Sz Hop Len 20 192.168.4.1/0x086e4770 TE-link 103.103.103.103 








DEC 28 7/s23es2 para @rs Len 20 MPLS label allocation failure flag 0 by 
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192,168.4.1 Ya-link 103.103.105.103 
DEG 2s LIR238 32 Sender7 Len 12 192.168.1.1(port/lsp ID 2) 
Dec 28 17g 23332 Tspec Len 36 rate Obps size Obps peak 155.52Mbps m 20 M 1500 
Dysxe! Bis) L/S 8 eye ADspec Len 48 MTU 1500 
Dee 2 U/e2z3es2 RecRoute Len 20 103.103.103.103 90.90.90.90 
DSS Zi LIS23R32 Sugghabel Len 8 21252 
DECeZe ai 2s s2 UpstrLabel Len 8 21252 
Meaning 


The sample output from the egress router R3 for the show log rsvp.log command is a snippet taken from 


the log file. The snippet shows a Link Management Protocol (LMP) resource request for the LSP 
gmpls-r1-to-r3. The request has problems with the encoding type (SDH/SONET), indicating a possible 
error with the SONET interface connecting R2 and R3. Further investigation of the configuration of the 
LMP on R2 and R3 is required. 


Sample Output 


Use the show configuration statement-path command to display a specific configuration hierarchy; in this 


instance, link-management. 


user@R2> show configuration protocols link-management 





te-link te-tester2 { 

local addcsismy OOP OOre nO. Ors ROO, 

remote-address 90.90.90.90; 

remote-id 22292; 

interface so-0/0/0 { 
local address M00 RI00 STU 0s 00), 
remote-address 90.90.90.90; 
remote-id 21253; 


} 
te-link te-tester3  { 
locel—ackizass IOs). Ws. 10S. 10s 
remote-address 93.93.93.93; 
remote-id 21254; 
interface so-0/0/1_ { 
local adcisesicmlOS eran mkOs mrlkO sy, 
remote-address 93.93.93.93; 
MSMOES—wCl LILA 


} 


peer tester2 { 
address 10.35.1.6; 


control-channel gre.0; 





ce=lLime cteceasire@ieZp 

} 

peer tester3 { 
AGC SismllOres Sipe: 
control-channel gre.1; 


te-link te-tester3; 





user@R3> show configuration protocols link-management 
te-link te-tester3 { 
local-address 95. 93.93.93; 
remote-address 103.103.103.103; 
remote-id 21254; 
} 
interface at-0/3/1 { 
local—-address 95.93.93.93; 
remote-address 103.103.103.103; 
SIMONE —ILCl DiLB 2) p 


} 
peer tester3 { 
acide sicnelOmrS Srwlens: 


control-channel gre.0; 





te-link te-tester3; 


Meaning 

The sample output from transit router R2 and ingress router R3 for the show configuration protocols 
link-management command shows that the interface type on the two routers is different. The resource 
allocated to te-tester3 on transit router R2 isa SONET interface, while the resource allocated to te-tester3 
on egress router R3 is an ATM interface. The interface type on each end of the data or control channels 
must be of the same type. In this case, both ends should be SONET or ATM. 


Solution 


Solution 

The solution to the problem of different interface or encapsulation types at either end of the GMPLS LSP 
is to make sure that the interface type is the same at both ends. In this case, the ATM interface was deleted 
from the link-management configuration on R3, and a SONET interface was configured instead. 


The following commands illustrate the correct configuration and commands to verify that the GMPLS LSP 
is up and using the data channel: 
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user@R3> show configuration protocols link-management 
user@R3> show mpls Isp 
user@R3> show link-management te-link 


Sample Output 


user@R3> show configuration protocols link-management 
te-link te-tester3 { 
local-address 93,93.93.93; 
remote-address 103.103.103.103; 
remote-id 21254; 





interface so-0/0/1 { # SONET interface replaces the incorrect ATM interface 
local—-address 93,93.93.93; 
LEMoOCe-acemess IOS. LOS. 10S. LOS 
emote tee 22525. 








} 

peer tester3 { 
acleieass, 10.35.51. ily 
control-channel gre.0; 


CeHlLimMle cS—casiceie 3p 





user@R3> show mpls Isp 
Ingress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Egress LSP: 1 sessions 





To From State Rt Style Labelin Labelout LSPname 
192.168.4.1 192.168.1.1 Up 0 1FF 21252 - gmpls-r1-to-r3 
Bakelsiers 


Total 1 displayed, Up 1, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


user@R3> show link-management te-link 

TE link name: te-tester3, State: Up 
Local identifier: 7003, Remote identifier: 21254, Local address: 93.93.93.93, 
Remowemaddisccisi me Ose Os ee tO Smelt Osr 
Encoding: SDH/SONET, Switching: PSC-1, Minimum bandwidth: 155.52Mbps, Maximum 
bandwidth: 155.52Mbps, Total bandwidth: 155.52Mbps, 

Available bandwidth: Obps 
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Name State Local ID Remote ID Bandwidth Used LSP-name 
so-0/0/1 Up 21252 21252 155.52Mbps Yes gmpls-ri-to-r3 


Meaning 

The sample output for the show protocols link-management, show mpls Isp, and show link-management 
te-link commands from ingress router R3 show that the problem is solved. LMP is correctly configured, 
and the LSP gmpls-r1-to-r3 is up and using the data channel so-0/0/1. 


Conclusion 
In conclusion, both ends of a GMPLS data channel must be the same encapsulation or interface type. This 
case illustrates the correct configuration of the data channel. The principles are the same for the control 


channel. 


Router Configurations 

Output that shows the configurations of the ingress router in the network. The no-more option entered 
after the pipe (|) prevents the output from being paginated if the output is longer than the length of the 
terminal screen. 


Sample Output 


The following sample output is for ingress router R1: 


user@R1> show configuration | no-more 

ls oo OWNEfowNE, cic GeEScl, . .] 

interfaces { 

so-0/0/0 { 
winwic © 4 
family inet { 
addnests Om Or l2eyll/.3 2a 
desitanaton OOM 32 


} 
family mpls; 


} 
fe-0/1/0 { 
winaic 0) 4 
family inet { 
acdizese 10.,0.12,13/ 305 
} 
family mpls; 


fxpoO { 
unit O { 
family inet { 
addresismelSOnule cm 7 Omen si/i2ale 
} 
} 
} 
gre { 
unit O { 
tunnel { 
sourmee 10,0512, i133 
desizimeatee ones) OP Ome EA. 
} 
family inet { 
acceess 10,35. 1,6/ 3082 
} 
family mpls; 
} 
} 
loo 4 
Binaic O ff 


family inet { 
acelrass 192, 168), 1. i1/ 32° 


} 
routing-options { 
Stateie 
/* corporate and alpha net */ 
eoues 172,16.0,0/12 4 
iMmexxic—inejo SZ. LG, 71.2547 
retain; 
no-readvertise; 
} 
/ Sil! eis mers “/ 
oles) IIA SIS sO, 0/ ile 4 
iMnese—Inejs 82. 16s. iL 25ee 
retain; 
no-readvertise; 
} 
route 0.0.0.0/0 { 
discard; 


retain; 


1669 


no-readvertise; 


} 
wouicee—icl 192,168. i, ip 
autonomous-system 65432; 
} 
PBOEOCOMmSm 
eswe 4 
traceoptions { 
file rsvp.log size 3m world-readable; 
flag state detail; 
flag error detail; 
flag packets detail; 
} 
interface fxp0.0 { 
disable; 
} 
interface all; 
interface 100.0; 
interface gre.0 { 
disable; 
} 


peer-interface tester2; 





} 
mpls { 
label-switched-path gmpls-ril-to-r3 { 
ison 192, LG, I. ibe 
c@ 192. 168.4, ip 
lsp-attributes { 
switching-type psc-l; 
encoding-type sonet-sdh; 
} 
MO—CSIOiE p 
primary pl; 
} 
path pl { 
NOOR ROO RO ORO ORFs iterrenie citer 
93,93 595.93 Siticileicp 
} 
interface all; 
} 
OS i=ant 
traffic-engineering; 


area 0.0.0.0 { 
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interface 100.0; 

interface fe-0/1/0.0; 

interface fxp0.0 { 
disable; 

} 

interface gre.0 { 
disable; 

} 

peer-interface tester2; 





} 
link-management { 
te-link tester2 { 
local-address 90.90.90.90; 
remote-address 100.100.100.100; 
remote-id 21253; 
interface so-0/0/0 { 
local—address 90.90.,90..90; 
BeMouc-address sO OREO OR OOOO} 
remote-id 21253; 


} 

peer tester2 { 
AGE SismlOnS Siler 
control-channel gre.0; 


te-link tester2; 


Sample Output 


The following sample output is for transit router R2: 


user@R2>show configuration | no-more 

Loc oOUlEoe ieictiowacecl. . 4] 

interfaces { 

so-0/0/0 { 
binaic © ff 
family inet { 
aceleess 10.0 .12,2/32 4 
CSgicimaicnem 10). 0) 12, ip 
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} 
family mpls; 


} 
so-0/0/1 { 
wiawic © 4 
family inet { 
address 10.0.24.1/32 { 
GesibaniatetonmsOm Ome 4 2r 


} 
family mpls; 


} 
fe-0/1/0 { 
bbe mom O ment 
family inet { 
acereess 10.0.12,14/ 305 
} 
family mpls; 


} 
fee ON/aly Za 
vinaic O 4 
family inet { 
Ac lise sisieeOm One Amelio as Ore 
} 
family mpls; 


} 
fxpod { 
winaie © f 
family inet { 
address 192.168.70.144/21; 


} 
gre { 
wimalie, 0) ff 
tunnel { 
sounce 1020.02. 14; 
CSS slivaticaloio, 310), (0).. 112, 1sip 
} 
family inet { 
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acdizess 10.35.1,5/ 30s 
} 
family mpls; 
} 
Ginalic i 4 
tunnel { 
SOuUnCe OOF aay si 
Gliese amacites"@ mee OP Ole 214 rele. 
} 
family inet { 
acdizess 10.,.35.1,1/ 30s 


} 
family mpls; 


} 
Lao | 
unit O { 
family inet { 
aclelease 192, 168 ,2. 1/ 325 


} 
MOUELMG CSE LoOMs | 
Sicaicac { 
rouse 172,16.,.0,0/12 4 
mexe—Inojs) 2. 16s. Wil 2549 
retain; 
no-readvertise; 
} 
route 192.168.0.0/16 { 
inerxic—in@jo ILS) IS, 71.2547 
retain; 
no-readvertise; 
} 
PoOUES OoW0,0,0/0 4 
discard; 
retain; 


no-readvertise; 


} 
rOUIESE—LeEl 192, 168.2.i1¢ 


autonomous-system 65432; 
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DEOEOCO Sm 
rsvp { 
traceoptions { 
file rsvp.log size 3m world-readable; 
flag packets detail; 
flag state detail; 
flag error detail; 
} 
interface fxp0.0; 
interface 100.0; 
interface all; 
interface gre.0 { 
disable; 
} 
peer-interface tester2; 
peer-interface tester3; 
} 
mpls { 
interface all; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface 100.0; 
interface fxp0.0 { 
disable; 
} 
interface gre.0 { 
disable; 
} 
interface fe-0/1/0.0; 
interface fe-0/1/2.0; 
interface gre.1 { 
disable; 
} 
peer-interface tester2; 








peer-interface tester3; 


} 
link-management { 
te-link te-tester2 { 
llocaliSaddresis SiO OR 000 OR OO}, 
remote-address 90.90.90.90; 
remote-1d 22292. 
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interface so-0/0/0 { 
lice addres sme hOORe OOF Ones 00; 
remote-address 90.90.90.90; 
remote-id 21253; 





te-link te-tester3 { 

local—ecklcess 10S 5105, 105510572 

remote-address 93.93.93.93; 

remote-1d 21254; 

interface so-0/0/1 { 
local acddiesiseelOS el O Se elhOSren0ss, 
remote-address 93.93.93.93; 
bemote-1d 21252; 


} 

peer tester2 { 
addresiss WOR S Sry 6; 
control-channel gre.0; 


cE—lLimle CEScesireir2- 





} 

peer tester3 { 
address 10.35.1.2; 
control-channel gre.1; 


te-link te-tester3; 





Sample Output 


The following sample output is for egress router R3: 


user@R3> show configuration | no-more 
lsc cOUlEOUIE Icio ZicSCl., 5 || 
interfaces { 
so-0/0/1 { 
imac 0) ff 
family inet { 
aGdinestselOm Ol Any 2i/63 2% 


} 
family mpls; 
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} 
fe-0/1/2 { 
Binaie O 
family inet { 
address 10.0.24.14/30; 
} 
family mpls; 


} 


Expo { 
unit O { 
family inet { 
address 192.168.70.146/21; 
} 
} 
} 
gre { 
wiawic © 4 
tunnel { 
SOURC Cw NO One 4nalaae, 
Ge sieaniciteclko mel O O24 lore 
} 
family inet { 
aceleess 10. 35,1,2/ 30% 
} 
family mpls; 
} 
} 
OO 
winwic © 4 


family inet { 
address 192.168.4.1/32; 


} 
routing-options { 
Sieciteslec mt 
woes 172,16,0,0/12 4 
inSee—Inejsy IZ. Gis, Wil Boas 
retain; 
no-readvertise; 
} 
Pouce ID2 168 ,0,0/16 4 
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meracnejs) 92. Is) . 7 il. 2 See 
retain; 
no-readvertise; 
} 
route 0.0.0.0/0 { 
discard; 
retain; 


no-readvertise; 


} 
weuieSer—wel IZ. Gs. 4. ig 
autonomous-system 65432; 
} 
DBOwOCoISma 
rsvp { 
traceoptions { 
file rsvp.log size 3m world-readable; 
flag packets detail; 
flag error; 
flag state; 
icles; Jhiijsyp 
} 
interface fxp0.0 { 
disable; 
} 
interface all; 
interface 100.0; 
interface gre.0 { 
disable; 
} 


peer-interface tester3; 





} 
mpls { 
interface all; 
} 
ospf { 
traffic-engineering; 
area 0.0.0.0 { 
interface fxp0.0 { 
disable; 
} 
interface fe-0/1/2.0; 
interface gre.0 { 


disable; 
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} 


interface 100.0; 





peer-interface tester3; 


} 
link-management { 
te-link te-tester3 { 
local-address 93,93.93.93; 
LEMOTE-ACHESS 103, LOS. LOS. LOS, 
bremote-1d 21254; 
interface so-0/0/1 { 
local—-address 95.93,95.93; 
weno e—crclolaess) IMS). IOS). LOS), LOS 
Lemote-1d 21252. 





} 


peer tester3 { 
acddweisicm WO ms Snellen: 


control-channel gre.0; 





cE—lLimle ce ceasiceie sir 


Determining LSP Status 


Display detailed information about Resource Reservation Protocol (RSVP) objects and the label-switched 
path (LSP) history to pinpoint a problem with the LSP. 


Figure 139 on page 1679 illustrates the network topology used in this topic. 


1678 


Figure 139: MPLS Network Topology 
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AS 65432 
a 50-0/0/3 
R2 24.1 24.2 
s0-0/00 | ip. 9 ne s0-0/0/2 
12.2 we ett 45.1 
- so-0/0/2 so0-0/0/0 
ot. s0-0/0/1 26.1 94.2 30-0/0/1 50-0/0/2 
cae 23.1 46.1 45.2 
is so-0/0/1 so-0/0/1 
Ingress 154 452 
lo0: .1 SL igi a 
© so-0/0/1 so-0/0/1 
-0/0/2 so-0/0/0 so-0/0/2 so-0/0/0 
ore 23.2 34.1 26.2 46.2 56.4 
s0-0102 a eee s0-0/0/0 
ransi 
132 eps gg) 20-0/0/3 50-0/0/3 ane 
36.1 36.2 

Key: 
so-0/0/X: 10.1.x.x/30 
100: 10.0.0.x/32 ——— Physical connection 


Note: The IGP is IS-IS or OSPF 


LSP-bidirectional traffic 





To determine the LSP state, follow these steps: 


ce Check the Status of the LSP | 1679 


2: Display Extensive Status About the LSP | 1680 


Check the Status of the LSP 


Purpose 


Display the status of the label-switched pathe (LSP). 


Action 


To determine the LSP status, on the ingress router, enter the following Junos OS command-line interface 


(CLI) operational mode command: 


user@host> show mpls Isp 


| Sample Output 


user@R1> show mpls Isp 


Ingress LSP: 1 sessions 


To From 
10.0.0.6 10.0.0.1 Up 1 
Total 1 displayed, Up 1, 





Down 0 


State Rt ActivePath P 
* R1-to-R6 


LSPname 
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Egress LSP: 1 sessions 
To From State Rt Style Labelin lLabelout LSPname 


10.0.0.1 10.0.0.6 Up 01 FF 3 - R6-to-R1 
Total 1 displayed, Up 1, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 

The sample output is from the ingress router (R1), and shows ingress, egress, and transit LSP information. 
Ingress information is for the sessions that originate from this router, egress information is for sessions 
that terminate on this router, and transit information is for sessions that transit through this router. 


There is one ingress route from R1 (10.0.0.1) to R6 (10.0.0.6). This route is currently up, and is an active 
route installed in the routing table (Rt). The LSP R1-to-R6 is the primary path (P) as opposed to the secondary 
path, and is indicated by an asterisk (*). The route to R6 does not contain a named path (ActivePath). 


There is one egress LSP from R6 to R1. The State is up, with no routes installed in the routing table. RSVP 
reservation style (Style) consists of two parts. The first is the number of active reservations (1). The second 
is the reservation style, which is FF (fixed filter). The reservation style can be FF, SE (shared explicit), or 
WF (wildcard filter). There are three incoming labels (Labelin) and no labels going out (Labelout) for this 
LSP. 


There are no transit LSPs. 


For more information on checking the LSP state, see Checklist for Working with the Layered MPLS 
Troubleshooting Model. 


Display Extensive Status About the LSP 
Purpose 


Display extensive information about LSPs, including all past state history and the reasons why an LSP 
might have failed. 


Action 


To display extensive information about LSPs, on the ingress router, enter the following Junos OS CLI 
operational mode command: 


user@host> show mpls Isp extensive 


| Sample Output 


user@R1> show mpls Isp extensive 


Ingress LSP: 1 sessions 


I> O06 


Hesomts 


10.0.0.1, State: Up , ActiveRoute: 1, LSPname: R1-to-R6 


ActivePath: (primary) 





*Primary 


LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


State: Up 


ComputedERO (S [L] denotes strict [loose] hops): (CSPF metric: 20) 


IM 1,135.2 S 10,1.36.2 S 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPr 


Al 
30 
89 
88 
87 
86 
85 
84 
83 
82 
81 
80 
V2 
78 
V7 
76 
V5 
74 
13 
V2 
VA 
70 
69 
68 
67 
66 
65 


Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 
Aug 





IM Lets s2 10.1. 36.2 

17 12:22:52 Selected as active path 

ly le2s22e52 Recor INowitSes LO, s.2 IM.1 S652 

17 12:22:52 Up 

ly i2c22c52 Creiguimetce Cail 

17 12:22:52 CSPF: computation result accepted 

IF WAse22e23 CSiPr saslilecls me icowices comeuce 10.0,0,.6[13920 cams] 








12 IMsize5si Clear Call 

12 19:12:50 10.1.56.2: MPLS label allocation failure 

12 19:12:47 Deselected as active 

T2 19 12°47 lOL1. 56.2: MPS label vallocatwon farlune 

12 19:12:47 ResvTear received 

12 I9sil2zsay Dew 

12 19:12:31 10.1.56.2: MPLS label allocation failure[4 times] 





12 19:09:58 Selected as active path 

12 IMs09e5S Recowel IRowrSes LO 1.15.2 10,.1,56.2 

12 ILVsOVeSe Wo 

12 ISs09say Orwesinece Calli 

12 19:09:57 CSPF: computation result accepted 

IZ I9s09es29) CS tteallecls mo wowre torcwel 10,.0.0.6| il times] 
UA ISO ssG Cikeeue ieeulIb 

12 19:04:23 Deselected as active 

12 19:04:23 ResvTear received 

12 19:04:23 Down 

12 19:04:23 CSPF failed: no route toward 10.0.0.6 
12 19:04:23 10.1.15.2: Session preempted 

1A lGs4tiasss Recor iNowires LO tsi S.2 10.1 .S6.2 

ia lease Sis) lye) 








mpt): 
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64 Aug 12 16:45:35 Clear Call 

63 Aug 12 16:45:35 CSPF: computation result accepted 
62 Aug 12 16:45:35 ResvTear received 

61 Aug 12 16:45:35 Down 

60 Aug 12 16:45:35 10.1.13.2: Session preempted 

59 Aug 12 14:50:52 Selected as active path 

He Nuc 12 I4eS0eo2 ineerorcl inomeee IO slols.2 Osi. 3652 
Sy PAU Cpe eZ 4: 2510S UD 

D6 Aug 12) 14 50) 52 Oritginave Cali: 

55 Aug 12 14:50:52 CSPF: computation result accepted 


54 Aug 12 14:50:23 CSPF failed: no route toward 10.0.0.6[7 times] 


53 Aug 12 14:47:22 Deselected as active 
52 Aug 12 14:47:22 CSPF failed: no route toward 10.0.0.6 
51 Aug 12 14:47:22 Clear Call 





50 Aug 12 14:47:22 CSPF: link down/deleted 
1D 1,12. 1 (RL W0O/10.0.0, 1) S10. 1.12.2 (R2 .00/10.,0.0.2) 
49 Aug 12 14:47:22 CSPF: link down/deleted 
1.1.15, (RL, 00/10 .0.0,1)-210,1,15.2 (25.00/10.,0.0.5) 


48 Aug 12 14:4 


Aug 12 14:4 
Aug 12 14:4 
mois; A Ia eaye ae LO, ibe ile IMieuiis; leis glllereeie stein se elat lives 
Aug 12 14:47:22 MPLS label allocation failure 

Aug 12 14:47:22 Down 

42 Jul 23 11:27:21 Selected as active path 

Created: Sat Jul 10 18:18:44 2004 


Total 1 displayed, Up 1, Down O 


S22 IML, IS 13 Mens label allllocaciom tes ilucS 
a7 2GilcaiaeCanbls 





q 


Soa SS Ss] S&S =I 


4 2:22 CSPF: computation result accepted 





q 





q 


Gy FS (on wy Sl 9 


q 








Egress LSP: 1 sessions 


1G) 0) .O, ab 
From: 10.0.0.6,  LSPstate:Up , ActiveRoute: 0 


LSPname: R6-to-R1 , LSPpath: Primary 
Suggested label received: -, Suggested label sent: 








Recovery label received: , Recovery label sent: 
Resv style: 1 FF , Label in: 3, Label out: - 
Time left: 141, Since: Tue Aug 17 12:23:14 2004 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 39024 protocol 0 
Nine wemezems IO,1,15,2 (se-O0/0/1.,0) 130 Skes 
Adspec: received MTU 1500 





PATH sentto: localclient 





RES VEE CE rOn seloCcakelmmernite 
Necorcl iourees IO i, S652 10,1,15,2 <seilic> 
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Total 1 displayed, Up 1, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


Meaning 

The sample output is from the ingress router (R1), and shows ingress, egress, and transit LSP information 
in detail, including all past state history and the reasons why an LSP failed. Ingress information is for sessions 
that originate from this router, egress information is for sessions that terminate on this router, and transit 
information is for sessions that transit through this router. 


There is one ingress route from R11 (10.0.0.1) to R6 (10.0.0.6). This route is currently up (State), with one 
route actively using the LSP, R1-to-R6. The LSP active path is the primary path. Even if the LSP does not 
contain a primary or secondary keyword, the router still treats the LSP as a primary LSP, indicating that if 
the LSP fails, the router will attempt to signal inactive LSPs at 30-second intervals, by default. 


Load balancing is Random, which is the default, indicating that when selecting the physical path for an 
LSP, the router randomly selects among equal-cost paths that have an equal hop count. Other options 
that you can configure are Least-fill and Most-fill. Least-fill places the LSP over the least utilized link of 
the equal-cost paths with equal hop count. Most-fill places the LSP over the most utilized link of the 
equal-cost paths sharing an equal hop count. Utilization is based on the percentage of available bandwidth. 


The Encoding type field shows Generalized MPLS (GMPLS) signaling parameters (Packet), indicating IPv4. 
The Switching type is Packet, and the Generalized Payload Identifier (GPID) is IPv4. 


The primary path is the active path, as indicated by an asterisk (*). The state of the LSP is Up. 


The Explicit Route Object (ERO) includes the Constrained Shortest Path First (CSPF) cost (20) for the 
physical path that the LSP follows. The presence of the CSPF metric indicates that this is a CSPF LSP. The 
absence of the CSPF metric indicates a no-CSPF LSP. 


The field 10.1.13.2 S indicates the actual ERO. The RSVP signaling messages went to 10.1.13.2 strictly (as 
a next hop) and finished at 10.1.36.2 strictly. All ERO addresses are strict hops when the LSP is a CSPF 
LSP. Loose hops can only display in a no-CSPF LSP. 


The received Record Route Object (RRO) has the following protection flags: 


e 0x01—Local protection available. The link downstream of this node is protected by a local repair 
mechanism. This flag can only be set if the Local protection flag was set in the SESSION_ATTRIBUTE 
object of the corresponding path message. 


e 0x02—Local protection in use. A local repair mechanism is in use to maintain this tunnel (usually because 
of an outage of the link it was routed over previously). 


e 0x04— Bandwidth protection. The downstream router has a backup path providing the same bandwidth 
guarantee as the protected LSP for the protected section. 
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e 0x08—Node protection. The downstream router has a backup path providing protection against link and 
node failure on the corresponding path section. If the downstream router can set up only alink-protection 
backup path, the “Local protection available” bit is set but the “Node protection” bit is cleared. 


e 0x10—Preemption pending. The preempting node sets this flag if a pending preemption is in progress 
for the traffic engineered LSP. This indicates to the ingress label edge router (LER) of this LSP that it 
should be rerouted. 


For more information on protection flags, see the Junos Routing Protocols and Policies Command Reference. 


The field 10.1.13.2.10.1.36.2 is the actual received record route (RRO). Note that the addresses in the 
RRO field match those in the ERO field. This is the normal case for CSPF LSPs. If the RRO and ERO 
addresses do not match for a CSPF LSP, the LSP has to reroute or detour. 


The lines numbered 91 through 42 contain the 49 most recent entries to the history log. Each line is time 
stamped. The most recent entries have the largest log history number and are at the top of the log, indicating 
that line 91 is the most recent history log entry. When you read the log, start with the oldest entry (42) 
to the most recent (91). 


The history log was started on July 10, and displays the following sequence of activities: an LSP was 
selected as active, was found to be down, MPLS label allocation failed several times, was deleted several 
times, was preempted because of an ResvTear, was deselected as active, and was cleared. In the end, the 
router computed a CSPF ERO, signaled the call, the LSP came up with the listed RRO (line 90), and was 
listed as active. 


For more information on error messages, see the Junos MPLS Network Operations Guide Log Reference. 


The total number of ingress LSPs displayed is 1, with 1 up and O down. The number in the Up field plus 
the number in the Down field should equal the total. 


There is one egress LSP session from R6 to R1. The State is up, with no routes installed in the routing 
table. RSVP reservation style (Style) consists of two parts. The first is the number of active reservations 
(1). The second is the reservation style, which is FF (fixed filter). The reservation style can be FF, SE (shared 
explicit), or WF (wildcard filter). There are three incoming labels (Labelin) and no labels going out (Labelout) 
for this LSP. 


There are no transit LSPs. 
For more information on checking the LSP state, see Checklist for Working with the Layered MPLS 


Troubleshooting Model. 


Checking That RSVP Path Messages Are Sent and Received 


Purpose 

The presence or absence of various RSVP messages can help determine if there is a problem with 
Multiprotocol Label Switching (MPLS) in your network. For example, if path messages occur in the output 
without Resv messages, it might indicate that label-switched paths (LSPs) are not being created. 
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Action 


To check that RSVP Path messages are sent and received, enter the following Junos OS command-line 
interface (CLI) operational mode command: 


user@host> show rsvp Statistics 


| Sample Output 


user@R1> show rsvp statistics 





























PacketType orca Last 5 seconds 
Sent Received Sent Received 
Path 114523 80185 1 0 
PathErr 5 10 0 0 
PathTear 12 6 0 0 
Resv FF 80515 111476 0 0 
Resv WE 0 0 0 0 
Resv SE 0 0 0 0 
ResvErr 0 0 0 0 
ResvTear 0 5 0 0 
ResvCont 0 0 0 0 
Ack 0 0 0 0 
SRefresh 0 0 0 0 
Hello 915851 915881 0 0 
EndtoEnd RSVP 0 0 0 0 
Errors Total ase omseeCOnels 
Rev pkt bad length 0 0 
Rev pkt unknown type 0 0 
Rev pkt bad version 0 0 
Rev pkt auth fail 0 0 
Rev pkt bad checksum 0 0 
Rev pkt bad format 0 0 
Memory allocation fail 0 0 
No path information 0 0 
Resv style conflict 0 0 
Pore, Comrie 0 0 
Resv no interface 0 0 
PathErr to client 15 0 
ResvErr to client 0 0 
Path timeout 0 





Resv timeout 





Message out-of-order 
Unknown ack msg 
Recv nack 


Recv duplicated msg-id 





Sea 2 LS S| S&S 
S | 2 S&S S&S & 





No TE-link to recv Hop 


Meaning 


The sample output shows RSVP messages sent and received. The total number of RSVP Path messages is 
11,4532 sent and 80,185 received. Within the last 5 seconds, no messages have been sent or received. 


A total of 5 PathErr messages were sent and 10 received. When path errors occur (usually because of 
parameter problems in a path message), the router sends a unicast PathErr message to the sender that 
issued the path message. In this case, R1 sent at least 10 path messages with an error, as indicated by the 
10 PathErr messages that R1 has received. The downstream router sent R1 five path messages with an 
error, as indicated by the five PathErr messages that R1 has sent. PathErr messages transmit in the opposite 
direction to path messages. 


A total of 12 PathTear messages were sent and 6 received, none in the last 5 seconds. In contrast to 
PathErr messages, PathTear messages travel in the same direction as path messages. Since path messages 
are both sent and received, PathTear messages are also sent and received. However, if only path messages 
are sent, then only the PathTear messages that are sent appear in the output. 


A total of 80,515 reservation (Resv) messages with the fixed filter (FF) reservation style were sent and 
111,476 received, none in the last 5 seconds. An FF reservation style indicates that within each session, 
each receiver establishes its own reservation with each upstream sender, and that all selected senders are 
listed. No messages for the wildcard filter (WF) or shared explicit (SE) reservation styles are sent or received. 
For more information on RSVP reservation styles, see the Junos MPLS Applications Configuration Guide. 


Other RSVP message types are not sent or received. For information on the ResvErr, ResvTear, and 
Resvconf message types, see the Junos MPLS Applications Configuration Guide. 


Ack and summary refresh (SRefresh) messages do not appear in the output. Ack and summary refresh 
messages are defined in RFC 2961 and are part of the RSVP extensions. Ack messages are used to reduce 
the amount of RSVP control traffic in the network. 


A total of 915,851 hello messages were sent and 915,881 received, with none transmitted or received in 
the last 5 seconds. The RSVP hello interval is 9 seconds. If more than one hello message is sent or received 
in the last 5 seconds, it implies that more than one interface supports RSVP. 


EndtoEnd RSVP messages are legacy RSVP messages that are not used for RSVP traffic engineering. These 
counters increment only when RSVP forwards legacy RSVP messages issued by a virtual private network 
(VPN) customer for transit across the backbone to the other site(s) in the VPN. They are called end-to-end 
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messages because they are intended for the opposite side of the network and only have meaning at the 


two ends of the provider network. 


The Errors section of the output shows statistics about RSVP packets with errors. A total of 15 PathErr 
to client packets were sent to the Routing Engine. The total combines the sent and received PathErr 


packets. 
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abstract-hop 


Syntax 


abstract-hop abstract-hop-name { 
constituent-list constituent-list-name (include-any-list | include-all-list | exclude-all-list | exclude-any-list); 
operators (AND | OR); 


Hierarchy Level 


[edit logical systems logical-systems-name protocols mpls] 
[edit protocols mpls] 


Release Information 
Statement introduced in Junos OS Release 17.1 for all platforms. 


Description 
Define router clusters or groups, similar to the sequence of real-hop constraints (strict or loose), as a 
sequence of abstract hops for setting up a label-switched path (LSP). 


An abstract hop is a logical combination of the existing traffic engineering constraints, such as administrative 
groups, extended administrative groups, and Shared Risk Link Groups (SRLGs), along with the ordering 
property of real hops. As a result, when a sequence of abstract hops is used in a path constraint, ordering 
is achieved among the groups of routers that meet a logical combination of link or node attributes called 
constituent attributes. A path can use a combination of real and abstract hops as constraints. 


Options 

abstract-hop-name—Name of the abstract hop that is a logical combination of the existing traffic engineering 
constraints, such as administrative groups, extended administrative groups, and SRLGs, along with the 
ordering property of real hops. 


constituent-list constituent-list-name—Name of the predefined constituent list to be included in defining 
the abstract hop. A constituent list enables you to define a set of constituent attributes that is identified 
with a user-defined name. 


include-any-list—Satisfy any one of the attributes specified in the constituent list. 
include-all-list—Satisfy all of the attributes specified in the constituent list. 
exclude-all-list—Satisfy none of the attributes specified in the constituent list. 


exclude-any-list—Fail to satisfy any one of the attributes specified in the constituent list. 


operators—Specify the operation between constituent lists when more than one constituent list is included 
in the abstract hop definition. 


AND-Satisfy all the constituent lists referenced in the abstract hop definition for the attached node to 
be a member of the abstract hop. 


OR-Satisy at least one of the constituent lists referenced in the abstract hop definition for the attached 
node to be a member of the abstract hop. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Abstract Hops for MPLS LSPs | 442 
constituent-list | 1742 
show mpls abstract-hop-membership | 2330 


show mpls Isp abstract-computation | 2400 
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| adaptive 
Syntax 


adaptive; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

During reroute, do not double-count bandwidth on links shared by the old and new paths. Including this 
statement causes RSVP to use shared explicit (SE) reservation styles and assists in smooth transition during 
rerouting. 


Default 
The configured object is disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Adaptive LSP Configuration | 588 
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| adjust-interval 


Syntax 


adjust-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 


Specify the bandwidth reallocation interval. 


Options 

seconds—Bandwidth reallocation interval, in seconds. 
Range: 300 through 315,360,000 seconds 
Default: 86,400 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Automatic Bandwidth Allocation Interval | 519 
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| adjust-threshold 


Syntax 


adjust-threshold percent; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 


Specify in percentage how sensitive the automatic bandwidth adjustment for a label-switched path (LSP) 
is to changes in bandwidth utilization. 


To specify the changes in the automatic bandwidth adjustment for a LSP in absolute value, use the 
adjust-threshold-absolute statement instead. 


Options 

percent—Bandwidth demand for the current bandwidth adjustment interval is determined and compared 
to the LSP’s current bandwidth allocation. If the percentage difference in bandwidth is greater than or 
equal to the percentage specified by this statement, the LSP’s bandwidth is adjusted to the current 
bandwidth demand. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Automatic Bandwidth Adjustment Threshold | 521 


1701 


| adjust-threshold-absolute 


Syntax 


adjust-threshold-absolute bps; 


Hierarchy Level 


[edit logical-systems name protocols mpls label-switched-path name auto-bandwidth ], 

[edit logical-systems name routing-instances name protocols mpls label-switched-path name auto-bandwidth ], 
[edit protocols mpls label-switched-path name auto-bandwidth ], 

[edit routing-instances name protocols mpls label-switched-path name auto-bandwidth ] 


Release Information 
Statement introduced before Junos OS Release 17.4R1 on all platforms. 


Description 
Specify in bits per second how sensitive the automatic bandwidth adjustment for a label-switched path 
(LSP) is to changes in the average LSP utilization. 


The adjust-threshold-absolute statement works in conjunction with the adjust-thresholdstatement, which 
specifies the change in automatic bandwidth adjustment for an LSP as a percentage. 


By triggering automatic bandwidth LSP resignaling based on absolute change in bandwidth instead of 
percentage bandwidth change, LSP resignaling can be optimized for both big and small LSPs at the same 
time. 


Options 
bps—Change in average LSP utilization to trigger automatic bandwidth adjustment in bits per second. 
Default: O bps 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Configuring the Automatic Bandwidth Adjustment Threshold | 521 
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| adjust-threshold-activate-bandwidth 


Syntax 


adjust-threshold-activate-bandwidth bps; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


Release Information 
Statement introduced before Junos OS Release 14.1. 


Description 


Specify an absolute value to prevent automatic adjustment of signaled bandwidth and aggressive re-signaling 
of a label-switched path (LSP) when the actual bandwidth over the LSP is below the configured threshold, 
although the adjust-threshold percentage condition is satisfied. 


Options 

bps—Amount of bandwidth that is compared with the maximum of all traffic samples during an adjustment 
interval. If the maximum average bandwidth is less than this configured value, automatic bandwidth 
adjustment or re-signaling does not happen, even if the adjust-threshold percentage condition is satisfied. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Automatic Bandwidth Adjustment Threshold | 521 
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| adjust-threshold-overflow-limit 


Syntax 


adjust-threshold-overflow-limit number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


Release Information 
Statement introduced in Junos OS Release 7.5. 
Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 


Specify the number of consecutive bandwidth overflow samples before triggering a bandwidth adjustment. 


Options 

number—Number of consecutive bandwidth overflow samples. 
Range: 1 through 65,535 
Default: This feature is disabled by default. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring a Limit on Bandwidth Overflow and Underflow Samples | 521 
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| adjust-threshold-underflow-limit 


Syntax 


adjust-threshold-underflow-limit number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


Release Information 
Statement introduced in Junos OS Release 11.3. 
Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 


Specify the number of consecutive bandwidth underflow samples before triggering a bandwidth adjustment. 


Options 

number—Number of consecutive bandwidth underflow samples. 
Range: 1 through 65,535 
Default: This feature is disabled by default. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring a Limit on Bandwidth Overflow and Underflow Samples | 521 
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| admin-down 


Syntax 


admin-down; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced in Junos OS Release 8.2. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Set anonpacket GMPLS LSP to the administrative down state. This statement does not affect control path 
setup or data forwarding for packet LSPs. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Allowing Nonpacket GMPLS LSPs to Establish Paths Through Routers Running Junos OS | 1266 
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| admin-group (for Interfaces) 


Syntax 


admin-group [ group-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls interface interface-name], 
[edit protocols mpls interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Define administrative groups for an interface. 


Options 
group-names—One or more names of groups defined with the admin-groups statement at the [edit protocols 
mpls] hierarchy level. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Administrative Groups for LSPs | 503 
admin-groups | 1710 


1707 


| admin-group (for LSPs) 


Syntax 


admin-group { 
exclude [ group-names ]; 
include-all [ group-names ]; 
include-any [ group-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Define the administrative groups to include or exclude an LSP and a path’s primary and secondary paths. 


Options 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Administrative Groups for LSPs | 503 
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| admin-group-extended 


Syntax 


admin-group-extended { 
apply-groups group-value; 
apply-groups-except group-value; 
exclude [ group-values ]; 
include-all [ group-values ]; 
include-any [ group-values ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | secondary) 
path-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 
Statement introduced in Junos OS Release 11.1. 


Description 

Specifies the group name and group identifier for an administrative group. The group identifier must be 
within the range of values specified by the admin-groups-extended-range statement. The extended 
administrative group values are global and must be identically configured on all the supported routers 
participating in the network. The domain-wide extended administrative groups database, learned from 
other routers through IGP flooding, is used by CSPF for path computation. 


Options 
apply-groups—Apply the specified administrative groups for the LSP or for the primary and secondary 
paths. 


apply-groups-except—Exclude the specified administrative groups from the LSP or from the primary and 
secondary paths. 


exclude—Define the administrative groups to exclude from an LSP or from the primary and secondary 
paths. 


include-all—Require the LSP to traverse links that include all of the defined administrative groups. 
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include-any—Define the administrative groups to include for an LSP for the primary and secondary paths. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Extended Administrative Groups for LSPs | 505 
Configuring Administrative Groups for LSPs | 503 
admin-groups-extended | 1711 





admin-groups-extended-range | 1713 
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| admin-groups 
Syntax 


admin-groups { 
group-name group-value; 


} 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 


[edit protocols mpls] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Configure administrative groups to implement link coloring of resource classes. 


Options 
group-name—Name of the group. You can assign up to 32 names. The names and their corresponding 
values must be identical across all routers within a single domain. 


group-value—Value assigned to the group. The names and their corresponding values must be identical 
across all routers within a single domain. 


Range: O through 31 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Administrative Groups for LSPs | 503 
admin-group (for Interfaces) | 1706 
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| admin-groups-extended 


Syntax 


admin-groups-extended group-name { 
group-value group-identifier, 


} 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls interface interface-name], 
[edit logical-systems logical-system-name routing-options], 

[edit protocols mpls interface interface-name], 

[edit routing-options] 


Release Information 
Statement introduced in Junos OS Release 11.1. 
Statement introduced in Junos OS Release 12.3 for ACX Series routers. 


Description 


Specifies the group name and group identifier for an administrative group. The group identifier must be 
within the range of values specified by the admin-groups-extended-range statement. The extended 
administrative group values are global and must be identically configured on all the supported routers 
participating in the network. The domain-wide extended administrative groups database, learned from 
other routers through IGP flooding, is used by CSPF for path computation. 


Options 
group-name—The range of configurable values is between 32 and 4,294,967,295. The range maximum 


must be greater than the range minimum. 


group-value group-identifier—The group identifier must be within the range of configurable values, 32 and 
4,294,967,295. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Extended Administrative Groups for LSPs | 505 
Configuring Administrative Groups for LSPs | 503 
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admin-group-extended | 1708 
admin-groups-extended-range | 1713 
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| admin-groups-extended-range 
Syntax 


admin-groups-extended-range { 
maximum maximum-number; 
mininum minimum-number,; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options], 
[edit routing-options] 


Release Information 
Statement introduced in Junos OS Release 11.1. 
Statement introduced in Junos OS Release 12.3 for ACX Series routers. 


Description 

Enables you to configure extended administrative groups, represented by a 32-bit value, expanding the 
number of administrative groups supported in the network beyond just 32. In MPLS traffic engineering, 
a link can be configured with a set of administrative groups (also known as colors or resource classes). 
Administrative groups are carried in |GPs (OSPFv2 and IS-IS) as a 32-bit value assigned to each link. By 
default, Juniper Networks routers interpret this 32-bit value as a bit mask with each bit representing a 
group. This normally limits each network to a total of 32 distinct administrative groups (value range O 
through 31). 


The extended administrative groups configuration accepts a set of interfaces with a corresponding set of 
extended administrative group names. It converts the names into a set of 32-bit values and propagates 
this information into the IGP. The extended administrative group values are global and must be identically 
configured on all the supported routers participating in the network. The domain-wide extended 
administrative groups database, learned from other routers through IGP flooding, is used by CSPF for path 
computation. 


Options 
maximum maximum-number—The range of configurable values is between 32 and 4,294,967,295. The 
range maximum must be greater than the range minimum. 


minimum minimum-number—The range of configurable values is between 32 and 4,294,967,295. The 
range maximum must be greater than the range minimum. 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Extended Administrative Groups for LSPs | 505 
Configuring Administrative Groups for LSPs | 503 
admin-group-extended | 1708 
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| advertise-mode (MPLS) 


Syntax 


advertise-mode (stub-alias | stub-proxy); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls egress-protection context-identifier context-id], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name egress-protection 
context-identifier context-id], 

[edit protocols mpls egress-protection context-identifier context-id], 

[edit protocols mpls label-switched-path Isp-name egress-protection context-identifier context-id] 


Release Information 
Statement introduced in Junos OS Release 13.3. 


Description 


Configure the method for the interior gateway protocol (IGP) to advertise egress protection availability. 


Egress protection availability is advertised in the IGP. Label protocols along with CSPF use this information 
to do egress protection. 


Options 


stub-alias—Context identifier has an alias. 


In the alias method, the LSP end-point address has an explicit backup egress node where the backup 
node can be learned or configured on the penultimate hop node (PHN) of a protected LSP. With this 
model, the PHN of a protected LSP sets up the bypass LSP tunnel to back up the egress node by 
avoiding the primary egress node. This model requires a Junos OS upgrade in core nodes, but is flexible 
enough to support all traffic engineering constraints. 


stub-proxy—Context-identifier has a stub proxy node. 


A stub node is one that only appears at the end of an AS path, which means it does not provide transit 
service. In this mode, known as the virtual or proxy mode, the LSP end-point address is represented 
as a node with bidirectional links, with the LSP's primary egress node and backup egress node. With 
this representation, the penultimate hop of the LSP primary egress point can behave like a PLR in 
setting up a bypass tunnel to back up the egress by avoiding the primary egress node. This model has 
the advantage that you do not need to upgrade Junos OS on core nodes and thereby helps operators 
to deploy this technology. 


Required Privilege Level 
routing—To view this statement in the configuration. 
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routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Egress Protection for Layer 3 VPN Edge Protection Overview 
Example: Configuring Layer 3 VPN Egress Protection with RSVP and LDP 


| advertisement-hold-time 


Syntax 


advertisement-hold-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Do not advertise when the LSP goes from up to down, for a certain period of time known as the hold time. 


Options 
seconds—Hold time, in seconds. 
Range: O through 65,535 seconds 


Default: 5 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Damping Advertisement of LSP State Changes | 530 
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| allow-fragmentation 


Syntax 


allow-fragmentation; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls path-mtu], 
[edit protocols mpls path-mtu] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Allow IP packets to be fragmented before they are encapsulated in MPLS. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Enabling Packet Fragmentation | 810 
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| always-mark-connection-protection-tlv 


Syntax 


always-mark-connection-protection-tlv; 


Hierarchy Level 


[edit logical-systems logical-systems-name protocols mpls interface interface-name], 
[edit protocols mpls interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 10.2. 


Description 

(MX Series routers only) Enable you to switch an LSP away from a network node using a bypass LSP. This 
feature could be used in maintenance of active networks when a network device needs to be replaced 
without interrupting traffic passing through the network. The LSPs can be either static or dynamic. 


This statement marks all OAM traffic transiting this interface in preparation for switching the traffic to an 
alternate path based on the OAM functionality. To switch traffic to the bypass LSP, you then need to 
configure the switch-away-lIsps statement. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Switching LSPs Away from a Network Node | 804 


1719 


| associate-backup-pe-groups 
Syntax 


associate-backup-pe-groups; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced in Junos OS Release 9.0. 


Description 

Enable an LSP to monitor the status of its destination PE router. You can configure multiple backup PE 
router groups using the same router's address. Backup PE router groups provide ingress PE router 
redundancy when point-to-multipoint LSPs are configured for multicast distribution. A failure of this LSP 
indicates to all of the backup PE router groups that the destination PE router is down. This statement is 
not tied to a specific backup PE router group. It applies to all groups that are interested in the status of 
the LSP to the destination address. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Enabling Point-to-Point LSPs to Monitor Egress PE Routers | 693 
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| associate-Isp 


Syntax 


associate-Isp Isp-name { 
from from-ip-address; 


} 


Hierarchy Level 


[edit protocols mpls label-switched-path Isp-name oam] 
Release Information 
Statement introduced in Junos OS Release 12.1. 


Description 


Configure associated bidirectional label-switched paths (LSPs) on the two ends of an LSP for sending and 
receiving GAL and G-Ach OAM messages. 


Options 


from from-ip-address—(Optional) Source address for the associated LSP configuration. 
If omitted, this is derived from the to address of the ingress LSP configuration. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring the MPLS Transport Profile for OAM | 1132 


| auto-bandwidth (MPLS Tunnel) 


Syntax 


auto-bandwidth { 
adjust-interval seconds; 
adjust-threshold percent; 
adjust-threshold-absolute; 
adjust-threshold-activate-bandwidthbps 
adjust-threshold-overflow-limit number; 
adjust-threshold-underflow-limit number; 
maximum-bandwidth bps; 
minimum-bandwidth bps; 
minimum-bandwidth-adjust-interval 
minimum-bandwidth-adjust-threshold-change 
minimum-bandwidth-adjust-threshold-value 
monitor-bandwidth; 
resignal-minimum-bandwidth 
sync-active-path-bandwidth 


Hierarchy Level 


[edit protocols mpls label-switched-path Isp-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for QFX Series switches. 
Statement introduced in Junos OS Release 17.2R1 for QFX10000 Series switches. 


Description 
Allow an MPLS tunnel to automatically adjust its bandwidth allocation based on the volume of traffic 
flowing through the tunnel. 


NOTE: Incalculating the value for Max AvgBW (relative to the ingress LSP), the sample collected 
during make before break (MBB) is ignored to prevent inaccurate results. The first sample after 
a bandwidth adjustment, or after a change in the LSP ID (regardless of path change), is also 
ignored. 


Options 
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adjust-threshold-absolute adjust-threshold-absolute-value—Configure an absolute value based threshold 
along with the percentage based threshold that helps avoid the bandwidth getting triggered for LSPs 
of both small and large bandwidth reservations. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Automatic Bandwidth Allocation for LSPs | 517 
request mpls Isp adjust-autobandwidth | 2302 
show mpls Isp autobandwidth | 2403 
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| auto-bandwidth (MPLS Statistics) 


Syntax 


auto-bandwidth; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls statistics], 
[edit protocols mpls statistics] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for QFX Series switches. 
Statement introduced in Junos OS Release 17.2R1 for QFX10000 Series switches. 


Description 


Collect statistics related to automatic bandwidth. 


Required Privilege Level 
routing and trace—To view this statement in the configuration. 
routing-control and trace-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Automatic Bandwidth Allocation for LSPs | 517 
Configuring MPLS to Gather Statistics | 387 
statistics | 1964 
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| auto-policing 
Syntax 


auto-policing { 
class all (drop | loss-priority-high | loss-priority-low); 
class ctnumber (drop | loss-priority-high | loss-priority-low); 


} 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced for QFX10000 Series switches in release 15.1X53-D40. 

Statement introduced for MX240, MX480, MX960, MX2010, and MX2020 routers with MPC10E and 
MPC11E line cards in Junos OS 20.2R1. 


Description 


Enable the automatic policing of all the MPLS LSPs on the router or logical system. 


Options 
class all—Apply the same policer action to all the class types (ct0, ct1, ct2, and ct3). 


class ctnumber—Specific class type (ctO, ct1, ct2, or ct3) to which to apply a policer action. 


Policer actions—You can specify the following policer actions: 
Default: no action 

e drop—Drop all packets. 

e loss-priority-high—Set the packet loss priority (PLP) to high. 


e loss-priority-low—Set the PLP to low. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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policing (Protocols MPLS) | 1895 
Configuring Automatic Policers | 152v 


| backup-pe-group 
Syntax 


backup-pe-group group-name { 
backups [ addresses ]; 
local-address address; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast], 
[edit logical-systems logical-system-name routing-options multicast], 

[edit routing-instances routing-instance-name routing-options multicast], 

[edit routing-options multicast] 


Release Information 

Statement introduced in Junos OS Release 9.0. 

Statement introduced in Junos OS Release 9.5 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 


Description 
Configure a backup provider edge (PE) group for ingress PE redundancy when point-to-multipoint 
label-switched paths (LSPs) are used for multicast distribution. 


Options 


group-name—Name of the group for PE backups. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Ingress PE Redundancy 
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| bandwidth (Fast Reroute, Signaled, and Multiclass LSPs) 


Syntax 


bandwidth bps { 
ctO bps; 
ct1 bps; 
ct2 bps; 
ct3 bps; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name fast-reroute], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name fast-reroute], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


When configuring an LSP, specify the traffic rate associated with the LSP. 


When configuring fast reroute, allocate bandwidth for the reroute path. By default, no bandwidth is 
reserved for the rerouted path. The fast reroute bandwidth does not need to be identical to that allocated 
for the LSP itself. 


When configuring a multiclass LSP, use the ctnumber bandwidth statements to specify the bandwidth to 
be allocated for each class type. 


Options 
bps—Bandwidth, in bits per second. You can specify this as an integer value. You can also use the 
abbreviations k (for a thousand), m (for a million), or g (for a billion). 

Range: Any positive integer 


Default: O (no bandwidth is reserved) 


NOTE: On the ACX Series, bps is the only supported option. 


ctnumber bps—Bandwidth for the specified class type, in bits per second. You can specify this as an integer 
value. If you do so, count your zeros carefully, or you can use the abbreviations k (for a thousand), m (for 
a million), or g (for a billion [also called a thousand million]). 


Range: Any positive integer 


Default: O (no bandwidth is reserved) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Fast Reroute | 474 
Configuring the Bandwidth Value for LSPs | 516 
Configuring Traffic-Engineered LSPs | 1128 





Configuring Class-Type Bandwidth Constraints for Multiclass LSPs 
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| bandwidth (Static LSP) 


Syntax 


bandwidth bps; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name bypass], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name transit incoming-label], 
[edit protocols mpls static-label-switched-path Isp-name bypass], 

[edit protocols mpls static-label-switched-path Isp-name ingress], 

[edit protocols mpls static-label-switched-path Isp-name transit incoming-label] 


Release Information 
Statement introduced in Junos OS Release 10.1. 


Description 


When configuring a static LSP, specify the traffic rate associated with the LSP. 


Options 
bps—Bandwidth, in bits per second. You can specify this as an integer value. You can also use the 
abbreviations k (for a thousand), m (for a million), or g (for a billion). 

Range: Any positive integer 


Default: O (no bandwidth is reserved) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Static LSPs | 574 


1729 


| bandwidth-model 


Syntax 


bandwidth-model { 
extended-mam; 
mam; 


rdm; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls diffserv-te], 
[edit protocols mpls diffserv-te] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Configure the bandwidth model for differentiated services. Note that you cannot configure both bandwidth 
models at the same time. 

Options 

extended-mam—The extended maximum allocation model (MAM) is a bandwidth model based on MAM. 


mam—The MAM is defined in RFC 4125, Maximum Allocation Bandwidth Constraints Model for Diffserv-aware 
MPLS Traffic Engineering. 


rdm—The Russian dolls bandwidth allocation model (RDM) is defined in RFC 4127, Russian Dolls Bandwidth 
Constraints Model for Diffserv-aware MPLS Traffic Engineering. RDM makes efficient use of bandwidth by 
allowing the class types to share bandwidth. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Bandwidth Model | 1123 
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| bandwidth-percent 


Syntax 


bandwidth-percent percentage; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name fast-reroute], 
[edit protocols mpls label-switched-path Isp-name fast-reroute] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Configure the percentage of bandwidth to reserve for the detour path in case the primary path for a traffic 
engineered LSP or a multiclass LSP fails. The percentage configured indicates the percentage of the 
protected path’s bandwidth that is reserved for the detour path. 


Options 
percentage—The percentage of the protected path’s bandwidth that is reserved for the detour path. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Fast Reroute | 474 
Configuring Fast Reroute for Traffic-Engineered LSPs | 1129 
Configuring Fast Reroute for Multiclass LSPs 


| bfd-liveness-detection (Protocols MPLS) 


Syntax 


bfd-liveness-detection { 
failure-action { 
make-before-break teardown-timeout seconds; 
teardown; 
} 
minimum-interval milliseconds; 
minimum-receive-interval milliseconds; 
minimum-transmit-interval milliseconds; 
multiplier detection-time-multiplier, 


Hierarchy Level 


[edit protocols mpls label-switched-path Isp-name oam], 
[edit protocols mpls oam] 


Release Information 

Statement introduced in Junos OS Release 7.6. 

failure-action option added in Junos OS Release 8.5. 

Statement introduced in Junos OS Release 12.2 for EX Series switches. 


Description 


Enable Bidirectional Forwarding Detection (BFD) for all of the MPLS LSPs or for just a specific LSP. 


Options 

minimum-interval—Minimum transmit and receive interval. 
Range: 50 through 255,000 milliseconds 
Default: 50 


minimum-receive-interval—Minimum receive interval. 
Range: 50 through 255,000 milliseconds 
Default: 50 


minimum-transmit-interval—Minimum transmit interval. 
Range: 50 through 255,000 milliseconds 
Default: 50 


multiplier—Detection time multiplier. 
Range: 1 through 255 
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Default: 3 
The failure-action statement is explained separately. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring BFD for MPLS IPv4 LSPs | 143 
Configuring Bidirectional Forwarding Detection for MPLS (CLI Procedure) | 136 
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| bfd-liveness-detection (Source Packet Routing Template) 


Syntax 


bfd-liveness-detection { 
minimum-interval milliseconds; 
multiplier multiplier; 
no-router-alert-option; 
sbfd; 


Hierarchy Level 


[edit protocols source-packet-routing source-routing-path-template] 


Release Information 
Statement introduced in Junos OS Release 19.4R1. 


Description 


Configure Bidirectional forwarding detection (BFD) options for PCE-initiated segment routing LSP template. 


NOTE: The BFD configuration is applied at the top level and not individually per segment list. 
As aresult, each path of the PCE-initiated LSP inherits the same BFD configuration. 


Options 
minimum-interval—Specify in milliseconds the minimum transmit and receive interval. 
Range: 1 through 255000 milliseconds 


multiplier—Specify the detection time multiplier. 
Default: 3 
Range: 1 through 255 


no-router-alert-option—Do not set the router alert option in the IP header. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing 
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RELATED DOCUMENTATION 


Understanding Static Segment Routing LSP in MPLS Networks | 711 
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| bfd-liveness-detection (LSP) 


Syntax 


bfd-liveness-detection { 
minimum-interval milliseconds; 
multiplier multiplier; 
no-router-alert-option; 
sbfd { 
remote-discriminator remote-discriminator; 


Hierarchy Level 


[edit protocols source-packet-routing segment-list], 
[edit protocols source-packet-routing source-routing-path Isp-name primary segment-list-name], 


[edit protocols source-packet-routing source-routing-path Isp-name secondary segment-list-name] 


Release Information 

Statement introduced in Junos OS Release 18.4R1. 

Support at the following hierarchy levels introduced in Junos OS Release 19.1R1: [edit protocols 
source-packet-routing source-routing-path Isp-name primary segment-list-name], and [edit protocols 
source-packet-routing source-routing-path Isp-name secondary segment-list-name]. 


NOTE: Starting in Junos OS Release 19.1R1, the bfd-liveness-detection statement is not 
supported at the [edit protocols source-packet-routing segment-list] hierarchy level. 


Description 


Bidirectional forwarding detection options. 


Options 
minimum-interval—Minimum transmit and receive interval (milliseconds). 
Range: 1 through 255000 


multiplier—Detection time multiplier. 
Default: 3 
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Range: 1 through 255 
no-router-alert-option—Do not set the Router Alert option in IP header. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing 
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| class-of-service (Protocols MPLS) 


Syntax 


class-of-serviceclass-of-service cos-value; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


Description 


Class-of-service (CoS) value given to all packets in the LSP. 


The CoS value might affect the scheduling or queuing algorithm of traffic traveling along an LSP. 


Options 
cos-value—CoS value. A higher value typically corresponds to a higher level of service. 

Range: O through 7 

Default: If you do not specify a CoS value, the IP precedence bits from the packet's IP header are used as the 
packet’s CoS value. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Class of Service for MPLS LSPs | 1220 
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Configuring the Ingress Router for Static LSPs | 575 
Configuring the Intermediate (Transit) and Egress Routers for Static LSPs | 578 


| compute-options 
Syntax 


compute-options; 


Hierarchy Level 


[edit protocols source-packet-routing] 
Release Information 
Statement introduced in Junos OS Release 19.2R1-S1 on MX Series and PTX Series routers. 


Description 


Configure compute options applicable to all the computed paths. 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Enabling Distributed CSPF for Segment Routing LSPs | 704 
compute-profile | 1739 
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| compute-profile 
Syntax 


compute-profile name { 
protected { 
mandatory; 


} 
unprotected { 


mandatory; 
} 
admin-group include-any [ include-any ... Jinclude-all [ include-all ... }exclude [ exclude ... }; 
compute-segment-list compute-segment-list; 
maximum-computed-segment-lists maximum-computed-segment-lists; 
maximum-segment-list-depth maximum-segment-list-depth; 
metric-type { 
(igp | te); 
} 


no-label-stack-compression; 


Hierarchy Level 


[edit protocols source-packet-routing] 


Release Information 
Statement introduced in Junos OS Release 19.2R1-S1 on MX Series and PTX Series routers. 


Description 

Configure the compute profile for dynamically computed paths. You can use a compute profile to logically 
group the computation constraints. These compute profiles are referenced by the segment routing paths 
for computing the primary and secondary segment routing LSPs. 


Options 


name—Name of the computation-profile. 


protected—Choose protected labels if available. 
Values: 
e mandatory—Mandatorily choose protected labels. 


unprotected—Choose unprotected labels if available. 


Values: 
e mandatory—Mandatorily choose unprotected labels. 
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compute-segment-list—Name of the compute type segment list. 


maximum-computed-segment-lists—Maximum number of segment-lists (ECMP paths) to be computed. 
Range: 1 through 128 


maximum-segment-list-depth—Maximum depth of computed path. 
Range: 1 through 16 


metric-type—Specify the metric type used for computation. 
Values: 
e igo—Interior gateway protocol metric. 


e te—Traffic-engineering metric. 


no-label-stack-compression—Provide fully expanded path, using adjacency segment identifiers. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Enabling Distributed CSPF for Segment Routing LSPs | 704 
compute-options | 1738 
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connections (MPLS) 


Syntax 


connections { 
remote-interface-switch connection-name { 
interface interface-name.unit-number,; 
transmit-Isp label-switched-path; 
receive-Isp label-switched-path; 


Hierarchy Level 


[edit protocols] 


Release Information 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Define the connection between two circuits in a CCC connection. 


The remaining statements are explained separately. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring MPLS on EX8200 and EX4500 Switches | 42 
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| constituent-list 


Syntax 


constituent-list constituent-list-name { 
(administrative-group [ group-names ] | administrative-group-extended [ extended-administrative-group-names | | 
srlg [ srlg-names ]); 


Hierarchy Level 


[edit logical systems logical-systems-name protocols mpls] 
[edit protocols mpls] 


Release Information 
Statement introduced in Junos OS Release 17.1 for all platforms. 


Description 

Create a list of traffic engineering attributes called constituent attributes, which are the link and node 
attributes whose logical combination makes up an abstract hop. The constituent attributes are listed under 
administrative groups, extended administrative groups, and Shared Risk Link Groups (SRLGs). 


Options 
constituent-list-name—Name of the constituent list that includes constituent traffic engineering attributes 
for use in the abstract hop definition. 


administrative-group [ group-names ]—Names of administrative groups to include in the constituent list. 


administrative-group-extended [ extended-administrative-group-names ]—Names of extended administrative 
groups to include in the constituent list. 


srlg [ srlg-names ]—Names of SRLGs to include in the constituent list. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Abstract Hops for MPLS LSPs | 442 
abstract-hop | 1696 
show mpls abstract-hop-membership | 2330 


1743 


| show mpls Isp abstract-computation | 2400 


container-label-switched-path 


Syntax 


container-label-switched-path Isp-name { 
disable; 
description description; 
label-switched-path-template; 
splitting-merging; 
suffix string; 
to ip-address; 


Hierarchy Level 


[edit protocols mpls] 


Release Information 
Statement introduced in Junos OS Release 14.2. 
Statement introduced for QFX Switches in Junos OS Release 15.1X53-D30. 


Description 


Configure a multi-label-switched path (LSP) tunnel between the ingress and the egress routers. The 
container LSP consists of several member LSPs to the same destination. 


Options 
disable—Disable MPLS container-label-switched path. 


description description—Text describing the container LSP. 
suffix string—Suffix to generate names of member LSPs of the container LSP. 
to ip-address—IP address of the egress router. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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| corouted-bidirectional 


Syntax 


corouted-bidirectional; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced in Junos OS Release 12.2. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Specify that the label-switched path be established as a corouted bidirectional packet LSP. You cannot 
configure this statement at the same time as the corouted-bidirectional-passive statement. 


Default 
This statement is disabled by default. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Corouted Bidirectional LSPs | 531 


corouted-bidirectional-passive | 1745 
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| corouted-bidirectional-passive 


Syntax 


corouted-bidirectional-passive; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced in Junos OS Release 12.2. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Specify that the label-switched path be a passive LSP associated with a bidirectional LSP when it is signaled 
at the ingress router. This passive LSP enables the MPLS application to utilize the reverse LSP. You cannot 
configure this statement at the same time as the corouted-bidirectional statement. 


Default 
This statement is disabled by default. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Corouted Bidirectional LSPs | 531 
corouted-bidirectional | 1744 
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| credibility 
Syntax 


credibility { 
direct; 
isis-level-1; 
isis-level-2; 
ospf; 
static; 
unknown; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls traffic-engineering database export], 
[edit protocols mpls traffic-engineering database export] 


Release Information 
Statement introduced in Junos OS Release 14.2. 
Statement introduced in Junos OS Release 17.1R1 on QFX Series and QFX10000 switches. 


Description 
Configure preference values for entries from BGP-TE to the traffic engineering database. A protocol with 
a higher credibility value is preferred over a protocol with a lower credibility value. 


The credibility order for the BGP-TE protocols is as follows: 
e Unknown—80 

e OSPF—81 

e ISIS Level 1—82 

e ISIS Level 2—83 

e Static—84 


e Direct—85 

Options 

direct— Entries sourced from directly connected links. 
isis-level-1—Entries sourced from IS-IS Level 1. 


isis-level-2—Entries sourced from IS-IS Level 2. 
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ospf—Entries sourced from OSPF. 
static—Entries sourced from static configuration. 


unknown—Entries sourced from unknown entities. 
Range: O through 512 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


traffic-engineering | 1983 
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| database 


Syntax 


database { 
export; 
import; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls traffic-engineering], 
[edit protocols mpls traffic-engineering] 


Release Information 
Statement introduced in Junos OS Release 14.2. 
Statement introduced in Junos OS Release 17.1R1 for QFX Series and QFX10000 switches. 


Description 
Include link and node entries from the traffic engineering database into the Isdist.0 routing information 
base (RIB), so it gets picked up by the BGP export policy. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


traffic-engineering | 1983 
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| delay (querier) 


Syntax 


delay { 
traffic-class tc-value { 
average-sample-size sample size; 
padding-size size; 
query-interval milliseconds; 
rtt-delay-threshold rtt threshold value; 
twcd-delay-threshold twcd threshold value; 


Hierarchy Level 


[edit protocols mpls oam performance-monitoring querier], 

[edit protocols mpls label-switched-path Isp-name oam performance-monitoring querier], 

[edit protocols mpls label-switched-path Isp-name primary path-name oam performance-monitoring querier], 
[edit protocols mpls label-switched-path Isp-name secondary path-name oam performance-monitoring querier] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Configure delay measurement options. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Pro-Active Loss and Delay Measurements | 417 
On-Demand Packet Loss and Delay Measurement for UHP LSPs Overview | 388 
performance-monitoring (Protocols MPLS) | 1893 
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| delay (responder) 


Syntax 


delay { 
min-query-interval milliseconds; 


Hierarchy Level 


[edit protocols mpls oam performance-monitoring responder], 

[edit protocols mpls label-switched-path Isp-name oam performance-monitoring responder], 

[edit protocols mpls label-switched-path Isp-name primary path-name oam performance-monitoring responder], 
[edit protocols mpls label-switched-path Isp-name secondary path-name oam performance-monitoring responder] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Configure delay measurement options. 


Options 

min-query-interval milliseconds—(Optional) Specify the minimum query interval that the responder supports. 
If the minimum query interval of the responder is greater than the query interval configured at querier, 
the effective message query rate will be the minimum query interval configured for the responder. 


Default: 10 seconds 
Range: 1000 through 4294967295 milliseconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Pro-Active Loss and Delay Measurements | 417 
On-Demand Packet Loss and Delay Measurement for UHP LSPs Overview | 388 
performance-monitoring (Protocols MPLS) | 1893 
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| description (Protocols MPLS) 


Syntax 


description text; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name bypass], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name transit incoming-label], 
[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls static-label-switched-path Isp-name bypass], 

[edit protocols mpls static-label-switched-path Isp-name ingress], 

[edit protocols mpls static-label-switched-path Isp-name transit incoming-label] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


Description 

Provides a textual description of the LSP. Enclose any descriptive text that includes spaces in quotation 
marks (""). Any descriptive text you include is displayed in the output of the show mpls Isp detail command 
and has no effect on the operation of the LSP. 


Options 
text—Provide a textual description of the LSP. The description text can be no more than 80 characters in 
length. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring a Text Description for LSPs | 499 
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| description (Protocols Layer 2 VPN) 


Syntax 


description text; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols |2vpn site site-name 
interface interface-name], 
[edit routing-instances routing-instance-name protocols |2vpn site site-name interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 11.1 for EX Series switches. 


Description 


Describe the VPN or virtual private LAN service (VPLS) routing instance. 


Options 

text—Provide a text description. If the text includes one or more spaces, enclose it in quotation marks (" 
"). Any descriptive text you include is displayed in the output of the show route instance detail command 
and has no effect on operation. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Site 
Configuring an MPLS-Based Layer 2 VPN (CLI Procedure) 
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| deselect-on-bandwidth-failure 


Syntax 


deselect-on-bandwidth-failure { 
tear-Isp; 


} 


Hierarchy Level 


[edit protocols mpls], 
[edit protocols mpls label-switched-path path-name] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 
Deselect an active path if it does not meet the auto-bandwidth criteria required for path selection. The 
deselect-on-bandwidth-failure statement does not apply to static bandwidth. 


Options 


tear-Isp— Bring down an active path if none of the paths are able to reserve the required bandwidth. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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| diffserv-te 


Syntax 


diffserv-te { 
bandwidth-model { 
extended-mam; 
mam; 
rdm; 
} 
te-class-matrix { 
tenumber { 
priority priority; 
traffic-class { 
ctnumber priority priority; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify properties for differentiated services in traffic engineering. 


Options 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Routers for DiffServ-Aware Traffic Engineering | 1122 
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| disable (Protocols MPLS) 


Syntax 


disable; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls interface interface-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls], 

[edit protocols mpls interface interface-name], 

[edit protocols mpls label-switched-path Isp-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


Description 


Disable the functionality of the configured object. 


Default 


The configured object is enabled (operational) unless explicitly disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


label-switched-path | 1817 
interface | 1812 
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| dual-transport 


Syntax 


dual-transport { 
inet-Isr-id inet-Isr-id; 
inet6-lsr-id inet6-Isr-id; 


Hierarchy Level 


[edit protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 16.1 for the M320 Series, MX Series, and PTX Series. 


Description 

Configure to allow Junos LDP to establish the TCP connection over IPv4 with IPv4 neighbors, and over 
IPv6é with IPv6 neighbors as a single-stack LSR. inet-Isr-id and inet6-Isr-id are the two LSR IDs that have 
to be configured to establish an LDP session over IPv4 and IPv6 TCP transport. These two IDs should be 
non-zero and must be configured with different values. 


Options 
inet-Isr-id inet-Isr-id— Configure the LSR ID to establish an LDP session over IPv4 TCP transport. 


inet6-Isr-id inet6-Isr-id— Configure the LSR ID to establish an LDP session over IPv6é TCP transport. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


LDP Native IPv6é Support Overview | 865 

Example: Configuring LDP Native IPv6 Support | 986 
Configuring LDP Native IPv6é Support | 984 

family (Protocols LDP) | 1778 
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| dynamic (Source Packet Routing) 


Syntax 


dynamic { 
protected { 
mandatory; 


} 
unprotected { 
mandatory; 


Hierarchy Level 


[edit protocols source-packet-routing segment-list] 


Release Information 
Statement introduced in Junos OS Release 19.2R1 on all platforms. 


Description 
Enable dynamic computation of segment routing label-switched paths (LSPs) based on tunnel destination 
and translation service to fetch the corresponding segment identifiers (SIDs). 


NOTE: 


When the dynamic statement is enabled, all the next hops must have an IP address assigned as a minimum 
configuration. In the case of segment-lists, if a next hop has both IP address and label configured, then 
the configured label is retained. 


NOTE: 

e Because translation service use IGP instance of traffic-engineered database (TED), you must 
include the igp-topology statement at the [edit protocols isis traffic-engineering] hierarchy 
level for successful translation. 


e The auto-translation and dynamic statements are mutually exclusive, and only either of them 
can be configured under a segment-list. 


Options 
protected—(Optional) Ensures a protected adjacency SID is used for the links of the LSP. 
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unprotected—(Optional) Ensures an unprotected adjacency SID is used for the links of the LSP. 


mandatory—(Optional) Enabled translation to fail if the specified type of adjacency SID cannot be found 
for a link. This option does not have effect on node SIDs. 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Understanding Static Segment Routing LSP in MPLS Networks | 711 


| dynamic-tunnels 


Syntax 


dynamic-tunnels tunnel-name { 
destination-networks prefix; 
gre; 
rsvp-te entry-name { 
destination-networks network-prefix; 
label-switched-path-template (Multicast) { 
default-template; 
template-name; 


} 

source-address address; 

spring-te; 

traceoptions; 

tunnel-attributes name { 
dynamic-tunnel-anchor-pfe dynamic-tunnel-anchor-pfe; 
dynamic-tunnel-anti-spoof (off | on); 
dynamic-tunnel-gre-key 
dynamic-tunnel-mtu dynamic-tunnel-mtu; 
dynamic-tunnel-source-prefix dynamic-tunnel-source-prefix; 
dynamic-tunnel-type V40V6; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], 
[edit logical-systems logical-system-name routing-options], 

[edit routing-instances routing-instance-name routing-options], 

[edit routing-options] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3 for ACX Series routers. 


Description 


Configure a dynamic tunnel between two PE routers. 


NOTE: ACX Series routers do not support the gre statement. 
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Configure dynamic IPv4-over-IPvé6 tunnels and define their attributes to forward |IPv4 traffic over an 
IPv6-only network. IPv4 traffic is tunneled from customer premises equipment to IPv4-over-IPv6é gateways. 
You must also configure extended-nexthop option at [edit protocols bgp family inet unicast] hierarchy 
level to allow BGP to route IPv4 address families over an IPv6 session. 


Options 
gre—Enable dynamic generic routing encapsulation type tunnel mode for IPv4 
Values: 
e next-hop-based-tunnel—Enable next hop base dynamic-tunnel for steering IPv4 traffic with IPv6é 
next hop address. 


source-address—Specify the source address of the tunnel. 
tunnel-name—Name of the dynamic tunnel. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


extended-nexthop 
tunnel-attributes 
Example: Configuring a Two-Tiered Virtualized Data Center for Large Enterprise Networks 


Understanding Redistribution of IPv4 Routes with IPv6 Next Hop into BGP 
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| egress-protection (MPLS) 


Syntax 


egress-protection { 
context-identifier context-id { 
primary | protector; 
metric igp-metric-value; 
advertise-mode (stub-alias | stub-proxy); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name] 


Release Information 

Statement introduced in Junos OS Release 10.4. 

Options primary, protector, and metric introduced in Junos OS Release 11.4R3. 
Option advertise-mode introduced in Junos OS Release 13.3. 


Description 
Enables an Edge Protection Virtual Circuit (EPVC) for the MPLS protocol. 


Options 


context-identifier context-id-ip-address—(Optional) The context identifier IPv4 address. 
metric igp-metric-value—(Optional) The IGP metric value ranging from 2 through 16777215. 


(primary | protector)—On the primary PE router, configure as type primary. On the protector PE router, 
configure as type protector. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Egress Protection for Layer 3 VPN Services 
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Example: Configuring Layer 3 VPN Egress Protection with RSVP and LDP 
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| encapsulation-type (Layer 2 VPNs) 


Syntax 


encapsulation-type (atm-aal5 | atm-cell | atm-cell-port-mode | atm-cell-vc-mode | atm-cell-vp-mode | cesop | 
cisco-hdlc | ethernet | ethernet-vlan | frame-relay | frame-relay-port-mode | interworking | ppp | satop-e1 | satop-e3 
| satop-t1 | satop-t3); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols |2circuit neighbor address interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols |2vpn], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols |2vpn neighbor address], 
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls], 

[edit protocols I2circuit neighbor address interface interface-name], 

[edit routing-instances routing-instance-name protocols |2vpn], 

[edit routing-instances routing-instance-name protocols I2vpn neighbor address], 

[edit routing-instances routing-instance-name protocols vpls], 

[edit routing-instances routing-instance-name protocols vpls neighbor address] 


Release Information 
Statement introduced in Junos OS Release 9.2. 
Statement introduced in Junos OS Release 11.1 for EX Series switches. 


Description 

Specify the type of Layer 2 traffic originating from the CE device. Only the ethernet and ethernet-vlan 
encapsulation types are supported for VPLS. Not all encapsulation types are supported on the switches. 
See the switch CLI. 


Options 
atm-aal5—ATM Adaptation Layer (AAL/5) 


atm-cell—ATM cell relay 

atm-cell-port-mode—ATM cell relay port promiscuous mode 
atm-cell-vc-mode—ATM VC cell relay nonpromiscuous mode 
atm-cell-vp-mode—ATM virtual path (VP) cell relay promiscuous mode 
cesop—CESOP-based Layer 2 VPN 

cisco-hdlc—Cisco Systems-compatible HDLC 


ethernet—Ethernet 
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ethernet-vian—Ethernet VLAN 
frame-relay—Frame Relay 
frame-relay-port-mode—Frame Relay port mode 
interworking—Layer 2.5 interworking VPN 
ppp—PPP 

satsop-e1—SATSOP-E1-based Layer 2 VPN 
satsop-e3—SATSOP-E3-based Layer 2 VPN 
satsop-t1—SATSOP-T1-based Layer 2 VPN 


satsop-t3—SATSOP-T3-based Layer 2 VPN 
Default: For VPLS networks, the default encapsulation type is ethernet. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Encapsulation Type 

Configuring VPLS Routing Instances 

Configuring the Encapsulation Type for the Layer 2 Circuit Neighbor Interface 
Configuring an MPLS-Based Layer 2 VPN (CLI Procedure) 
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encoding-type 
Syntax 


encoding-type (ethernet | packet | pdh | sonet-sdh); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name Isp-attributes], 
[edit protocols mpls label-switched-path Isp-name Isp-attributes] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 

Specify the encoding type of payload carried by the LSP. It can be any of the following: 
e ethernet—Ethernet 

e packet—Packet 

e pdh—Plesiochronous digital hierarchy (PDH) 

e sonet-sdh—SONET/SDH 


Default 
packet 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Encoding Type | 1264 
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| entropy-label 


Syntax 


entropy-label { 
ingress-policy ingress-policy-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 


Release Information 
Statement introduced in Junos OS Release 14.1. 
Statement introduced in Junos OS Release 17.2R1 for QFX10000 Series switches. 


Description 

Assists the transit router in load-balancing MPLS traffic across ECMP paths or Link Aggregation groups 
by introducing the entropy label to the MPLS label stack. The entropy label allows routers to load balance 
MPLS traffic by using a hash-input without the need to perform deep packet inspection. Deep packet 
inspection requires more of the router’s processing power and is not a capability shared by all routers. 


Options 


The other statements are explained separately. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Entropy Label for LSPs | 534 
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| entropy-label 


Syntax 


entropy-label { 
import policy-name; 
no-next-hop-validation; 


Hierarchy Level 


[edit logical-systems logical-system name protocols bgp family inet labeled-unicast], 

[edit logical-systems logical-system name protocols bgp group group-name family inet labeled-unicast], 

[edit logical-systems logical-system name protocols bgp group group-name neighbor address labeled-unicast], 
[edit protocols bgp family inet labeled-unicast], 

[edit protocols bgp group group-name family inet labeled-unicast], 

[edit protocols bgp group group-name neighbor address labeled-unicast] 


Release Information 
Statement introduced in Junos OS Release 15.1. 
Statement introduced in Junos OS Release 17.2R1 for QFX10000 Series switches. 


Description 

Insert the entropy label into the BGP labeled unicast LSP packets, which assists the transit router in 
load-balancing BGP traffic across equal-cost multipaths or link aggregation groups. The ingress label edge 
router inspects the flow information of a packet and maps it to an entropy label, which is inserted into the 
BGP label stack. LSRs in the core use this entropy label as the key to hash the packet and direct it to the 
correct path. 


Options 


import policy-name— (Optional) Specify a policy that lists the routes that allow the use of entropy labels. 


no-next-hop-validation—(Optional) Do not validate the next-hop field in the entropy label capability 
attribute against the route next hop. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


labeled-unicast 
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policy-statement | 1899 

Configuring an Entropy Label for a BGP Labeled Unicast LSP 

Example: Configuring an Entropy Label for a BGP Labeled Unicast LSP | 535 
Understanding Entropy Label for BGP Labeled Unicast LSP 


| ethernet-vlan (Protocols Link Management) 


Syntax 


ethernet-label { 
vian-id-range vlan-id-range; 


} 


Hierarchy Level 


[edit protocols link-management te-link te-link-name] 


Release Information 
Statement introduced in Junos OS Release 14.2. 


Description 
Specify the TE-link to be used for Layer 2 VLAN label-switched path (LSP). 


Options 


vlan-id-range vlan-id-range—Pool of VALN IDs. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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| ether-pseudowire 


Syntax 


ether-pseudowire { 
zero-control-word; 


Hierarchy Level 


[edit forwarding-options enhanced-hash-key family mpls] 


Release Information 
Statement introduced in Junos OS Release 16.1 for the MX Series. 


Description 
Load-balance IP over Ethernet pseudowire. Presence of zero-control-word in the payload indicates an 


Ethernet frame. 


zero-control-word— Precedes Ethernet packet to indicate the start Ethernet farme in an MPLS 
ether-pseudowire payload. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


enhanced-hash-key 

hash-key 

family mpls | 1779 

MPLS Encapsulated Payload Load-balancing Overview | 187 
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| exclude (for Administrative Groups) 


Syntax 


exclude [ group-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name admin-group], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | secondary) path-name 
admin-group], 

[edit protocols mpls label-switched-path Isp-name admin-group], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name admin-group] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Define the administrative groups to exclude for an LSP or for a path’s primary and secondary paths. 


Options 


group-names—Names of one or more groups defined with the admin-groups statement. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Administrative Groups for LSPs | 503 
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| exclude (for Fast Reroute) 


Syntax 


(exclude [ group-names ] | no-exclude); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name fast-reroute], 
[edit protocols mpls label-switched-path Isp-name fast-reroute] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 14.1X53-D10 for the QFX Series and for EX4600 switches. 


Description 


Control exclusion of administrative groups: 


e exclude—Define the administrative groups to exclude for fast reroute. 


e no-exclude—Disable administrative group exclusion. 
Options 
group-names—Names of one or more groups defined with the admin-groups statement. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Fast Reroute | 474 
admin-groups | 1710 
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| exclude-srlg 


Syntax 


exclude-srlg; 


Hierarchy Level 


[edit protocols mpls], 

[edit logical-systems logical-system-name protocols mpls], 

[edit protocols mpls label-switched-path path-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path path-name], 

[edit protocols rsvp interface interface-name link-protection], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 

[edit protocols rsvp interface interface-name link-protection bypass destination], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass destination] 


Release Information 
Statement introduced in Junos OS Release 11.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Exclude Shared Risk Link Group (SRLG) links for the secondary path for critical links where it is imperative 
to keep the secondary and primary label-switched paths completely disjoint from any common SRLG. 


When specified, the Constrained Shortest Path First (CSPF) algorithm excludes any link belonging to the 
set of SRLGs in the primary path. When not specified and if a link belongs to the set of SRLGs in the primary 
path, CSPF adds the SRLG cost to the metric, but still accepts the link for computing the path. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Excluding SRLG Links Completely for the Secondary LSP | 214 
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| exp 


Syntax 


exp classifier-name { 
import (classifier-name | default); 
forwarding-class class-name { 
loss-priority level { 
code-points [aliases] [3-bit-patterns]; 


} 


Hierarchy Level 


[edit class-of-service classifiers], 
[edit class-of-service code-point-aliases], 
[edit class-of-service interfaces interface-name unit logical-unit-number rewrite-rules], 
[edit class-of-service rewrite-rules] 


Release Information 
Statement introduced in Junos OS Release 10.1 for EX Series switches. 


Description 


Define the experimental bits (EXP) code point mapping that is applied to MPLS packets. You can define 
an exp classifier only on EX3200 switches, EX4200 and EX8200 standalone switches, and EX8200 Virtual 
Chassis. You can bind an exp rewrite rule on EX8200 standalone switches and EX8200 Virtual Chassis. 


EX Series switches support only one EXP code mapping on the switch (either default or custom). It is 
applied globally and implicitly to all the MPLS-enabled interfaces on the switch. You cannot bind it or 
disable it on individual interfaces. 


Options 


classifier-name—Name of the classifier. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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Understanding Using CoS with MPLS Networks on EX Series Switches | 1231 

Configuring MPLS on Provider Edge EX8200 and EX4500 Switches Using Circuit Cross-Connect | 74 
Configuring MPLS on Provider Edge Switches Using IP-Over-MPLS | 68 

Configuring CoS on Provider Switches of an MPLS Network | 1230 


expand-loose-hop 


Syntax 


expand-loose-hop; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 
Statement introduced in Junos OS Release 7.6. 
Point-to-multipoint LSP support introduced in Junos OS Release 11.2. 


Description 


Allow an LSP to traverse multiple OSPF areas within a service provider’s network. 


Allows a point-to-multipoint LSP to span multiple domains in a network. Effectively, this allows you to 
configure one or more sub-LSPs (branches) in separate network domains. Examples of such domains include 
OSPF areas and autonomous systems (ASs). A sub-LSP of an inter-domain point-to-multipoint LSP can be 
intra-area, inter-area, or inter-AS, depending on the location of the egress node (leaf) with respect to the 
ingress node (source). Only OSPF areas are supported for inter-domain point-to-multipoint LSPs. IS-IS 
levels are not supported. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Enabling Interarea Traffic Engineering | 1068 
Configuring Inter-Domain Point-to-Multipoint LSPs | 688 
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| explicit-null (Protocols MPLS) 


Syntax 


explicit-null; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


Description 


Advertise label 0 to the egress router of an LSP. 


Default 


If you do not include the explicit-null statement in the MPLS configuration, label 3 (implicit null) is advertised. 


NOTE: Junos OS does not support explicit null routes with next hops to virtual tunnel (vt-) 
interfaces. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring RSVP to Pop the Label on the Ultimate-Hop Router | 815 
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| export (MPLS Traffic engineering database) 


Syntax 


export { 
credibility; 
policy policy-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls traffic-engineering database], 
[edit protocols mpls traffic-engineering database] 


Release Information 
Statement introduced in Junos OS Release 14.2. 


Description 


Configure the traffic engineering database export-related parameters. 


Options 


policy policy-name—Name of the export policy. 


The remaining statement is explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


traffic-engineering | 1983 
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| failure-action (Protocols MPLS) 


Syntax 


failure-action { 
make-before-break teardown-timeout seconds; 
teardown; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls oam bfd-liveness-detection], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name oam bfd-liveness-detection], 
[edit protocols mpls label-switched-path Isp-name oam bfd-liveness-detection], 

[edit protocols mpls oam bfd-liveness-detection] 


Release Information 
Statement introduced in Junos OS Release 9.4. 


Description 

Configure route and next-hop properties in the event of a Bidirectional Forwarding Detection (BFD) 
protocol session failure event on an RSVP label-switched path (LSP). The failure event could be an existing 
BFD session that has gone down or a BFD session that never came up. RSVP adds back the route or next 
hop when the relevant BFD session comes back up. 


Options 
make-before-break—When a BFD session fails for an RSVP LSP, an attempt is made to signal a new LSP 
path before tearing down the old LSP path. 


teardown—When a BFD session fails for an RSVP LSP, the associated LSP path is taken down and resignaled 
immediately. 


teardown-timeout seconds—When you configure the make-before-break option, you can specify a time 
in seconds for the teardown-timeout option. At the end of the time specified, the associated RSVP LSP 
is automatically torn down and resignaled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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| Configuring a Failure Action for the BFD Session on an RSVP LSP | 146 


| family 
Syntax 


family { 
inet; 
inet6; 


Hierarchy Level 


[edit protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 16.1 for the M320 Series, MX Series, and PTX Series. 


Description 


Configure the address family as inet for IPv4 or inet6 for IPv6, or both. If the address family is not configured, 
then the default address family is IPv4. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


LDP Native IPv6 Support Overview | 865 

Example: Configuring LDP Native IPv6 Support | 986 
Configuring LDP Native IPv6é Support | 984 
dual-transport | 1756 
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| family mpls 
Syntax 


family mpls { 
all-labels; 
label-1; 
label-2; 
label-3; 
no-labels; 
no-label-1-exp; 
payload { 
ether-pseudowire { 
zero-control-word; 
} 
ip { 
disable; 
layer-3-only; 
port-data { 
source-msb; 
source-|sb; 
destination-msb; 
destination-lsb; 


Hierarchy Level 


[edit forwarding-options hash-key] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

no-label-1-exp option introduced in Junos OS Release 8.0. 

label-3 and no-labels options introduced in Junos OS Release 8.1. 

ether-pseudowire statement introduced in Junos OS Release 9.1 (M320 and T Series routers only); support 
extended to M120 and MX Series routers in Junos OS Release 9.4. 

all-labels and payload ip disable options introduced in Junos OS Release 12.1X48R2. (PTX Series Packet 
Transport Routers only). 

zero-control-word option introduced in Junos OS Release 16.1 for the M Series, MX Series, and PTX 
Series. 


Description 
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For aggregated Ethernet and SONET/SDH interfaces only, configure load balancing based on MPLS labels 
and payload. Only the IPv4 protocol is supported. 
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Options 


family mpls—(Aggregated Ethernet interfaces, aggregated SONET/SDH interfaces, and multiple equal-cost 


MPLS next hops only) Incorporate MPLS label and payload information into the hash key for per-flow load 


balancing. Only the IPv4 protocol is supported. 


all-labels—(PTX Series Packet Transport Routers only) Up to eight MPLS labels are included in the hash 
key to identify the uniqueness of a flow in the Packet Forwarding Engine. This is the default setting. 


label-1—(M120, M320, MX Series, and T Series routers only) Include the first MPLS label into the hash 
key. This is used for a one-label packet for per-flow load balancing IPv4 VPLS traffic based on IP 
information and MPLS labels. 


label-2—(M120, M320, MX Series, and T Series routers only) Include the second MPLS label into the 
hash key. This is used for a two-label packet for per-flow load balancing IPv4 VPLS traffic based on IP 
information and MPLS labels. To use the second MPLS label in the hash key, include both the label-1 
and label-2 statements at the [edit forwarding-options hash-key family mpls] hierarchy level. By default, 
the router provides hashing on the first and second labels. If both labels are specified, the entire first 
label and the first 16 bits of the second label are hashed. 


label-3—(M120, M320, MX Series, and T Series routers only) Include the third MPLS label into the hash 
key. To use the third MPLS label, include the label-1, label-2, and label-3 statements at the [edit 
forwarding-options hash-key family mpls] hierarchy level. 


no-labels—Include no MPLS labels into the hash key. 


no-label-1-exp—(M120, M320, MX Series, and T Series routers only) The EXP bit of the first label is not 
used in the hash calculation to avoid reordering complications. 


payload—Incorporate bits from the IP payload into the hash key for per-flow load balancing Layer 2 
information based on MPLS labels. 


e disable—(PTX Series Packet Transport Routers only) Exclude IP payload from the hash key. 


e ether-pseudowire—(M120, M320, MX Series, and T Series routers only) Load-balance |IPv4 traffic 
over Layer 2 Ethernet pseudowires. 


e zero-control-word—(M Series, MX Series, and PTX Series) Precedes Ethernet packet to indicate the 
start of an Ethernet frame in an MPLS ether-pseudowire payload. 


e ip—Include the IP address of the IPv4 or IPv6 payload into the hash key for per-flow load balancing 
Layer 2 information based on MPLS labels. For the PTX Series Packet Transport Routers, this is the 
default setting with both Layer 3 and Layer 4 IP information included in the hash key. 


e disable—(PTX Series Packet Transport Routers only) Exclude IP payload from the hash key. 


e layer-3-only—Include only Layer 3 IP information from the IP payload data into the hash key for 
per-flow load balancing Layer 2 information based on MPLS labels. 


e port-data—(M120, M320, MX Series, and T Series routers only) Include the source and destination 
port field information into the hash key. By default, the most significant byte and least significant 
byte of the source and destination port fields are hashed. To select specific bytes to be hashed, 
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include one or more of the source-msb, source-Isb, destination-msb, and destination-Isb options 
at the [edit forwarding-options hash-key family mpls payload ip port-data] hierarchy level. To 
prevent all four bytes from being hashed, include the layer-3-only statement at the [edit 
forwarding-options hash-key family mpls payload ip] hierarchy level. 


© destination-Ilsb—Include the least-significant byte of the destination port. 
e destination-msb—Include the most-significant byte of the destination port. 
e source-Isb—Include the least-significant byte of the source port. 


e source-msb—Include the most-significant byte of the source port. 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Load Balancing Based on MPLS Labels | 162 
Configuring Load Balancing for Ethernet Pseudowires | 1215 
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| fast-reroute (Protocols MPLS) 


Syntax 


fast-reroute { 
(bandwidth bps | bandwidth-percent percentage); 
(exclude [ group-names ] | no-exclude ); 
hop-limit number; 
(include-all [ group-names ] | no-include-all); 
(include-any [ group-names ] | no-include-any); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 14.1X53-D10 for the QFX Series and for EX4600 switches. 
Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


Description 
Establish detours for the LSP so that if a node or link in the LSP fails, the traffic on the LSP can be rerouted 
with minimal packet loss. 


Options 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Fast Reroute | 474 
Fast Reroute Overview | 472 


MPLS Feature Support on QFX Series and EX4600 Switches | 11 





Understanding Interprovider and Carrier-of-Carriers VPNs | 1312 
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| fate-sharing 


Syntax 


fate-sharing { 
group group-name { 
cost value; 
from address <to address>; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options], 

[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], 
[edit routing-options], 

[edit routing-instances routing-instance-name routing-options] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Specify a backup path in case the primary path becomes unusable. 


You specify one or more objects with common characteristics within a group. All objects are treated as 
/32 host addresses. The objects can be a LAN interface, a router ID, or a point-to-point link. Sequence is 
insignificant. 


Changing the fate-sharing database does not affect existing established LSPs until the next CSPF 
reoptimization. The fate-sharing database does affect fast-reroute detour path computations. 


Options 

cost value—Cost assigned to the group. 
Range: 1 through 65,535 
Default: 1 


from address—Address of the router or address of the LAN/NBMA interface. For example, an Ethernet 
network with four hosts in the same fate-sharing group would require you to list all four of the separate 
from addresses in the group. 
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group group-name—Each fate-sharing group must have a name, which can have a maximum of 32 characters, 
including letters, numbers, periods (.), and hyphens (-). You can define up to 512 groups. 


to address—(Optional) Address of egress router. For point-to-point link objects, you must specify both a 
from and a to address. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Alternate Backup Paths Using Fate Sharing | 490 
MPLS Applications User Guide 
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| forwarding-rib 
Syntax 


forwarding-rib name { 
inet-import [ inet-import ... ]; 


Hierarchy Level 


[edit logical-systems name routing-instances name routing-options dynamic-tunnels], 

[edit logical-systems name routing-options dynamic-tunnels], 

[edit logical-systems name tenants name routing-instances name routing-options dynamic-tunnels], 
[edit routing-instances name routing-options dynamic-tunnels], 

[edit routing-options dynamic-tunnels], 

[edit tenants name routing-instances name routing-options dynamic-tunnels] 


Release Information 
Statement introduced in Junos OS Release 18.3R1 on PTX Series routers and QFX Series switches. 


Description 
Configure policy control for forwarding routing table next hops for MPLS-over-UDP dynamic tunnels. 
With this configuration, you can resolve the dynamic tunnel destination routes over select prefixes. 


Options 


name—Name of the routing table. 


inet-import—Name of the import policy for IPv4 dynamic-tunnels. 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Example: Configuring Next-Hop-Based MPLS-Over-UDP Dynamic Tunnels | 94 
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| forwarding-table 


Syntax 


forwarding-table { 
export [ policy--names ]; 
(indirect-next-hop | no-indirect-next-hop); 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options], 
[edit routing-options] 


Release Information 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Configure information about the routing device’s forwarding table. 


The remaining statements are explained separately. See CLI Explorer. 


Options 
remnant-holdtime—Sets the remnant hold time, which is required for the MXVC-ISSU, where the 
recommended value is 900.. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Per-Packet Load Balancing 
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| from (Protocols MPLS) 


Syntax 


from address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


Description 


Specify the source address to use for the LSP. 


The address you specify does not affect the outgoing interface used by the LSP. 


Default 


If you do not include this statement, the software automatically selects the loopback interface as the 
address. 


Options 


address—IP address. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Ingress Router Address for LSPs | 485 
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| gpid 
Syntax 


gpid (ethernet | hdlc | ipv4 | pos-scrambling-crc-16 | pos-no-scrambling-crc-16 | pos-scrambling-crc-32 | 
pos-no-scrambling-crc-32 | ppp); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name Isp-attributes], 
[edit protocols mpls label-switched-path Isp-name Isp-attributes] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

pos-scrambling-crc-16, pos-no-scrambling-crc-16, pos-scrambling-crc-32, and pos-no-scrambling-crc-32 
options added in Junos OS Release 8.0. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Specify the type of payload carried by the LSP. It can be any of the following: 

e ethernet—Ethernet (GPID value: 33) 

e hdic—High-level Data Link Control (HDLC) (GPID value: 44) 

e ipv4—IP version 4 (GPID value: Ox0800) 

e pos-no-scrambling-crc-16—for interoperability with other vendors’ equipment (GPID value: 29) 
e pos-no-scrambling-crc-32—for interoperability with other vendors’ equipment (GPID value: 30) 
e pos-scrambling-crc-16—for interoperability with other vendors’ equipment (GPID value: 31) 

e pos-scrambling-crc-32—for interoperability with other vendors’ equipment (GPID value: 32) 


ppp—Point-to-Point Protocol (PPP) (GPID value: 50) 


Default 
ipv4 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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Configuring the GPID | 1265 
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gre (Routing Options) 
Syntax 


gre, 
next-hop-based-tunnel; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name], 
[edit routing-options dynamic-tunnels tunnel-name] 


Release Information 
Statement introduced in Junos OS Release 10.1. 
next-hop-based-tunnel option introduced in Junos OS Release 16.2. 


Description 
Enable generic routing encapsulation (GRE) type for IPv4 to automatically establish label-switched paths 
(LSPs) for any new provider edge (PE) router added to a full mesh of LSPs. 


Options 

next-hop-based-tunnel—Create a tunnel composite next hop for every dynamic GRE tunnel configured. 
The tunnel composite next hop includes the dynamic tunnel’s encapsulation data and a VPN label 
(when chained composite next hop is not enabled). When this option is not configured, the default 
interface-based tunnel mode is enabled. By configuring this option, a device can scale up to 32,000 
IP tunnels, which is otherwise restricted to the system limit on the number of interfaces supported. 


At a given point in time, either the next-hop-based dynamic tunnel or the default interface-based 
dynamic GRE tunnel can exist on a device. A switchover from one tunnel mode to another deletes the 
existing tunnels and creates new tunnels in the new tunnel mode. As a result, a tunnel mode switchover 
can impact network performance. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring MPLS-Signaled LSPs to Use GRE Tunnels 


| hop-limit 
Syntax 


hop-limit number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name fast-reroute], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name fast-reroute], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name], 

[edit protocols rsvp interface interface-name link-protection], 

[edit protocols rsvp interface interface-name link-protection bypass bypass-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Specify the maximum number of routers that an LSP can traverse. This limit can be applied to any of the 
following: 


e LSPs—The configured hop limit includes the ingress and egress routers. You can specify a hop limit for 
an LSP and for both primary and secondary paths. 


e Fast reroute detour—Specify the number of additional routers a fast reroute detour can traverse relative 
to the protected LSP. For example, if an LSP traverses 4 routers, any detour for the LSP can be no more 
than 10 router hops, including the ingress and egress routers. 


e Link protection bypass—Specify the maximum number of routers that a link protection bypass can 
traverse. 


Options 

number—Maximum number of hops. 
Range: 2 through 255 (for an LSP or for a link protection bypass); O through 255 (for fast reroute) 
Default: 255 (for an LSP or for a link protection bypass); 6 (for fast reroute) 
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Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Fast Reroute | 474 
Limiting the Number of Hops in LSPs | 516 
Configuring the Hop Limit for Bypass LSPs | 381 
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| import (MPLS Traffic Engineering Database) 


Syntax 


import { 
bgp-ls-identifier domain-identifier; 
identifier identifier; 
policy policy-name; 
igp-topologyf{ 
bgp-link-state; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls traffic-engineering database], 
[edit protocols mpls traffic-engineering database] 


Release Information 
Statement introduced in Junos OS Release 14.2. 


Description 


Configure the traffic engineering database import parameters. 


Options 
bgp-ls-identifier domain-identifier—BGP-TE domain identifier. 


identifier identifier—BGP-TE identifier. 
Range: 2 through 18446744073709551615 


policy policy-name—Name of the import policy. 


igp-topology—Download IGP topology information into the traffic engineering database (TED). In Junos 
OS, the IGPs install topology information into a database called the traffic engineering database. The 
traffic engineering database contains the aggregated topology information. The IGP routes are installed 
by the traffic engineering database on behalf of the corresponding IGP into a user-visible routing table 
called Isdist.0, subject to route policies. 


bgp-link-state—Export IGP topology information into BGP-Link State (BGP-LS) from the Isdist.0 routing 
table. The Isdist.0 routing table stores the network topology information from the traffic engineering 
database. The BGP-LS reads IGP entries from Isdist.0 and advertises the information to BGP peers. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


traffic-engineering | 1983 
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| ip-tunnel-rpf-check 
Syntax 


ip-tunnel-rpf-check { 
mode (strict | loose); 
fail-filter filter-name; 


Hierarchy Level 


[edit routing-instances routing-instance-name routing-options forwarding-table] 


Release Information 
Statement introduced in Junos OS Release 17.1 for MX Series Routers with MICs. 


Description 

Configure the system to enable anti-spoofing protection for next-hop-based dynamic tunnels, where 
reverse path forwarding checks are placed to ensure that the tunnel traffic is received from a legitimate 
source through designated IP tunnel, where the source is reachable on the same tunnel on which the 
packet was received. 


When a packet comes from a nondesignated source, the reverse path forwarding check fails in the strict 
mode, and passes in the loose mode. When a packet comes from a nonexistent source, the reverse path 
forwarding check fails. 


By default, the reverse path forwarding check is in strict mode, where the packets are not forwarded if 
the source of the packet is from a nondesignated tunnel. 


Options 
mode (strict | loose)—(Optional) Specify the mode of the reverse path forwarding check to enable 
anti-spoofing protection for next-hop-based dynamic tunnels. 


In the strict mode (default), the reverse path forwarding check fails when the packet is received from 
a nondesignated tunnel source. The check passes only for packets from designated tunnels. 


In the loose mode, the reverse path forwarding check passes even if the packet is received from a 
nondesignated tunnel source. 


When the packet is from a nonexistent tunnel source, the reverse path forwarding check fails in both 
the strict and loose modes. 


Default: If you omit the mode statement, the default behavior is strict mode. 


fail-filter filter-name—(Optional) Attach a filter to the Layer 3 VPN to log packets that failed the reverse 
path forwarding check. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Anti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels Overview | 112 
Example: Configuring Anti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels | 115 
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| ipv4 (Family MPLS) 
Syntax 


ipv4 { 

destination-address ip-address { 
except; 

} 

destination-prefix-list destination-prefix-list-name { 
except; 

} 

protocol protocol { 
(source-port | source-port-except); 
(destination-port | destination-port-except); 

} 

source-address ip-address { 
except; 

} 

source-prefix-list source-prefix-list-name { 


except; 


Hierarchy Level 


[edit firewall family mpls filter name term name from ip-version] 


Release Information 
Statement introduced in Junos OS Release 18.4R1 on MX Series routers with MPC and MIC interfaces. 


Description 


Define Layer 3 and Layer 4 match items to match IPv4 packets for IP-based filtering of MPLS traffic. 


Options 
destination-address ip-address—Match MPLS traffic with the specified IPv4 destination address. 


destination-prefix-list destination-prefix-list-name—Match MPLS traffic with the specified IPv4 destination 
prefixes. The prefix-list is defined under the [edit policy-options prefix-list prefix-list-name] hierarchy 
level. 


protocol protocol—Specify one or a range of inner IPv4 protocols for IP-based filtering of MPLS traffic. 


source-address ip-address—Match MPLS traffic with the specified IPv4 source address. 
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source-prefix-list source-prefix-list-name—Match MPLS traffic with the specified IPv4 source prefixes. The 
prefix-list is defined under the [edit policy-options prefix-list prefix-list-name] hierarchy level. 


Required Privilege Level 
firewall—To view this statement in the configuration. 
firewall-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding IP-Based Filtering and Selective Port Mirroring of MPLS Traffic | 194 
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| ipv6 (Family MPLS) 
Syntax 


ipvé { 

destination-address destination-ip-address { 
except; 

} 

destination-prefix-list prefix-list-name { 
except; 

} 

protocol protocol { 
(source-port | source-port-except); 
(destination-port | destination-port-except); 

} 

source-address ip-address { 
except; 

} 

source-prefix-list source-prefix-list-name { 


except; 


Hierarchy Level 


[edit firewall family mpls filter name term name from ip-version], 


Release Information 
Statement introduced in Junos OS Release 18.4R1 on MX Series routers with MPC and MIC interfaces. 


Description 


Define Layer 3 and Layer 4 match items to match IPv6 packets for IP-based filtering of MPLS traffic. 


Options 
destination-address ip-address—Match MPLS traffic with the specified IPv6é destination address. 


destination-prefix-list destination-prefix-list-name—Match MPLS traffic with the specified list of IPvé 
destination prefixes. The prefix-list is defined under the [edit policy-options prefix-list prefix-list-name] 
hierarchy level. You must configure separate prefix-lists for IPv4 and IPv6é addresses. 


protocol protocol—Specify one or a range of inner IPv6é next header for IP-based filtering of MPLS traffic. 


source-address ip-address—Match MPLS traffic with the specified IPv6 source address. 
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source-prefix-list source-prefix-list-name—Match MPLS traffic with the specified IPv6 source prefixes. The 
prefix-list is defined under the [edit policy-options prefix-list prefix-list-name] hierarchy level. You 
must configure separate prefix-lists for IPv4 and IPv6 addresses. 


Required Privilege Level 
firewall 


ip-version (Family MPLS) 
Syntax 


ip-version { 
ipv4; 
ipv6; 

} 


Hierarchy Level 


[edit firewall family mpls filter name term name from] 


Release Information 
Statement introduced in Junos OS Release 18.4R1 on MX Series routers with MPC and MIC interfaces. 


Description 


Specify inner IP version to enable IP-based filtering of MPLS family filter. 


The remaining statements are explained separately. Search for a statement in CL! Explorer or click a linked 
statement in the Syntax section for details. 


Required Privilege Level 
firewall—To view this statement in the configuration. 
firewall-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding IP-Based Filtering and Selective Port Mirroring of MPLS Traffic | 194 
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| include-all (for Administrative Groups) 


Syntax 


include-all [ group-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name admin-group], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | secondary) path-name 
admin-group], 

[edit protocols mpls label-switched-path Isp-name admin-group], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name admin-group] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Require the LSP to traverse links that include all of the defined administrative groups. 


Options 


group-names—One or more names of groups defined with the admin-groups statement. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Administrative Groups for LSPs | 503 
admin-groups | 1710 
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| include-all (for Fast Reroute) 


Syntax 


(include-all [ group-names ] | no-include-all); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name fast-reroute], 
[edit protocols mpls label-switched-path Isp-name fast-reroute] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 14.1X53-D10 for the QFX Series and for EX4600 switches. 


Description 


Control inclusion of administrative groups: 


e include-all—Define the administrative groups that must all be included for fast reroute. 


e no-include-all—Disable administrative group inclusion. 
Options 
group-names—One or more names of groups defined with the admin-groups statement. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Fast Reroute | 474 
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| include-any (for Administrative Groups) 


Syntax 


include-any [ group-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name admin-group], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | secondary) path-name 
admin-group], 

[edit protocols mpls label-switched-path Isp-name admin-group], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name admin-group] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Define the administrative groups to include for an LSP or for a path’s primary and secondary paths. 


Options 


group-names—One or more names of groups defined with the admin-groups statement. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Administrative Groups for LSPs | 503 
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| include-any (for Fast Reroute) 


Syntax 


(include-any [ group-names ] | no-include-any); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name fast-reroute], 
[edit protocols mpls label-switched-path Isp-name fast-reroute] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 14.1X53-D10 for the QFX Series and for EX4600 switches. 


Description 


Control inclusion of administrative groups: 


e include-any—Define the administrative groups to include for fast reroute. 


e no-include-any—Disable administrative group inclusion. 
Options 
group-names—One or more names of groups defined with the admin-groups statement. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Fast Reroute | 474 
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| ingress (LSP) 
Syntax 


ingress { 
bandwidth bps; 
class-of-service cos-value; 
description string; 
entropy-label; 
install { 
destination-prefix <active>; 
} 
link-protection bypass-name name; 
metric metric; 
next-hop (address | interface-name | address/interface-name); 
node-protection bypass-name name next-next-label label; 
no-install-to-address; 
policing { 
filter filter-name; 
no-auto-policing; 
} 
preference preference; 
push out-label; 
to address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name], 
[edit protocols mpls static-label-switched-path Isp-name] 


Release Information 

Statement introduced in Junos OS Release 10.1. 

entropy-label option introduced in Junos OS Release 14.1. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Configure an ingress LSR for a static LSP. 


The remaining statements are explained separately 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


1807 


RELATED DOCUMENTATION 


Configuring Static LSPs | 574 
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| install (Protocols MPLS) 


Syntax 


install { 
destination-prefix <active>; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 
[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls static-label-switched-path Isp-name ingress] 

[edit protocols source-packet-routing source-routing-path Isp-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 

Support at the [edit protocols source-packet-routing source-routing-path Isp-name] hierarchy level 
introduced in Junos OS Release 19.1R1. 


Description 
Associate one or more prefixes with an LSP. When the LSP is up, all the prefixes are installed as entries 
into the inet.3 or inet6.3 routing table. 


The support of the install statement at the [edit protocols source-packet-routing source-routing-path 
Isp-name] is applicable for both colored and non-colored segment routing LSPs. 


For static colored LSPs, when the install prefix is configured, a route similar to the tunnel ingress route is 
installed in the inetcolor.0O or inet6color.0 routing table. 


On the other hand, for static non-colored LSPs, when the install prefix is configured, a route similar to the 
tunnel to route is installed in inet.3 or inet6.3 routing table. 


You can use the show route table command to view the install routes for both colored and non-colored 
segment routing traffic-engineered LSPs. 
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NOTE: 


Take the following into consideration when configuring the install destination-prefix statement 
at the [edit protocols source-packet-routing source-routing-path Isp-name] hierarchy level: 


e The install prefixes should be unique in a tunnel, and should not be the same as the tunnel to 
address. A commit check is done to ensure that the prefixes are unique. 


e If two install prefixes are same across two different tunnels, then the gateways of the both 
tunnels are considered only if the segment lists are of the same resolution type. If the first hop 
resolution types vary, the route is not installed. In such cases, a system log message is generated 
to record the error. 


For example: 


[edit protocols source-packet-routing] 
segment-list path-1 { 
hop-1 ip-address 172.0.12.2; 
hop-2 label 1000012; 
hop-3 label 1000013; 
hop-4 label 1000014; 
} 
source-routing-path Isp1 { 
to 10.10.10.1; 
install 20.20.20.2; 
install 30.30.30.3; 
primary { 
path-1; 


The inet.3 routing table has two additional routes (to 20.20.20.2 and 30.30.30.3) with next hops 
derived from the same segment list path-1 with same attributes as the to address route. 
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Options 


active—(Optional) Install the route into the inet.O or inet6.0 routing table. This allows you to issue a ping 
or traceroute command on this address. 


NOTE: The install destination-prefix active statement is not supported on static LSPs. When 
the install destination-prefix active statement is configured for a static LSP, the MPLS routes 
do not get installed into the inet.O routing table. 


destination-prefix—|Pv4 or IPvé address to associate with the LSP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Adding LSP-Related Routes to the inet.3 or inet6.3 Routing Table | 477 
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| ingress-policy 
Syntax 


ingress-policy [ ingress-policy-names ]; 


Hierarchy Level 


[edit logical-system logical-system-name protocols Idp entropy-label], 
[edit logical-system logical-system-name protocols Idp oam], 

[edit protocols Idp entropy-label], 

[edit protocols Idp oam] 


Release Information 

Statement introduced in Junos OS Release 9.4. 

Statement introduced at the [edit protocols Idp entropy-label] hierarchy level in Junos OS Release 14.1. 
Statement introduced in Junos OS Release 17.2R1 for QFX10000 Series switches. 


Description 


Configure an LDP ingress policy for either the entropy label or Operation, Administration, and Management 
(OAM). 


For OAM, configure the ingress policy to choose which forwarding equivalence classes (FECs) need to 
have OAM enabled. If the FEC passes through the policy or if the FEC is explicitly configured, OAM is 
enabled for a FEC. For FECs chosen using a policy, the BFD parameters configured under [edit protocols 
Idp oam bfd-liveness-detection] are applied. 


Options 


ingress-policy-names—Specify the names of the ingress policies. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring OAM Ingress Policies for LDP | 1148 
Configuring the Entropy Label for LSPs | 534 
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| interface (Protocols MPLS) 


Syntax 


interface (interface-name | all) { 
disable; 
admin-group [ group-names ]; 
srlg srlg-name; 


} 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


Description 


Enable MPLS on one or more interfaces. 


Options 
interface-name—Name of the interface on which to configure MPLS. To configure all interfaces, specify 
all. For details about specifying interfaces, see the Junos OS Network Interfaces Library for Routing Devices. 


srlg srlg-name—Name of the SRLG to associate with an interface. 


The remaining options are explained separately. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Intermediate (Transit) and Egress Routers for Static LSPs | 578 
Example: Configuring SRLG | 201 
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| interface (MPLS) 


Syntax 


interface (all | interface-name); 


Hierarchy Level 


[edit protocols mpls] 


Release Information 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Enable MPLS on all interfaces on the switch or on the specified interface. 


Default 
MPLS is disabled. 


Options 

all—All interfaces on the switch. 
interface-name—Name of an interface: 
e Aggregated Ethernet—aex 

e Gigabit Ethernet—ge-fpc/pic/port 
Required Privilege Level 


routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring MPLS on EX8200 and EX4500 Switches | 42 

Configuring CoS on an MPLS Provider Edge Switch Using IP Over MPLS | 1225 
Configuring CoS on an MPLS Provider Edge Switch Using Circuit Cross-Connect | 1228 
Configuring MPLS on EX8200 and EX4500 Provider Switches | 78 
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| inter-domain 


Syntax 


inter-domain; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path label-switched-path-name], 
[edit protocols mpls label-switched-path label-switched-path-name] 


Release Information 
Statement introduced in Junos OS Release 10.2. 


Description 

Allows the router to search for routes in the IGP database. You need to configure this statement on routers 
that might be unable to locate a path using intra-domain CSPF (by looking in the traffic engineering database 
(TED). When you configure inter-area or inter-AS LSPs, the inter-domain statement is required. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring an LSP Across ASs | 529 
label-switched-path | 1817 
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| ip-tunnel-rpf-check 
Syntax 


ip-tunnel-rpf-check { 
mode (strict | loose); 
fail-filter filter-name; 


Hierarchy Level 


[edit routing-instances routing-instance-name routing-options forwarding-table] 


Release Information 
Statement introduced in Junos OS Release 17.1 for MX Series Routers with MICs. 


Description 

Configure the system to enable anti-spoofing protection for next-hop-based dynamic tunnels, where 
reverse path forwarding checks are placed to ensure that the tunnel traffic is received from a legitimate 
source through designated IP tunnel, where the source is reachable on the same tunnel on which the 
packet was received. 


When a packet comes from a nondesignated source, the reverse path forwarding check fails in the strict 
mode, and passes in the loose mode. When a packet comes from a nonexistent source, the reverse path 
forwarding check fails. 


By default, the reverse path forwarding check is in strict mode, where the packets are not forwarded if 
the source of the packet is from a nondesignated tunnel. 


Options 
mode (strict | loose)—(Optional) Specify the mode of the reverse path forwarding check to enable 
anti-spoofing protection for next-hop-based dynamic tunnels. 


In the strict mode (default), the reverse path forwarding check fails when the packet is received from 
a nondesignated tunnel source. The check passes only for packets from designated tunnels. 


In the loose mode, the reverse path forwarding check passes even if the packet is received from a 
nondesignated tunnel source. 


When the packet is from a nonexistent tunnel source, the reverse path forwarding check fails in both 
the strict and loose modes. 


Default: If you omit the mode statement, the default behavior is strict mode. 


fail-filter filter-name—(Optional) Attach a filter to the Layer 3 VPN to log packets that failed the reverse 
path forwarding check. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Anti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels Overview | 112 
Example: Configuring Anti-Spoofing Protection for Next-Hop-Based Dynamic Tunnels | 115 


ipv6-tunneling 
Syntax 


ipv6-tunneling; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 14.1X53-D30 for QFX Series switches. 


Description 


Allow IPvé6 routes to be resolved over an MPLS network by converting LDP and RSVP routes stored in 
the inet.3 routing table to IPv4-mapped IPv6 addresses and then copying them into the inet6.3 routing 
table. This routing table can be used to resolve next hops for both inet6 and inet6-vpn routes. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Tunneling IPv6 Traffic over MPLS IPv4 Networks | 82 
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| label-switched-path (Protocols MPLS) 


Syntax 


label-switched-path Isp-name { 

disable; 

adaptive; 

admin-down; 

admin-group { 
exclude [ group-names ]; 
include-all [ group-names ]; 
include-any [ group-names ]; 

} 

auto-bandwidth { 
adjust-interval seconds; 
adjust-threshold percentage; 
maximum-bandwidth bps; 
minimum-bandwidth bps; 
monitor-bandwidth; 

} 

bandwidth bps { 
ctO bps; 
ct1 bps; 
ct2 bps; 
ct3 bps; 

} 

class-of-service cos-value; 

cross-credibility-cspf; 

description text; 

entropy-label; 

fast-reroute { 
(bandwidth bps | bandwidth-percent percentage); 
(exclude [ group-names ] | no-exclude); 
hop-limit number; 
(include-all [ group-names ] | no-include-all); 
(include-any [ group-names ] | no-include-any); 

} 

from address; 

install { 
destination-prefix/prefix-length <active>; 

} 

inter-domain; 

Idp-tunneling; 

link-protection; 

Isp-attributes { 
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Isp-external-controller; 
encoding-type (ethernet | packet | pdh | sonet-sdh); 
gpid (ethernet | hdlc | ipv4 | pos-scrambling-crc-16 | pos-no-scrambling-crc-16 | pos-scrambling-crc-32 | 
pos-no-scrambling-crc-32 | ppp); 
signal-bandwidth type; 
switching-type (fiber | lambda | psc-1 | tdm); 
} 
metric metric; 
no-cspf; 
no-decrement-ttl; 
node-link-protection; 
optimize-timer seconds; 
p2mp Isp-name; 
policing { 
filter filter-name; 
no-auto-policing; 
} 
preference preference; 
primary path-name { 
adaptive; 
admin-group { 
exclude [ group-names ]; 
include-all [ group-names ]; 
include-any [ group-names ]; 
} 
bandwidth bps { 
ctO bps; 
ct1 bps; 
ct2 bps; 
ct3 bps; 
} 
class-of-service cos-value; 
hop-limit number; 
no-cspf; 
no-decrement-ttl; 
optimize-timer seconds; 
preference preference; 
priority setup-priority reservation-priority; 
(record | no-record); 
select (manual | unconditional); 
standby; 
} 
priority setup-priority reservation-priority; 
(random | least-fill | most-fill); 
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(record | no-record); 
retry-limit number; 
retry-timer seconds; 
revert-timer seconds; 
secondary path-name { 
adaptive; 
admin-group { 
exclude[ group-names ]; 
include-all [ group-names ]; 
include-any [ group-names ]; 
} 
bandwidth bps { 
ctO bps; 
ct1 bps; 
ct2 bps; 
ct3 bps; 
} 
class-of-service cos-value; 
hop-limit number; 
no-cspf; 
no-decrement-ttl; 
optimize-timer seconds; 
preference preference; 
priority setup-priority reservation-priority; 
(record | no-record); 
select (manual | unconditional); 
standby; 
} 
soft-preemption; 
standby; 
to address; 
traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag <flag-modifier> <disable>; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 
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Release Information 

Statement introduced before Junos OS Release 7.4. 

cross-credibility-cspf option introduced in Junos OS Release 14.2. 
self-ping-duration and no-self-ping options introduced in Junos OS Release 16.1. 


Description 
Configure an LSP to use in dynamic MPLS. When configuring an LSP, you must specify the address of the 
egress router in the to statement. All remaining statements are optional. 
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Options 

Isp-name—Name that identifies the LSP. The name can be up to 64 characters and can contain letters, 
digits, periods, and hyphens. To include other characters, enclose the name in quotation marks. The 
name must be unique within the ingress router. 


cross-credibility-cspf—Enable path computation across credibility levels. The constraint path computation 
is run across multi-protocol links and nodes, instead of a credibility-by-credibility basis. 


link-protection—Enable protection for LSP from link faults only. 


no-self-ping—Disable self-ping for the LSP. 


NOTE: Starting in Junos OS 17.4, you can override the behavior of self-ping running by default 
using no-self-ping statement. 


self-ping-duration seconds—Specify the duration (in seconds) for which to run the self-ping mechanism 
unless the ping succeeds sooner. 


LSP self-ping for an LSP starts at the ingress label edge router (LER), once a Resv message for that 
LSP has been received. The configured self-ping time indicates the duration for which the self-ping 
mechanism runs once the LSP instance is signaled to be UP. 


By default, self-ping is enabled. The LSP types like CCC, P2MP, VLAN-based , and non-default instances 
do not support self-ping . 


The self-ping mechanism runs until the self-ping probe is received back (at which point the traffic is 
immediately switched to it) , or until the configured self-ping duration for the LSP is over (at which 
point traffic is switched over). 


When LSP self-ping-duration is enabled, the LSP behavior reverts back to a timer-based mechanism 
similar to the optimize-switchover-delay, where a specific amount of time is provided for all the 
downstream nodes to install the forwarding path before switchover. When LSP self-ping-duration is 
not enabled, the default behavior is to wait for an infinite amount of time for the self-ping to succeed 
before switching the traffic. 


Range: 1 through 65535 seconds 
NOTE: Starting in Junos OS 17.4R1, the default time-out duration for which the self-ping runs 


on an LSP instance is reduced from 65535 (runs until success) to 1800 seconds. You can also 
configure the self ping duration value between 1 to 65535 (runs until success) seconds. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Ingress and Egress Router Addresses for LSPs | 485 
Configuring Primary and Secondary LSPs | 570 
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| label-switched-path 


Syntax 


label-switched-path Isp-name to remote-provider-edge-switch; 


Hierarchy Level 


[edit protocols mpls] 


Release Information 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 


Description 
Define a label-switched path (LSP) to the remote provider edge switch to use for MPLS traffic. You must 
specify this statement on the provider edge switch. 


Options 

Isp-name —Name that identifies the LSP. The name can be up to 32 characters and can contain letters, 
digits, periods, and hyphens. To include other characters, enclose the name in quotation marks. The name 
must be unique on the ingress switch. 


remote-provider-edge-switch —Either the loopback address or the switch address. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring MPLS on EX8200 and EX4500 Switches | 42 
Configuring CoS on an MPLS Provider Edge Switch Using IP Over MPLS | 1225 
Configuring CoS on an MPLS Provider Edge Switch Using Circuit Cross-Connect | 1228 
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| label-switched-path-template (Container LSP) 


Syntax 


label-switched-path-template { 
(default-template | Isp-template-name); 


} 


Hierarchy Level 


[edit protocols mpls container-label-switched-path Isp-name] 
[edit routing-instances instance-name provider-tunnel] 


Release Information 

Statement introduced in Junos OS Release 14.2. 

Statement introduced for QFX Switches in Junos OS Release 15.1X53-D30. 

Statement introduced in Junos OS Release 18.2. under the heirarchy level [edit routing-instances 
instance-name provider-tunnell] 


Description 


Specify the LSP template. An LSP template is used as the basis for other dynamically generated LSPs. 


Options 
default-template—Specify that the default LSP template be used for the dynamically generated LSPs. 


Isp-template-name—Specify the name of an LSP to be used as a template for the dynamically generated 
LSPs. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


container-label-switched-path | 1743 
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| Idp-tunneling 
Syntax 


Idp-tunneling; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Enable the LSP to be used for LDP tunneling. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| Enabling LDP over RSVP-Established LSPs | 1047 


| least-fill 


See 
random 
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| link-protection (Dynamic LSPs) 


Syntax 


link-protection; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 14.1X53-D10 for the QFX Series and for EX4600 switches. 


Description 

Enable link protection on the specified LSP, which helps to ensure that traffic sent over a specific interface 
to a neighboring router can continue to reach the router if that interface fails. For point-to-multipoint 
LSPs, including this statement extends link protection to all of the paths used by the LSP. 


To fully enable link protection, you must also include the link-protection statement at the [edit protocols 
rsvp interface interface-name] or [edit logical-systems logical-system-name protocols rsvp interface 
interface-name] hierarchy level. 


Default 
Link protection is disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Link Protection for Point-to-Multipoint LSPs | 690 
Configuring Node Protection or Link Protection for LSPs | 385 
link-protection (RSVP) | 2026 
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| link-protection (Static LSPs) 


Syntax 


link-protection bypass-name name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name transit incoming-label], 
[edit protocols mpls static-label-switched-path Isp-name ingress], 

[edit protocols mpls static-label-switched-path Isp-name transit incoming-label] 


Release Information 
Statement introduced in Junos OS Release 10.1. 


Description 
Enable link protection on the specified static LSP. Link protection helps to ensure that traffic sent over a 
specific interface to a neighboring router can continue to reach the router if that interface fails. 


Default 


Link protection is disabled. 


Options 


bypass-name name—Bypass LSP name. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Static LSPs | 574 
Example: Configuring a Collection of Paths to Create an RSVP-Signaled Point-to-Multipoint LSP | 661 
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| load-balance-label-capability 


Syntax 


load-balance-label-capability; 


Hierarchy Level 


[edit forwarding-options] 


Release Information 
Statement introduced in Junos OS Release 14.1. 


Description 
Enables the router to push and pop the load balancing label and causes LDP and RSVP to advertise the 
entropy label TLV to neighboring routers. 


The load-balance-label-capability and no-load-balance-label-capability statements at the [edit 
forwarding-options] hierarchy level are mutually exclusive, and at a given point in time, configuring one 
statement overrides the other. 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Entropy Label for LSPs | 534 
no-load-balance-label-capability | 1868 
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log-updown (Protocols MPLS) 


Syntax 


log-updown { 

no-trap { 
mpls-Isp-traps; 
rfc3812-traps; 

} 

(syslog | no-syslog); 

trap; 

trap-path-down; 

trap-path-up; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

The mpls-Isp-traps and rfc-3812-traps options added in Junos OS Release 9.0. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


Description 

Log a message or send an SNMP trap whenever an LSP makes a transition from up to down, or vice versa, 
and whenever an LSP switches from one active path to another. Only the ingress router performs these 
operations. 


NOTE: System log messages for LSPs are generated by default. To disable the default logging 
of messages for LSPs, configure the no-syslog option under the log-updown statement. 


Default 


There is no default behavior for this statement. If you do not specify the options, the configuration cannot 
be committed. 


Options 


no-syslog—Do not log a message to the system log file. 
no-trap—Do not send an SNMP trap. 
syslog—Log a message to the system log file. 


trap—Send an SNMP trap. 


trap-path-down—Send an SNMP trap when an LSP path goes down. 


trap-path-up—Send an SNMP trap when an LSP path comes up. 


The no-trap statement is explained separately. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


System Log Messages and SNMP Traps for MPLS | 160 
Network Management and Monitoring Guide 

no-trap | 1872 

traceoptions (Protocols MPLS) | 1974 
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| longest-match 


Syntax 


longest-match { 
policy value |(expression) | [values ]; 


} 


Hierarchy Level 


[edit protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 16.1 for the M Series, MX Series, and PTX Series. 


Description 


Enable longest match to allow LDP to learn the routes aggregated or summarized across OSPF areas or 
IS-IS levels in inter-domain. 

Options 

policy value |(expression) | [values ]— Specify policy to provide per prefix granularity. 

Required Privilege Level 


routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Longest Match Support for LDP Overview | 866 
Example: Configuring Longest Match for LDP | 873 
Configuring Longest Match for LDP | 872 
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| loss (querier) 


Syntax 


loss { 
traffic-class tc-value { 
average-sample-size sample size; 
loss-threshold loss threshold value; 
loss-threshold-window number of samples for loss threshold; 
measurement-quantity bytes|packets; 
query-interval milliseconds; 


Hierarchy Level 


[edit protocols mpls oam performance-monitoring querier], 

[edit protocols mpls label-switched-path Isp-name oam performance-monitoring querier], 

[edit protocols mpls label-switched-path Isp-name primary path-name oam performance-monitoring querier], 
[edit protocols mpls label-switched-path Isp-name secondary path-name oam performance-monitoring querier] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Configure loss measurement options. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Pro-Active Loss and Delay Measurements | 417 
On-Demand Packet Loss and Delay Measurement for UHP LSPs Overview | 388 
performance-monitoring (Protocols MPLS) | 1893 
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| loss (responder) 


Syntax 


loss { 
min-query-interval milliseconds; 


Hierarchy Level 


[edit protocols mpls oam performance-monitoring responder], 

[edit protocols mpls label-switched-path Isp-name oam performance-monitoring responder], 

[edit protocols mpls label-switched-path Isp-name primary path-name oam performance-monitoring responder], 
[edit protocols mpls label-switched-path Isp-name secondary path-name oam performance-monitoring responder] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Configure loss measurement options. 


Options 

min-query-interval milliseconds—(Optional) Specify the minimum query interval that the responder supports. 
If the minimum query interval of the responder is greater than the query interval configured at the 
querier, the effective message query rate is the minimum query interval configured for the responder. 


Default: 10 seconds 
Range: 1000 through 4294967295 milliseconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Pro-Active Loss and Delay Measurements | 417 
On-Demand Packet Loss and Delay Measurement for UHP LSPs Overview | 388 
performance-monitoring (Protocols MPLS) | 1893 
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| loss-delay (querier) 


Syntax 


loss-delay { 
traffic-class tc-value { 

average-sample-size sample size; 
loss-threshold loss threshold value; 
loss-threshold-window number of samples for loss threshold; 
measurement-quantity bytes|packets; 
padding-size size; 
query-interval milliseconds; 
rtt-delay-threshold rtt threshold value; 
twcd-delay-threshold twcd threshold value; 


Hierarchy Level 


[edit protocols mpls oam performance-monitoring querier], 

[edit protocols mpls label-switched-path Isp-name oam performance-monitoring querier], 

[edit protocols mpls label-switched-path Isp-name primary path-name oam performance-monitoring querier], 
[edit protocols mpls label-switched-path Isp-name secondary path-name oam performance-monitoring querier] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Configure combined loss-delay measurement options. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Pro-Active Loss and Delay Measurements | 417 
On-Demand Packet Loss and Delay Measurement for UHP LSPs Overview | 388 
performance-monitoring (Protocols MPLS) | 1893 
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| Isp-attributes 


Syntax 


Isp-attributes { 
encoding-type (ethernet | packet | pdh | sonet-sdh); 
gpid (ethernet | hdlc | ipv4 | pos-scrambling-crc-16 | pos-no-scrambling-crc-16 | pos-scrambling-crc-32 | 
pos-no-scrambling-crc-32 | ppp); 
signal-bandwidth type; 
switching-type (fiber | lambda | psc-1 | tdm); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

pos-scrambling-crc-16, pos-no-scrambling-crc-16, pos-scrambling-crc-32, and pos-no-scrambling-crc-32 
options added in Junos OS Release 8.0. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Define the parameters signaled during LSP setup. These usually determine the nature of the resource 
(label) allocated for the LSP. 


The remaining statements are explained separately. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring MPLS LSPs for GMPLS | 1264 
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| Isping-channel-type 
Syntax 


Isping-channle-type { 
ipv4; 
on-demand-cv; 


Hierarchy Level 


[edit protocols mpls label-switched-path Isp-name oam mpls-tp-mode] 
[edit protocols mpls oam mpls-tp-mode] 


Release Information 
Statement introduced in Junos OS Release 16.1. 


Description 


Specify the control-channel types for MPLS-TP mode. By default, LSPING (Ox0008) is used, and the 
GACH-TLV is used along with this channel type. 


As per RFC 7026, GACH-TLV is deprecated for ipv4 and on-demand-cv channel types. 


Options 
ipv4—Channel type 0x0021. This channel type uses the IP/UDP encapsulation and provides interoperability 
support with other vendor devices using IP addressing. 


on-demand-cv—Channel type 0x0025. This is a new pseudowire channel type and is used for on-demand 
CV without IP/UDP encapsulation, where IP addressing is not available or non-IP encapsulation is 
preferred. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


mpls-tp-mode | 1854 


| I2vpn 


Syntax 


|2vpn { 


(control-word | no-control-word); 


encapsulation-type type; 


oam { 


bfd-liveness-detection { 


} 


detection-time { 
threshold milliseconds; 
} 
minimum-interval milliseconds; 
minimum-receive-interval milliseconds; 
multiplier number; 
no-adaptation; 
transmit-interval { 
threshold milliseconds; 
minimum-interval milliseconds; 
} 


version (1 | automatic); 


ping-interval seconds; 


} 


site site-name { 
community COMM; 
control-word ; 


encapsulation-type ethernet; 


ignore-encapsulation-mismatch; 


ignore-mtu-mismatch; 


interface interface-name { 


description text; 
community COMM; 
control-word ; 
encapsulation-type ethernet; 
ignore-encapsulation-mismatch; 
ignore-mtu-mismatch; 
mtu 1500; 
no-control-word; 
oam { 
bfd-liveness-detection { 
detection-time { 
threshold milliseconds; 
} 


minimum-interval milliseconds; 
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minimum-receive-interval milliseconds; 
multiplier number; 
no-adaptation; 
transmit-interval { 
threshold milliseconds; 
minimum-interval milliseconds; 
} 
version (1 | automatic); 
} 
ping-interval seconds; seconds; 
} 
remote-site-id remote-site-id; 
target-attachment-identifier identifier; 
} 
mtu 1500; 
no-control-word; 
oam { 
bfd-liveness-detection { 
detection-time { 
threshold milliseconds; 
} 
minimum-interval milliseconds; 
minimum-receive-interval milliseconds; 
multiplier number, 
no-adaptation; 
transmit-interval { 
threshold milliseconds; 
minimum-interval milliseconds; 
} 
version (1 | automatic); 
} 
ping-interval seconds; seconds; 
} 
site-identifier identifier; 
site-preference preference-value { 
backup; 
primary; 
} 
source-attachment-identifier identifier; 
} 
traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag <flag-modifier> <disable>; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols], 
[edit routing-instances routing-instance-name protocols] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 11.1 for EX Series switches. 


Description 


Enable a Layer 2 VPN routing instance on a PE router or switch. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring a Layer 2 VPN Routing Instance 
Configuring an MPLS-Based Layer 2 VPN (CLI Procedure) 
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| maximum-bandwidth (Protocols MPLS) 


Syntax 


maximum-bandwidth bps; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 


Specify the maximum amount of bandwidth in bits per second (bps). 


Options 


bps—Maximum amount of bandwidth. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth | 520 
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| maximum-helper-recovery-time 


Syntax 


maximum-helper-recovery-time seconds; 


Hierarchy Level 


[edit protocols rsvp graceful-restart], 
[edit logical-systems logical-system-name protocols rsvp graceful-restart] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Specify the length of time the router or switch retains the state of its Resource Reservation Protocol (RSVP) 
neighbors while they undergo a graceful restart. 


Options 
seconds—Legnth of time that the router retains the state of its Resource Reservation Protocol (RSVP) 
neighbors while they undergo a graceful restart. 

Range: 1 through 3600 

Default: 180 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Graceful Restart Options for RSVP, CCC, and TCC 
maximum-helper-restart-time (RSVP) | 1842 
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| maximum-helper-restart-time (RSVP) 


Syntax 


maximum-helper-restart-time seconds; 


Hierarchy Level 


[edit protocols rsvp graceful-restart], 
[edit logical-systems logical-system-name protocols rsvp graceful-restart] 


Release Information 
Statement introduced in Junos OS Release 8.3. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Specify the length of time the router or switch waits after it discovers that a neighboring router has gone 
down before it declares the neighbor down. This value is applied to all RSVP neighbor routers and should 
be based on the time that the slowest RSVP neighbor requires for restart. 


Options 
seconds—The time the router or switch waits after it discovers that a neighboring router has gone down 
before it declares the neighbor down. 

Range: 1 through 1800 

Default: 60 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Graceful Restart Options for RSVP, CCC, and TCC 


maximum-helper-recovery-time | 1841 
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| maximum-labels 


Syntax 


maximum-labels maximum-labels; 


Hierarchy Level 


[edit interfaces interface-name unit logical-unit-number family mpls], 
[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family mpls] 


Release Information 
Statement introduced in Junos OS Release 10.1. 
Statement introduced in Junos OS Release 17.2R1 for QFX10000 switches. 


Description 


On the logical interface, specify the maximum number of MPLS labels upon which MPLS can operate. 


Options 


maximum-labels—Maximum number of labels for the protocol family. 


NOTE: On PTX Series routers with third-generation FPCs, the maximum labels that can be 
pushed cannot exceed 8 labels. 


Range: 3 through 16 
Default: 3 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Maximum Number of MPLS Labels | 462 
Junos OS VPNs Library for Routing Devices 
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| minimum-bandwidth-adjust-interval 


Syntax 


minimum-bandwidth-adjust-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


Release Information 
Statement introduced in Junos OS Release 12.2. 
Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 


Specify the duration (in seconds) for which minimum bandwidth is frozen. 


Options 
seconds—Minimum bandwidth reallocation interval, in seconds. 
Range: 300 through 31,536,000 seconds. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth | 520 
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| minimum-bandwidth-adjust-threshold-change 


Syntax 


minimum-bandwidth-adjust-threshold-change percentage; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


Release Information 
Statement introduced in Junos OS Release 12.2. 
Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 


Specify the percentage change in maximum average bandwidth to freeze the minimum bandwidth. 


Options 
percentage—Percentage change in maximum average bandwidth. 


Range: Range: O through 100 percent. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth | 520 


1846 


| minimum-bandwidth-adjust-threshold-value 


Syntax 


minimum-bandwidth-adjust-threshold-value bps; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


Release Information 
Statement introduced in Junos OS Release 12.2. 
Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 
Specify the value in bits per second (bps) to freeze the minimum bandwidth if the maximum average 
bandwidth falls below this value. 


Options 
bps—Threshold value for minimum bandwidth if the maximum average bandwidth falls below the specified 
value. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth | 520 
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| metric (Protocols MPLS) 


Syntax 


metric metric; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 
[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls static-label-switched-path Isp-name ingress] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


Description 

Compare against another LSP or against an IGP route. To disable dynamic metric tracking, assign a fixed 
metric value to an LSP. If no metric is assigned, the LSP metric is dynamic and automatically tracks underlying 
IGP metrics. 


Options 

metric—LSP metric value. 
Default: No metric assigned (dynamic) 
Range: 1 through 16,777,215 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Static LSP Metrics | 498 
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| minimum-bandwidth 


Syntax 


minimum-bandwidth bps; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 


Set the minimum bandwidth in bps for an LSP with automatic bandwidth allocation enabled. 


NOTE: For a label-swtiched path (LSP) that has both bandwidth and minimum-bandwidth for 
autobandwidth configured under the [edit protocols mpls label-switched-path Isp-name] hierarchy 
level, the LSP bandwidth is adjusted differently. 


The LSP is initiated with the bandwidth value configured under the bandwidth statement at the 
[edit protocols mpls label-switched-path Isp-name] hierarchy level. At the expiry of the 
adjust-interval timer, the LSP bandwidth gets adjusted based on the traffic flow. 


If the bandwidth to be signaled is less than the value configured under the minimum-bandwidth 
statement at the [edit protocols mpls label-switched-path Isp-name autobandwidth] hierarchy 
level, then the LSP is signaled only using the minimum bandwidth. 


If the bandwidth to be signaled is greater than the value configured under the 
maximum-bandwidth statement at the [edit protocols mpls label-switched-path Isp-name 
autobandwidth] hierarchy level, then the LSP is signaled only using the maximum bandwidth. 


Options 
bps—Miniminum bandwidth for the LSP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


| Configuring the Maximum and Minimum Bounds of the LSP’s Bandwidth | 520 


monitor-bandwidth 


Syntax 


monitor-bandwidth; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 
Do not automatically adjust bandwidth allocation. However, the maximum average bandwidth utilization 
is monitored on the LSP, and the information is recorded in the MPLS statistics file. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| Configuring Passive Bandwidth Utilization Monitoring | 523 


most-fill 


See 
random 
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| mpls (Protocols) 


Syntax 


mpls { ... } 


Hierarchy Level 


[edit logical-systems logical-system-name protocols], 
[edit protocols] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 
Enable MPLS on the router. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring MPLS | 39 
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| mpls 


Syntax 


mpls { 
disable; 
class-of-service cos-value; 
no-cspf,; 
no-decrement-ttl; 


advertisement-hold-time seconds; 
explicit-null; 
icmp-tunneling; 
interface (interface-name | all) { 
disable; 
} 
ipv6-tunneling; 
no-propagate-ttl; 
path path-name { 
(address | hostname) <loose | strict>; 
} 
label-switched-path Isp-name { 
disable; 
auto-bandwidth { 
adjust-interval seconds; 
adjust-threshold percentage; 
adjust-threshold-overflow-limit count; 
adjust-threshold-underflow-limit 
maximum-bandwidth bps; 
minimum-bandwidth bps; 
monitor-bandwidth; 
} 
description text-string; 
from address; 
install destination-prefix</prefix-length> <active>; 
Idp-tunneling; 
no-cspf; 
no-decrement-ttl; 
primary path-name { 
adaptive; 
select (manual | unconditional); 
} 
secondary path-name { 
adaptive; 
select (manual | unconditional); 


} 

to address; 

traceoptions { 
file filename <files number> <size maximum-file-size> <world-readable | no-world-readable>; 
flag flag; 


} 
static-label-switched-path Isp-name { 
bypass bypass-name { 
description text-string; 
next-hop (address | interface-name | address/interface-name), 
to address; 
} 
ingress { 
description string; 
install { 
destination-prefix <active>; 
} 
link-protection bypass-name name; 
next-hop (address | interface-name | address/interface-name); 
to address; 
} 
transit incoming-label { 
bandwidth bps; 
description text-string; 
link-protection bypass-name name; 
next-hop (address | interface-name | address/interface-name); 
pop, 
swap out-label; 
} 
statistics { 
auto-bandwidth; 
file filename <files number> <size maximum-file-size> <world-readable | no-world-readable>; 
interval seconds; 
} 
traceoptions { 
file filename <files number> <size maximum-file-size> <world-readable | no-world-readable>; 
flag flag; 
} 
traffic-engineering (bgp | bgp-igp); 
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Hierarchy Level 


[edit protocols] 


Release Information 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 
Statement introduced in Release 19.4R1 for cRPD. 


Description 
Enable MPLS on the switch. 


The remaining statements are explained separately. 


Default 
MPLS is disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring MPLS on EX8200 and EX4500 Switches | 42 

Configuring CoS on an MPLS Provider Edge Switch Using IP Over MPLS | 1225 
Configuring CoS on an MPLS Provider Edge Switch Using Circuit Cross-Connect | 1228 
Configuring MPLS on EX8200 and EX4500 Provider Switches | 78 

Junos OS MPLS Applications Configuration Guide 
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| mpls-tp-mode 
Syntax 


mpls-tp-mode; 
Isping-channel-type; 


Hierarchy Level 


[edit protocols mpls label-switched-path Isp-name oam], 
[edit protocols mpls oam] 


Release Information 
Statement introduced in Junos OS Release 12.1. 
Isping-channel-type statement introduced in Junos OS Release 16.1. 


Description 
Enable GAL or G-Ach OAM operation without IP encapsulation on a label-switched path (LSP). 


Include this statement at the [edit protocols mpls oam] hierarchy level to enable GAL or G-Ach OAM 
operation without IP encapsulation on all LSPs in the MPLS network. Include this statement at the [edit 
protocols mpls label-switched-path Isp-name oam] hierarchy level to enable GAL and G-Ach OAM operation 
without IP encapsulation on a specific LSP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring the MPLS Transport Profile for OAM | 1132 
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| mtu-signaling 
Syntax 


mtu-signaling; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls path-mtu rsvp], 
[edit protocols mpls path-mtu rsvp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Enable MTU signaling in RSVP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Enabling MTU Signaling in RSVP | 810 
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| neighbor (Protocols Layer 2 Circuit) 


Syntax 


neighbor address { 
interface interface-name { 
backup-neighbor address { 
community name; 
hot-standby; 
psn-tunnel-endpoint address; 
standby; 
virtual-circuit-id number; 
} 
bandwidth (bandwidth | ctnumber bandwidth); 
community community-name; 
(control-word | no-control-word); 
description text; 
egress-protection { 
protected-I|2circuit { 
egress-pe address; 
ingress-pe address; 
virtual-circuit-id identifier; 
} 
protector-interface interface-name; 
protector-pe address { 
context-identifier identifier; 
Isp Isp-name; 


} 


} 
encapsulation-type type; 
ignore-encapsulation-mismatch; 
ignore-mtu-mismatch; 
mtu mtu-number; 
no-revert; 
protect-interface interface-name; 
pseudowire-status-tlv hot-standby-vc-on; 
psn-tunnel-endpoint address; 
revert-time seconds; 
static { 
incoming-label label; 
outgoing-label label; 
send-oam; 
} 


switchover-delay milliseconds; 


virtual-circuit-id identifier; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols |2circuit], 
[edit protocols |2circuit] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 11.1 for EX Series switches. 


Description 

Each Layer 2 circuit is represented by the logical interface connecting the local provider edge (PE) router 
or switch to the local customer edge (CE) router or switch. All the Layer 2 circuits using a particular remote 
PE router or switch designated for remote CE routers or switches are listed under the neighbor statement 
(neighbor designates the PE router or switch). Each neighbor is identified by its IP address and is usually 

the end-point destination for the LSP tunnel (transporting the Layer 2 circuit). 


Options 


address—IP address of a neighboring router or switch. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Neighbor Interface for the Layer 2 Circuit 
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| next-hop (Protocols MPLS) 


Syntax 


next-hop (address | interface-name | address/interface-name), 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name bypass], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name transit incoming-label], 
[edit protocols mpls static-label-switched-path Isp-name bypass], 

[edit protocols mpls static-label-switched-path Isp-name ingress], 

[edit protocols mpls static-label-switched-path Isp-name transit incoming-label] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Support for IPv6 addresses in static LSP configurations added in Junos OS Release 17.2R1. 
Support for IPv4 or IPv6 lookup after poping the label added in Junos OS Release 17.4R1. 


Description 

Location of the next hop to the destination, specified as the IPv4 or IPv6é address of the next hop, the 
interface name (for point-to-point interfaces only), or the address/interface-name to specify an IP address 
on an operational interface. 


Options 


address—|Pv4 or IPv6 address of the next-hop router. 


NOTE: IPv6 static LSPs are not supported at the [edit protocols mpls static-label-switched-path 
Isp-name ingress] hierarchy level. 


interface-name—IP address of the outgoing interface. It must be a point-to-point interface. The name can 
be a simple or fully qualified domain name. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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| Configuring the Ingress Router for Static LSPs | 575 


| no-bfd-triggered-local-repair 
Syntax 


no-bfd-triggered-local-repair; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options], 
[edit routing-options] 


Release Information 
Statement introduced in Junos OS Release 12.2. 
Statement introduced in Junos OS Release 12.3 for ACX Series routers. 


Description 


Disable Bidirectional Forwarding Detection (BFD) sessions to trigger fast reroute (FRR) using MPLS-FRR 
and loop-free alternates (LFAs). When this statement is configured, no BFD-triggered local repair is 
supported. However, logical interface down-based local repair is in force. 


When using this statement to disable local repair, you also must restart routing to ensure proper behavior. 
To restart routing, include the graceful-restart command for the interior gateway protocol (IGP) used in 
your configuration. For example, if your IGP is OSPF, include the graceful-restart statement at the [edit 
protocols ospf] hierarchy level. 


Default 


BFD-triggered local repair is the default behavior. The loss of a neighbor results in BFD local repair for all 
next hops that derive themselves from the base next hop with which the BFD session is established. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


BFD-Triggered Local Repair for Rapid Convergence | 141 
graceful-restart (Enabling Globally) | 1864 
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| no-cspf 
Syntax 


no-cspf; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mplslabel-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Disable constrained-path LSP computation. 


An explicit-path LSP is completely configured through operator action. Once configured, it is initiated only 
along the explicitly specified path. 


A constrained-path LSP relies on an ingress router to compute the complete path. The ingress router takes 
into account the following information during the computation: 


e Interior gateway protocol (IGP) topology database 
e Link utilization information from extensions in the IGP link-state database 
e Administrative group information from extensions in the IGP link-state database 


e LSP requirements, including bandwidth, hop count, and administrative group 


Constrained-path LSPs can generally avoid link failures and congested links. They also permit recomputation 
(therefore, a new path) during topology changes or unsuccessful setup. 


Default 


Constrained-path LSP computation enabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Disabling Constrained-Path LSP Computation | 483 
Configuring Explicit-Path LSPs | 564 
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| no-decrement-ttl 


Syntax 


no-decrement-ttl; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 12.3X50 on the QFX Series. 
Statement introduced in Junos OS Evolved Release 19.3R1 on PTX10003. 
Statement introduced in Junos OS Evolved Release 20.1R1 on PTX10008. 


Description 

Disable normal time-to-live (TTL) decrementing, which decrements the TTL field in the IP header by 1. 
This statement decrements the IP TTL by 1 before encapsulating the IP packet within an MPLS packet. 
When the penultimate router pops off the top label, it does not use the standard write-back procedure of 
writing the MPLS TTL into the IP TTL field. Therefore, the IP packet is decremented by 1. The ultimate 
router then decrements the packet by one more for a total cloud appearance of 2, thus hiding the network 
topology. 


Default 


Normal TTL decrementing enabled; the TTL field value is decremented by 1 as the packet passes through 
each label-switched router in the LSP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Disabling Normal TTL Decrementing 
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no-propagate-ttl | 1870 
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| graceful-restart (Enabling Globally) 


Syntax 


graceful-restart { 
disable; 
helper-disable; 
maximum-helper-recovery-time seconds; 
maximum-helper-restart-time seconds; 
notify-duration seconds; 
recovery-time seconds; 
restart-duration seconds; 
stale-routes-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options], 
[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options], 
[edit routing-options], 


[edit routing-instances routing-instance-name routing-options] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 
Statement introduced in Junos OS Release 12.1 for the QFX Series. 
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 

You configure the graceful restart routing option globally to enable the feature, but not to enable graceful 
restart for all routing protocols in a routing instance. To enable graceful restart globally, include the 
graceful-restart statement under the [edit routing options] hierarchy level. This enables graceful restart 
globally for all routing protocols. You can, optionally, modify the global settings at the individual protocol 
level. 
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NOTE: 
e For VPNs, the graceful-restart statement allows a router whose VPN control plane is undergoing 
a restart to continue to forward traffic while recovering its state from neighboring routers. 


e For BGP, if you configure graceful restart after a BGP session has been established, the BGP 
session restarts and the peers negotiate graceful restart capabilities. 


e LDP sessions flap when graceful-restart configurations change. 


Default 
Graceful restart is disabled by default. 


Options 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Enabling Graceful Restart 

Configuring Routing Protocols Graceful Restart 
Configuring Graceful Restart for MPLS-Related Protocols 
Configuring VPN Graceful Restart 

Configuring Logical System Graceful Restart 

Configuring Graceful Restart for QFabric Systems 
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| helper-disable (Multiple Protocols) 


Syntax 


helper-disable; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (isis | Idp | ospf | ospf3 | rsvp) graceful-restart], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (Idp | ospf | ospf3) 
graceful-restart], 

[edit protocols (isis | Idp | ospf | ospf3 | rsvp) graceful-restart], 

[edit routing-instances routing-instance-name protocols (Idp | ospf | ospf3) graceful-restart] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Disable helper mode for graceful restart. When helper mode is disabled, a router or switch cannot help a 
neighboring router that is attempting to restart. 


Default 
Helper mode is enabled by default for these supported protocols: IS-I1S, LDP, OSPF/OSPFv3, and RSVP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Routing Protocols Graceful Restart 


Configuring Graceful Restart for MPLS-Related Protocols 
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| no-install-to-address 


Syntax 


no-install-to-address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 
[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls static-label-switched-path Isp-name ingress] 


Release Information 
Statement introduced in Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Prevent the egress router address configured using the to statement from being installed into the inet.3 
and inet.O routing tables. 


Default 


The egress router address for an LSP is installed into the inet.3 and inet.O routing tables. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Preventing the Addition of Egress Router Addresses to Routing Tables | 486 
to | 1973 
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no-load-balance-label-capability 


Syntax 


no-load-balance-label-capability; 


Hierarchy Level 


[edit forwarding-options] 


Release Information 
Statement introduced in Junos OS Release 14.1. 


Description 


Disables advertisement of entropy label capability in LDP and RSVP. 


When you configure the no-load-balance-label-capability statement, it also disables the flow-aware 
transport of pseudowires (FAT) flow label for FEC 128. 


The load-balance-label-capability and no-load-balance-label-capability statements at the [edit 
forwarding-options] hierarchy level are mutually exclusive, and at a given point in time, configuring one 
statement overrides the other. 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


load-balance-label-capability | 1828 
entropy-label | 1766 
Configuring the Entropy Label for LSPs | 534 
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no-mcast-replication 
Syntax 


no-mcast-replication; 


Hierarchy Level 


[edit chassis fpc slot-number pic pic-number], 
[edit chassis Icc number fpc slot-number pic pic-number] 


Release Information 
Statement introduced in Junos OS Release 11.3. 


Description 

For point-to-multipoint LSPs configured on T Series routers, protect the Packet Forwarding Engine (PFE) 
from bandwidth saturation. When a PFE does not need to replicate traffic, the PFE’s bandwidth is less 
likely to become saturated. When you include the no-mcast-replication statement, the PFE is forced to 
be a leaf node in the binary tree. Leaf nodes, unlike branch nodes, do not replicate traffic in the process 
of forwarding traffic. Because leaf nodes have no children, they do not need to replicate traffic, and thus 
are less likely to become saturated with traffic. 


Default 


If you omit the no-mcast-replication statement, the PFE can become a branch node or a leaf node. When 
the PFE becomes a branch node, the PFE must replicate traffic. 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Point-to-Multipoint LSPs Overview | 657 
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no-propagate-ttl 
Syntax 


no-propagate-ttl; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 12.3X50 on the QFX Series. 
Statement introduced in Junos OS Evolved Release 20.1R1 on PTX10008. 


Description 

Disable normal time-to-live (TTL) decrementing. You configure this statement once per router, and it 
affects all RSVP-signaled or LDP-signaled LSPs. When this router acts as an ingress router for an LSP, it 
pushes an MPLS header with a TTL value of 255, regardless of the IP packet TTL. When the router acts 
as the penultimate router, it pops the MPLS header without writing the MPLS TTL into the IP packet. 


When you add the no-propagate-ttl statement to the configuration or delete it from the configuration, 
the effect takes place immediately. There is no need to clear existing RSVP LSPs or LDP sessions. 


Default 


Normal TTL decrementing enabled; the TTL field value is decremented by 1 as the packet passes through 
each label-switched router in the LSP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Disabling Normal TTL Decrementing 


Example: Diagnosing Networking Problems Related to Layer 3 VPNs by Disabling TTL Decrementing (on 
Layer 3 VPNs User Guide for Routing Devices or in the Junos VPNs Configuration Guide) 


no-decrement-ttl | 1862 
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| no-transit-statistics 


Syntax 


no-transit-statistics; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls statistics], 
[edit protocols mpls statistics] 


Release Information 
Statement introduced in Junos OS Release 10.2 for PTX Series. 


Description 
(PTX Series only) Disables the collection of MPLS statistics for LSPs transiting the router. 


Required Privilege Level 
routing and trace—To view this statement in the configuration. 
routing-control and trace-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring MPLS to Gather Statistics | 387 
statistics | 1964 


1872 


no-trap 
Syntax 


no-trap { 
mpls-Isp-traps; 
rfc-3812-traps; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls log-updown], 
[edit protocols mpls log-updown] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

The mpls-Isp-traps and rfc-3812-traps options added in Junos OS Release 9.0. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Prevent the transmission of SNMP traps. 


Options 
mpls-Isp-traps—Block the MPLS LSP traps defined in therfc-3812-traps, but allows the rfc3812.mib traps. 


rfc-3812-traps—Block the traps defined in the rfc3812.mib, but allows the MPLS LSP traps defined in the 
jnx-mpls.mib. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


System Log Messages and SNMP Traps for MPLS | 160 
Network Management and Monitoring Guide 


traceoptions (Protocols MPLS) | 1974 
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| node-protection (Static LSP) 


Syntax 


node-protection bypass-name name next-next-label label; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name transit incoming-label], 
[edit protocols mpls static-label-switched-path Isp-name ingress], 

[edit protocols mpls static-label-switched-path Isp-name transit incoming-label] 


Release Information 
Statement introduced in JUNOS Release 10.1. 


Description 

Enable node protection on the specified static bypass LSP. Node protection ensures that traffic from an 
LSP traversing a neighboring router can continue to reach its destination even if the neighboring router 
fails. 


Default 


Node protection is disabled. 


Options 


bypass-name name—Bypass LSP name. 


next-next-label label—Bypass LSP name. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Static LSPs | 574 
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| normalization 


Syntax 


normalization { 
failover-normalization; 
no-incremental-normalize; 
normalization-retry-duration seconds; 
normalization-retry-limits number; 
normalize-interval seconds; 


Hierarchy Level 


[edit protocols mpls container-label-switched-path Isp-name splitting-merging] 


Release Information 
Statement introduced in Junos OS Release 14.2. 
Statement introduced in Junos OS Release 17.2R1 for QFX Series switches. 


Description 


Perform normailzation. 


Options 

failover-normalization—Enable the ingress router to pro-actively normalize or re-distribute traffic when 
a link or node failure happens on a member LSP. A member LSP can go down between two scheduled 
normalization events because of a link-failure or pre-emption. 
Default: Disabled 


no-incremental-normalize—Disables automatic switchover by the ingress router to a new instance of the 
container LSP until the desired demand is satisfied, although the given number of LSPs can be 
successfully signaled such that the new aggregate bandwidth value exceeds the old aggregate bandwidth 
value. 


Default: False (disabled) 


normalization-retry-duration seconds—Specifies the duration before which the ingress router performs a 
normalization reattempt when the previous normalization has not been successful. Normalization is 
done until a sufficient number of LSPs come up with an aggregate bandwidth that is more than the 
current aggregate or desired bandwidth. 


Default: 30 seconds 
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normalization-retry-limits number—Specifies the maximum number of times the ingress router performs 
normalization reattempts until a sufficient number of LSPs come up successfully with new bandwidth 
values. 


Default: 1 


normalize-interval seconds—Specifies the duration between two normalization events. 
Range: 21600 seconds through 6 hours 
Default: 21600 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


splitting-merging | 1953 


oam (Protocols MPLS) 


Syntax 


oam { 


bfd-liveness-detection{ 


} 


failure-action teardown; 
minimum-interval milliseconds; 
minimum-receive-interval milliseconds; 
minimum-transmit-interval milliseconds; 
multiplier detection-time-multiplier; 


Isp-ping-interval seconds; 


mpls-tp-mode; 


performance-monitoring { 


querier { 
loss { 
traffic-class tc-value { 


query-interval milliseconds; 
measurement-quantity bytes|packets; 
average-sample-size sample size; 
loss-threshold loss threshold value; 


loss-threshold-window number of samples for loss threshold; 


delay { 
traffic-class tc-value { 


query-interval milliseconds; 

padding-size size; 

average-sample-size sample size; 
rtt-delay-threshold rtt threshold value; 
twcd-delay-threshold twcd threshold value; 


loss-delay { 
traffic-class tc-value { 


query-interval milliseconds; 

measurement-quantity bytes|packets; 

padding-size size; 

average-sample-size sample size; 

loss-threshold loss threshold value; 

loss-threshold-window number of samples for loss threshold; 
rtt-delay-threshold rtt threshold value; 
twcd-delay-threshold twcd threshold value; 
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} 
responder { 
loss { 
min-query-interval milliseconds; 


} 
delay { 
min-query-interval milliseconds; 


Hierarchy Level 


[edit protocols mpls], 
[edit protocols mpls label-switched-path Isp-name] 
[edit protocols mpls label-switched-path Isp-name primary path-name] 


Release Information 

Statement introduced in Junos OS Release 7.6. 

Isp-ping-interval option introduced in Junos OS Release 9.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


performance-monitoring configuration statement introduced in Junos OS Release 15.1. 


Description 
Enable Operation, Administration, and Maintenance (OAM) for RSVP-signaled LSPs. 


Options 
Isp-ping-interval seconds—Specify the duration of the LSP ping interval in seconds. To issue a ping on an 
RSVP-signaled LSP, use the ping mpls rsvp command. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Configuring BFD for MPLS IPv4 LSPs | 143 
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| optimize-adaptive-teardown 
Syntax 


optimize-adaptive-teardown { 
p2p: 
delay value (3..65535 seconds) 


Hierarchy Level 


[edit protocols mpls] 


Release Information 
Statement introduced in Junos OS Release 15.1R1. 


Description 

Make use of a new feedback mechanism from TAG library which relies on RPD infrastructure to decide 
when all the routes using the old LSP instance have fully shifted to the new LSP instance after MBB 
switchover. When this statement is configured, the optimize-hold-dead-delay statement, which delays 
the teardown of the old LSP instance after MBB switchover, is ignored. 


Options 
p2p—Only point-to-point LSPs configured in the system will be affected. 


delay—Delays the tearing down of old optimized LSP paths based on the configured value. 
Range: from 3 through 65535 seconds 
Default: 600 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Optimizing Signaled LSPs | 511 
Achieving a Make-Before-Break, Hitless Switchover for LSPs | 508 
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optimize-aggressive 
Syntax 


optimize-aggressive; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

If enabled, the LSP reoptimization is based solely on the IGP metric. The reoptimization process ignores 
the available bandwidth ratio calculations, the least-fill 10 percent congestion improvement rule, and the 
hop-counts rule. This statement makes reoptimization more aggressive than the default. 


Default 


Aggressive optimization is disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Optimizing Signaled LSPs | 511 
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| optimize-hold-dead-delay 
Syntax 


optimize-hold-dead-delay seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switch-path Isp-name], 
[edit protocols mpls], 

[edit protocols mpls label-switch-path Isp-name] 


Description 


Allows you to specify the amount of time to delay the tear down of old paths after the router has switched 
traffic to new optimized paths. This delay timer starts when the timer specified by the 
optimize-switchover-delay statement has elapsed, which is typically 30 seconds, and at the start of the 
next retry sequence (in other words, the delay is not an absolute countdown of the seconds configured 
here). 


You only need to configure this statement on routers acting as the ingress for the affected LSPs (you do 
not need to configure this statement on transit or egress routers). The specified delay helps to ensure that 
old paths are not torn down before all routes have been switched over to the new optimized paths. 


Options 
seconds—Configure the time in seconds to wait before tearing down the old paths that were in use prior 
to the last LSP optimization. 


Default: 60 to 90 seconds 
Range: O through 65,535 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Optimizing Signaled LSPs | 511 
optimize-switchover-delay | 1882 


optimize-timer | 1883 
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optimize-switchover-delay 
Syntax 


optimize-switchover-delay seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 
Statement introduced in Junos OS Release 11.1R1. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Delays the switch over of LSPs to newly optimized paths. You only need to configure this statement on 
routers acting as the ingress for the affected LSPs (you do not need to configure this statement on transit 
or egress routers). The specified delay helps to ensure that the new optimized paths have been established 
before traffic is switched over from the old paths. 


Options 
seconds—Configure the time in seconds to wait before switching LSPs to newly optimized paths. 
Default: 1 second 


Range: 1 through 900 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Optimizing Signaled LSPs | 511 
optimize-hold-dead-delay | 1881 
optimize-timer | 1883 


1883 


| optimize-timer (Protocols MPLS) 


Syntax 


optimize-timer seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


Description 

Enable periodic reoptimization of an LSP that is already set up. If topology changes occur, an existing path 
might become suboptimal, and a subsequent recomputation might be able to determine a better path. This 
feature is useful only on LSPs for which constrained-path computation is enabled; that is, for which the 
no-cspf statement is not configured. Also, you only need to configure this statement on routers acting as 
the ingress for the affected LSPs (you do not need to configure this statement on transit or egress routers). 


To avoid extensive resource consumption that might result because of frequent path recomputations, or 
to avoid destabilizing the network as a result of constantly changing LSPs, we recommend that you either 
leave the timer value sufficiently large or disable the timer value. 


Default 


The optimize timer is disabled. 


Options 
seconds—Length of the optimize timer, in seconds. 
Range: O through 65,535 seconds 


Default: 0 seconds (the optimize timer is disabled) 


Required Privilege Level 
routing—To view this statement in the configuration. 
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routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Optimizing Signaled LSPs | 511 
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| p2mp (Protocols MPLS) 


Syntax 


p2mp p2mp-lsp-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


Description 


Specify an LSP as either a point-to-multipoint LSP or as a branch LSP of a point-to-multipoint LSP by 
specifying the point-to-multipoint LSP path name. 


Options 

p2mp-Isp-name—Name of the point-to-multipoint LSP path that identifies the sequence of nodes that form 
the point-to-multipoint LSP. The name can contain up to 32 characters and can include letters, digits, 
periods, and hyphens. To include other characters or use a longer name, enclose the name in quotation 
marks. The name must be unique within the ingress router. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Primary Point-to-Multipoint LSP | 687 
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| p2mp-lsp-next-hop 
Syntax 


p2mp-lsp-next-hop { 
metric metric; 
preference preference; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options static route 
destination-prefix], 

[edit logical-systems logical-system-name routing-options static route destination-prefix], 

[edit routing-instances routing-instance-name routing-options static route destination-prefix]. 

[edit routing-options static route destination-prefix] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3 for ACX Series routers. 


Description 
Specify a point-to-multipoint LSP as the next hop for a static route, and configure an independent metric 
or preference on that next-hop LSP. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Static Unicast Routes for Point-to-Multipoint LSPs | 582 
Example: Configuring a Collection of Paths to Create an RSVP-Signaled Point-to-Multipoint LSP | 661 
Example: Configuring an RSVP-Signaled Point-to-Multipoint LSP on Logical Systems 
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| path (Protocols MPLS) 


Syntax 


path path-name { 
abstract-hop-name (abstract | loose | loose-link | strict); 
(address | hostname) <strict | loose>; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for the QFX Series Virtual Chassis and Virtual 
Chassis Fabric. 


abstract-hop-name option introduced in Junos OS Release 17.1 for all platforms. 


Description 


Create a named path and optionally specify the sequence of explicit routers that form the path. 


You must include this statement when configuring explicit LSPs. 


Options 

abstract-hop-name—Name of the predefined abstract hop. The abstract hop can be used in combination 
with real IP next hops. An abstract hop is traversed by traversing the member nodes. This traversal can 
be done by either links that satisfy the logical combination of defined constituent attributes, or by any 
kind of link. This choice is controlled by the use of abstract hop qualifiers - abstract, loose, loose-link, and 
Strict. 


abstract—Indicate that the next hop configured in the path statement is an abstract hop.. 


loose-link—Indicate that the next hop in the path statement is a loose-link abstract hop. This means that 
the LSP cannot traverse other routers before reaching this router. In other words, the abstract hop of type 
loose-link is processed only if any of the viable routers is reached in constraint through a link of associated 
abstract hop membership. 


loose—Indicate that the next hop in the path statement is a loose abstract hop. The path can traverse any 
real nodes that do not have abstract hop membership, before reaching a node with abstract hop membership, 
which is a feasible starting point for processing the next abstract hop. 
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strict—Indicate that the next hop in the path statement is a strict abstract hop. After the last processed 
hop in the constraint list, the path can traverse any real nodes that do not have abstract hop membership, 
before reaching a node with abstract hop membership, which is a feasible starting point for processing 
the next abstract hop. 


address—|P address of each transit router in the LSP. You must specify the address or hostname of each 
transit router, although you do not need to list each transit router if its type is loose. As an option, you 
can include the ingress and egress routers in the path. Specify the addresses in order, starting with the 
ingress router (optional) or the first transit router, and continuing sequentially along the path until reaching 
the egress router (optional) or the router immediately before the egress router. 


Default: If you do not specify any routers explicitly, no routing limitations are imposed on the LSP. 


hostname—See address. 


Default: If you do not specify any routers explicitly, no routing limitations are imposed on the LSP. 


loose—(Optional) Indicate that the next address in the path statement is a loose link. This means that the 
LSP can traverse through other routers before reaching this router. 


Default: strict 


path-name—Name that identifies the sequence of nodes that form an LSP. The name can contain up to 
32 characters and can include letters, digits, periods, and hyphens. To include other characters or use a 
longer name, enclose the name in quotation marks. The name must be unique within the ingress router. 


strict—(Optional) Indicate that the LSP must go to the next address specified in the path statement without 
traversing other nodes. This is the default. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Creating Named Paths | 488 
abstract-hop | 1696 


| path 


Syntax 


path destination { 
<address | hostname> <strict | loose> 


Hierarchy Level 


[edit protocols mpls] 


Release Information 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Configure path protection on your MPLS network. 


Options 
destination —Name of a label switched path (LSP). In addition to specifying the name of the configured 
LSP, you can include some other designation such as primary-path. 


address —(Optional) IP address of each transit switch (or the IP address of the loopback interface on the 
switch) in the LSP. If you want to control exactly which switches are selected for the LSP, specify the 
address or hostname of each transit switch. Specify the addresses in order, starting with the first provider 
(transit) switch, and continuing sequentially along the path until reaching the egress provider edge switch. 


Default: If you do not specify the addresses or hostnames of any switches, the LSP is calculated by the switch. 


hostname —(Optional) See address . 


Default: If you do not specify the addresses or hostnames of any switches, the LSP is calculated by the switch. 


loose—(Optional) Indicates that the next address in the path statement is a loose link. This means that the 
LSP can traverse through other switches before reaching this switch. 


Default: strict 


strict—(Optional) Indicates that the LSP must go to the next address specified in the path statement without 
traversing other switches. This is the default. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


| Configuring Path Protection in an MPLS Network (CLI Procedure) | 280 


path-mtu 


Syntax 


path-mtu { 
allow-fragmentation; 
rsvp { 
mtu-signaling; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Configure MTU options for MPLS paths, including packet fragmentation and MTU signaling. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring MTU Signaling in RSVP | 809 
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| per-prefix-label 
Syntax 


per-prefix-label; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols bgp family inet labeled-unicast], 

[edit logical-systems logical-system-name protocols bgp group group-name family inet labeled-unicast], 

[edit protocols bgp family inet labeled-unicast], 

[edit protocols bgp group group-name family inet labeled-unicast], 

[edit routing-instances instance-name logical-systems logical-system-name protocols bgp family inet labeled-unicast], 

[edit routing-instances instance-name logical-systems logical-system-name protocols bgp group group-name family 
inet labeled-unicast], 

[edit routing-instances instance-name protocols bgp family inet labeled-unicast], 

[edit routing-instances instance-name protocols bgp group group-name family inet labeled-unicast] 


Release Information 
Statement introduced in Junos OS Release 12.1x48 for PTX Series Packet Transport Routers. 
Statement introduced in Junos OS Release 12.3 for M Series, T Series, and MX Series routers. 


Description 
Allocate a unique label for each prefix. The per-prefix-label statement helps minimize packet loss in most 
deployments. 


Although allocating a label for each prefix is not generally ideal for scaling, it is assumed that a small number 
of labels are used for BGP labeled-unicast. When labeled BGP is used to set up transport label-switched 
paths (LSPs), the common case is that each prefix has a unique next hop. Thus, the use of per-prefix labels 
does not have an adverse scaling impact. On the contrary, the use of per-prefix labels reduces churn in 
the network when multipath load balancing is enabled for IPv4 labeled-unicast, and a subset of the paths 
are withdrawn for some reason. 


The advantage of per-prefix labeling is that the advertised upstream label is more stable during network 
changes. That is, if the downstream label changes, the advertised upstream label remains the same under 
most scenarios. This way, the upstream router is isolated from the downstream network change, and the 
overall network is more stable. The greater stability of the advertised upstream label helps to reduce traffic 
loss during many different network change scenarios. 


Default 


By default, label allocation is per next-hop router. 


Required Privilege Level 
routing—To view this statement in the configuration. 
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routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


MPLS Label Allocation | 422 


1893 


| performance-monitoring (Protocols MPLS) 


Syntax 


performance-monitoring { 
querier { 
delay { 
traffic-class tc-value { 
average-sample-size sample size; 
padding-size size; 
query-interval milliseconds; 
rtt-delay-threshold rtt threshold value; 
twcd-delay-threshold twcd threshold value; 


} 
loss { 
traffic-class tc-value { 

average-sample-size sample size; 
loss-threshold loss threshold value; 
loss-threshold-window number of samples for loss threshold; 
measurement-quantity bytes|packets; 
query-interval milliseconds; 


} 
loss-delay { 
traffic-class tc-value { 

average-sample-size sample size; 
loss-threshold loss threshold value; 
loss-threshold-window number of samples for loss threshold; 
measurement-quantity bytes|packets; 
padding-size size; 
query-interval milliseconds; 
rtt-delay-threshold rtt threshold value; 
twcd-delay-threshold twcd threshold value; 


} 
responder { 
delay { 
min-query-interval milliseconds; 
} 
loss { 
min-query-interval milliseconds; 


Hierarchy Level 


[edit protocols mpls oam], 

[edit protocols mpls label-switched-path Isp-name oam], 

[edit protocols mpls label-switched-path Isp-name primary path-name oam], 
[edit protocols mpls label-switched-path Isp-name secondary path-name oam] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Configure performance monitoring options. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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| policing (Protocols MPLS) 


Syntax 


policing { 
filter filter-name; 
no-auto-policing; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 
[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls static-label-switched-path Isp-name ingress] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify the policing filter for the LSP. 


Options 


filter filter-name—Specify the name of the policing filter. 


no-auto-policing—Disable automatic policing on this LSP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Policers for LSPs | 149 
auto-policing | 1724 
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| policing 
Syntax 


policing (filter filter-name | no-automatic-policing); 


Hierarchy Level 


[edit protocols mpls label-switched-path Isp-name] 
[edit interfaces interface-id unit number-of-logical-unit family inet address ip-address] 


Release Information 
Statement introduced in Junos OS Release 10.1 for EX Series switches. 


Description 
Apply a rate-limiting policer as the specified policing filter: 
e To the LSP for MPLS over CCC. 


e To the customer-edge interface for IP over MPLS. 


Options 


filter filter-name—Specify the name of the policing filter. 


no-automatic-policing—Disable automatic policing on this LSP. 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


policer 

Configuring Policers to Control Traffic Rates (CLI Procedure) 

Configuring CoS on an MPLS Provider Edge Switch Using Circuit Cross-Connect | 1228 
Configuring CoS on an MPLS Provider Edge Switch Using IP Over MPLS | 1225 
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| policy-multipath 
Syntax 


policy-multipath policy [ policy } 
traceoptions <file filename <files files> <size size> <(world-readable | no-world-readable)>> name detail disable 
receive send 


Hierarchy Level 


[edit logical-systems name routing-instances name routing-options rib], 

[edit logical-systems name routing-options rib], 

[edit logical-systems name tenants name routing-instances name routing-options rib], 
[edit routing-instances name routing-options rib], 

[edit routing-options rib], 

[edit tenants name routing-instances name routing-options rib] 


Release Information 
Statement introduced in Junos OS Release 19.1R1 for all platfroms. 


Description 

Create policy-based multipath route using a combination of segment routing traffic-engineered (SR-TE) 
LDP or RSVP routes and SR-TE IP routes. You can resolve BGP service routes over the mutlipath route, 
and apply export policies to steer traffic differently for different prefixes. The policy-based multipath 
feature is supported for both IP and IPvé6 protocols. 


Options 


policy—Import policy to create policy-based multipath. 


NOTE: This statement is supported only at the [edit routing-option policy-multipath] hierarchy 
level. 


Any action commands configured in the policy, such as apply, is evaluated using the active route. For 
non-active routes, the policy is applied to check if the routes can participate in the multipath route or 
not. Multipath routes inherit all attributes of the active route. These attributes can be modified using 
the multipath policy configuration. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing 
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RELATED DOCUMENTATION 


Policy-Based Multipath Routes Overview | 188 
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| policy-statement 


Syntax 


policy-statement policy-name { 
term term-name { 
from { 
as-path-unique-count count (equal | orhigher | orlower); 
family family-name; 
match-conditions; 
policy subroutine-policy-name; 
prefix-list prefix-list-name; 
prefix-list-filter prefix-list-name match-type <actions>; 
protocol protocol-name; 
route-filter destination-prefix match-type <actions>; 
source-address-filter source-prefix match-type <actions>; 
tag value; 
traffic-engineering; 
} 
to { 
match-conditions; 
policy subroutine-policy-name; 
} 
then actions; 
} 
then { 
aggregate-bandwidth; 
dynamic-tunnel-attributes dynamic-tunnel-attributes; 
limit-bandwidth limit-bandwidth; 
multipath-resolve; 
no-entropy-label-capability; 
prefix-segment { 
index index; 
node-segment; 
} 
priority (high | medium | low); 
resolution-map map-name; 


Hierarchy Level 


[edit dynamic-profiles profile-name policy-options], 
[edit logical-systems logical-system-name policy-options], 
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[edit policy-options] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for configuration in the dynamic database introduced in Junos OS Release 9.5. 

Support for configuration in the dynamic database introduced in Junos OS Release 9.5 for EX Series 
switches. 

inet-mdt option introduced in Junos OS Release 10.0R2. 

Statement introduced in Junos OS Release 11.3 for the QFX Series. 

route-target option introduced in Junos OS Release 12.2. 

Statement introduced in Junos OS 14.1X53-D20 for the OCX Series. 

protocol and traffic-engineering options introduced in Junos OS Release 14.2. 
no-entropy-label-capability option introduced in Junos OS Release 15.1. 

priority and tag value options introduced in Junos OS Release 17.1. 

as-path-unique-count option introduced in Junos OS Release 17.2R1. 

prefix-segment option introduced in Junos OS Release 17.2R1 for MX Series routers, PTX Series routers, 
QFX5100 switches, and QFX10000 switches. 

multipath-resolve and dynamic-tunnel-attributes options introduced in Junos OS Release 17.3R1. 
aggregate-bandwidth and limit-bandwidth limit-bandwidth options introduced in Junos OS Release 17.4R1 
for MX Series, PTX Series, and QFX Series. 

I-isis and |-ospf keywords at the protocol option is introduced in Junos OS Release 19.1R1. 
resolution-map statement introduced in Junos OS Release 19.2R1-S1 on MX and PTX Series routers. 
Isp and Isp-regex options introduced in Junos OS Release 19.4R1. 


Description 


Define a routing policy, including subroutine policies. 


A term is a named structure in which match conditions and actions are defined. Routing policies are made 
up of one or more terms. Each routing policy term is identified by a term name. The name can contain 
letters, numbers, and hyphens (-) and can be up to 255 characters long. To include spaces in the name, 
enclose the entire name in double quotation marks. 


Each term contains a set of match conditions and a set of actions: 


e Match conditions are criteria that a route must match before the actions can be applied. If a route 
matches all criteria, one or more actions are applied to the route. 


e Actions specify whether to accept or reject the route, control how a series of policies are evaluated, and 
manipulate the characteristics associated with a route. 


Generally, a router compares a route against the match conditions of each term ina routing policy, starting 
with the first and moving through the terms in the order in which they are defined, until a match is made 
and an explicitly configured or default action of accept or reject is taken. If none of the terms in the policy 
match the route, the router compares the route against the next policy, and so on, until either an action 
is taken or the default policy is evaluated. 


If none of the match conditions of each term evaluates to true, the final action is executed. The final action 
is defined in an unnamed term. Additionally, you can define a default action (either accept or reject) that 
overrides any action intrinsic to the protocol. 


The order of match conditions in a term is not relevant, because a route must match all match conditions 
in a term for an action to be taken. 


To list the routing policies under the [edit policy-options] hierarchy level by policy-statement policy-name 
in alphabetical order, enter the show policy-options configuration command. 


The statements are explained separately. 
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Options 
actions—(Optional) One or more actions to take if the conditions match. The actions are described in 
Configuring Flow Control Actions. 


family family-name—(Optional) Specify an address family protocol. Specify inet for IPv4. Specify inet6 for 
128-bit IPv6, and to enable interpretation of IPv6 router filter addresses. For IS-IS traffic, specify iso. For 
IPv4 multicast VPN traffic, specify inet-mvpn. For IPv6 multicast VPN traffic, specify inet6-mvpn. For 
multicast-distribution-tree (MDT) IPv4 traffic, specify inet-mdt. For BGP route target VPN traffic, specify 
route-target. For traffic engineering, specify traffic-engineering. 


NOTE: When family is not specified, the routing device or routing instance uses the address 
family or families carried by BGP. If multiprotocol BGP (MP-BGP) is enabled, the policy defaults 
to the protocol family or families carried in the network layer reachability information (NLRI) as 
configured in the family statement for BGP. If MP-BGP is not enabled, the policy uses the default 
BGP address family unicast IPv4. 


from—(Optional) Match a route based on its source address. 


as-path-unique-count count (equal | orhigher | orlower)—(Optional) Specify a number from O through 1024 
to filter routes based on the number of unique autonomous systems (ASs) in the AS path. Specify the 
match condition for the unique AS path count. 


aggregate-bandwidth—(Optional) Enable BGP to advertise aggregate outbound link bandwidth for load 
balancing. 


dynamic-tunnel-attributes dynamic-tunnel-attributes—(Optional) Choose a set of defined dynamic tunnel 
attributes for forwarding traffic over V40V6 tunnels. 


match-conditions—(Optional in from statement; required in to statement) One or more conditions to use 
to make a match. The qualifiers are described in Routing Policy Match Conditions. 


multipath-resolve multipath-resolve-(Optional) Enable the use of all paths for resolution over the specified 
prefix. 


limit-bandwidth limit-bandwidth—(Optional) Specify the limit for advertised aggregate outbound link 
bandwidth for load balancing. 


Range: O through 4,294,967,295 bytes 


no-entropy-label-capability—(Optional) Disable the entropy label capability advertisement at egress or 
transit routes specified in the policy. 


priority (high | medium | low)—(Optional) Configure the priority for an IS-IS route to change the default 
order in which the routes are installed in the routing table, in the event of a network topology change. 


policy subroutine-policy-name—Use another policy as a match condition within this policy. The name 
identifying the subroutine policy can contain letters, numbers, and hyphens (-) and can be up to 

255 characters long. To include spaces in the name, enclose it in quotation marks (“”). Policy names cannot 
take the form __.*-internal__, as this form is reserved. For information about how to configure subroutines, 


see Understanding Policy Subroutines in Routing Policy Match Conditions. 


policy-name—Name that identifies the policy. The name can contain letters, numbers, and hyphens (-) and 
can be up to 255 characters long. To include spaces in the name, enclose it in quotation marks (“ ”). 


prefix-list prefix-list-name—Name of a list of IPv4 or IPvé6 prefixes. 


prefix-list-filter prefix-list-name—Name of a prefix list to evaluate using qualifiers; match-type is the type 
of match, and actions is the action to take if the prefixes match. 


protocol protocol-name—Name of the protocol used to control traffic engineering database import at the 
originating point. 


Starting in Junos OS Release 19.1R1, you can specify options to match label IS-IS and label OSPF routes 
using the I-isis and l-ospf options, respectively. The isis options matches all IS-IS routes, excluding labelled 
IS-IS routes. The ospf option matches all OSPF routes, including OSPFv2, OSPFv3 and labelled OSPF 
routes. 


resolution-map—(Optional) Set resolution map modes. A given resolution-map can be shared across multiple 
policy-statements. 


route-filter destination-prefix match-type <actions>—(Optional) List of routes on which to perform an 
immediate match; destination-prefix is the IPv4 or IPv6 route prefix to match, match-type is the type of 
match (see Configuring Route Lists), and actions is the action to take if the destination-prefix matches. 


source-address-filter source-prefix match-type <actions>—(Optional) Unicast source addresses in 
multiprotocol BGP (MBGP) and Multicast Source Discovery Protocol (MSDP) environments on which to 
perform an immediate match. source-prefix is the IPv4 or IPv6 route prefix to match, match-type is the 
type of match (see Configuring Route Lists), and actions is the action to take if the source-prefix matches. 


tag value—(Optional) A numeric value that identifies a route. You can tag certain routes to prioritize them 
over other routes. In the event of a network topology change, Junos OS updates these routes in the routing 
table before updating other routes with lower priority. You can also tag some routes to identify and reject 
them based on your requirement. 


term term-name—Name that identifies the term. The term name must be unique in the policy. It can contain 
letters, numbers, and hyphens (-) and can be up to 64 characters long. To include spaces in the name, 
enclose the entire name in quotation marks (“”). A policy statement can include multiple terms. We 
recommend that you name all terms. However, you do have the option to include an unnamed term which 
must be the final term in the policy. To configure an unnamed term, omit the term statement when defining 
match conditions and actions. 
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to—(Optional) Match a route based on its destination address or the protocols into which the route is being 
advertised. 


then—(Optional) Actions to take on matching routes. The actions are described in Configuring Flow Control 
Actions and Configuring Actions That Manipulate Route Characteristics. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


dynamic-db 
Understanding Source Packet Routing in Networking (SPRING) 
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| pop 


Syntax 
pop, 
Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name transit incoming-label], 
[edit protocols mpls static-label-switched-path Isp-name transit incoming-label] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Remove the label from the top of the label stack. If there is another label in the stack, that label becomes 
the label at the top of the label stack. Otherwise, the packet is forwarded as a native protocol packet 
(typically, as an IP packet). 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Intermediate and Egress Routers for Static LSPs | 578 
swap | 1966 
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| pop-and-forward (Protocols MPLS) 


Syntax 


pop-and-forward; 


Hierarchy Level 


[edit logical-systems name protocols mpls label-switched-path ], 

[edit logical-systems name routing-instances name protocols mpls label-switched-path J, 
[edit protocols mpls label-switched-path ], 

[edit routing-instances name protocols mpls label-switched-path ] 


Release Information 
Statement introduced in Junos OS Release 18.1R1 on MX Series routers, PTX Series routers, and vMX. 


Description 


Enable LSP as pop-and-forward with auto-delegation signaling enabled by default. 


The LSP undergoes a make-before-break from a regular point-to-point LSP to a pop-and-forward LSP. 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Pop-and-Forward LSP Configuration | 697 
show rsvp pop-and-forward | 2510 
pop-and-forward (Protocols RSVP) | 2046 


1907 


| preference (Protocols MPLS) 


Syntax 


preference preference; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name], 

[edit protocols mpls static-label-switched-path Isp-name ingress] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Preference for the route. 


You can optionally configure multiple LSPs between the same pair of ingress and egress routers. This is 
useful for balancing the load among the LSPs because all LSPs, by default, have the same preference level. 
To prefer one LSP over another, set different preference levels for individual LSPs. The LSP with the lowest 
preference value is used. The default preference for LSPs is lower (more preferred) than all learned routes 
except direct interface routes. 


Options 

preference—Preference to assign to the route. A route with a lower preference value is preferred. 
Range: 1 through 255 
Default: 5 for static MPLS LSPs, 7 for RSVP MPLS LSPs, 9 for LDP MPLS LSPs 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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Configuring Preference Values for LSPs | 507 
Configuring the Ingress Router for Static LSPs | 575 
Configuring the Intermediate (Transit) and Egress Routers for Static LSPs | 578 


1909 


primary (Protocols MPLS) 


Syntax 


primary path-name { 
adaptive; 
admin-group { 
exclude [ group-names ]; 
include-all [ group-names ]; 
include-any [ group-names ]; 
} 
bandwidth bps; 
class-of-service cos-value; 
hop-limit number; 
no-cspf; 
no-decrement-ttl; 
optimize-timer seconds; 
preference preference; 
priority setup-priority reservation-priority; 
(record | no-record); 
select (manual | unconditional); 
standby; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify the primary path to use for an LSP. You can configure only one primary path. 


You can optionally specify preference, CoS, and bandwidth values for the primary path, which override 
any equivalent values that you configure for the LSP (at the [edit mpls label-switched-path Isp-name] 
hierarchy level). 


Options 


path-name—Name of a path that you created with the path statement. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| Configuring Primary and Secondary LSPs | 570 


primary 


Syntax 


primary path-name; 


Hierarchy Level 


[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Specify the primary path to use for a label switched path (LSP). You can configure only one primary path. 


Options 
path-name —Name of the primary path that you created with the path statement. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Path Protection in an MPLS Network (CLI Procedure) | 280 
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| priority (Protocols MPLS) 


Syntax 


priority setup-priority reservation-priority; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 

Configure the setup priority and reservation priority for an LSP. If insufficient link bandwidth is available 
during session establishment, the setup priority is compared with other setup priorities for established 
sessions on the link to determine whether some of them should be preempted to accommodate the new 
session. Sessions with lower hold priorities are preempted. 


Options 
reservation-priority—Reservation priority, used to keep a reservation after it has been set up. A smaller 
number has a higher priority. The priority must be greater than or equal to the setup priority to prevent 
preemption loops. 

Range: O through 7, where 0 is the highest and 7 is the lowest priority. 


Default: O (Once the session is set up, no other session can preempt it.) 


setup-priority—Setup priority. 
Range: O through 7, where 0 is the highest and 7 is the lowest priority. 


Default: 7 (The session cannot preempt any existing sessions.) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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| Configuring Priority and Preemption for LSPs | 502 


| protection-revert-time 


Syntax 


protection-revert-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls interface interface-name static], 
[edit protocols mpls interface interface-name static] 


Release Information 
Statement introduced in Junos OS Release 10.1. 


Description 
Specify the amount of time (in seconds) that a static LSP must wait before traffic reverts from the bypass 
path to the original path. 


If you have configured a value of O seconds for the protection-revert-time statement and traffic is switched 
to the bypass path, the traffic remains on that path indefinitely. It is never switched back to the original 
path unless the bypass path is down or you intervene. 


Options 
seconds—Time in seconds. 
Range: O through 65,535 seconds 


Default: 5 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Static LSPs | 574 
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| push 
Syntax 


push out-label; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name bypass], 
[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 
[edit protocols mpls static-label-switched-path Isp-name bypass], 
[edit protocols mpls static-label-switched-path Isp-name ingress] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Add a new label to the top of the label stack. This statement is used to configure static LSPs at ingress 
routers and to configure bypass LSPs for static LSPs. 


Options 
out-label—Manually assigned outgoing label value. 
Range: O through 1,048,575. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


pop | 1905 
swap | 1966 
Configuring the Ingress Router for Static LSPs | 575 
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random 


Syntax 


(random | least-fill | most-fill); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 

Configure the preferred path when several equal-cost candidate paths to a destination exist, and prefer 

the path with the highest available bandwidth (with the largest minimum available bandwidth ratio). The 

available bandwidth ratio of a link is the available bandwidth on a link divided by the maximum reservable 
bandwidth on the link. 


e least-fill—Prefer the path with the most available bandwidth (with the largest available bandwidth ratio). 


e most-fill—Prefer the path with the least available bandwidth (with the minimum available bandwidth 
ratio). The minimum available bandwidth ratio of a path is the smallest available bandwidth ratio belonging 
to any of the links in the path. 


e random—Choose the path at random. 


Default 


random 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring CSPF Tie Breaking | 482 
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record 


Syntax 


(record | no-record); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path (primary | secondary) path-name], 
[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify whether an LSP should actively record the path by sending the record route object (RRO) of an 
LSP. The RRO is used to record the path that the LSP traverses. It includes the IP address, router ID, and 
node ID of the routers in the path. Recording LSP path can be useful for diagnostics and loop detection. 


Default 


Recording LSP path is enabled by default when you have node or link protection configured on the device. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Disabling Path Route Recording by LSPs | 508 
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| remote-interface-switch 


Syntax 


remote-interface-switch connection-name { 
interface interface-name.unit-number,; 
receive-lsp label-switched-path; 
transmit-lsp label-switched-path; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols connections], 
[edit protocols connections (MPLS)] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 


Description 
Configure MPLS LSP tunnel cross-connects. This makes an association between a CCC interface and two 
LSPs, one for transmitting MPLS packets from the local provider edge switch to the remote provider edge 
switch and the other for receiving MPLS packets on the local provider edge switch from the remote provider 
edge switch. 


Options 


connection-name—Connection name. 


interface interface-name.unit-number—Interface name. Include the logical portion of the name, which 
corresponds to the logical unit number of the CCC interface. 


receive-Isp label-switched-path—Name of the LSP from the connection’s source. This LSP name was 
specified by the label-switched-path statement on the remote provider edge switch in the protocols mpls 
stanza. 


transmit-Isp label-switched-path—Name of the LSP to the connection’s destination. This LSP name was 
specified by the label-switched-path statement on the local provider edge switch in the protocols mpls 
stanza. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Configuring MPLS LSP Tunnel Cross-Connects Using CCC | 1331 

Example: Configuring MPLS on EX8200 and EX4500 Switches | 42 

Configuring MPLS on Provider Edge EX8200 and EX4500 Switches Using Circuit Cross-Connect | 74 
Configuring MPLS on Provider Edge Switches Using IP-Over-MPLS | 68 

MPLS Applications User Guide 
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| remote-site-id 
Syntax 


remote-site-id remote-site-ID; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols |2vpn site site-name 
interface interface-name], 
[edit routing-instances routing-instance-name protocols |2vpn site site-name interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 11.1 for EX Series switches. 


Description 

Control the remote interface to which the interface should connect. If you do not explicitly configure the 
remote site ID, the order of the interfaces configured for the site determines the default value. This 
statement is optional. 


Options 
remote-site-[D—Identifier specifying the interface on the remote PE router the Layer 2 VPN routing instance 
connects to. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Remote Site ID 
Configuring an MPLS-Based Layer 2 VPN (CLI Procedure) 
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| retry-limit 
Syntax 


retry-limit number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name], 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Maximum number of times the ingress router tries to establish the primary path. This counter is reset each 
time a primary path is created successfully. When the limit is exceeded, no more connection attempts are 
made. Intervention is then required to restart the connection. 


Options 
number—Maximum number of tries to establish the primary path. 
Range: O through 10,000 
Default: O (The ingress node never stops trying to establish the primary path.) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Connection Between Ingress and Egress Routers | 493 
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| retry-timer 
Syntax 


retry-timer seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Amount of time the ingress router waits between attempts to establish the primary path. 


Options 

seconds—Amount of time between attempts to connect to the primary path. 
Range: 1 through 600 seconds 
Default: 30 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Connection Between Ingress and Egress Routers | 493 
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| revert-timer 


Syntax 


revert-timer seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

BFD behavior modified in Junos OS Release 9.0. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Specify the amount of time (in seconds) that an LSP must wait before traffic reverts to a primary path. If 
during this time the primary path experiences any connectivity problem or stability problem, the timer is 
restarted. 


If you have configured BFD on the LSP, the Junos OS waits until the BFD session is restored before starting 
the revert timer counter. 


If you have configured a value of O seconds for the revert-timer statement and traffic is switched to the 
secondary path, the traffic remains on that path indefinitely. It is never switched back to the primary path 
unless you intervene. 


Options 

seconds—Time in seconds. 
Range: O through 65,535 seconds 
Default: 60 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Revert Timer for LSPs | 571 
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revert-timer 


Syntax 


revert-timer seconds; 


Hierarchy Level 


[edit protocols mpls], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 


Description 

Specify the amount of time that a label switched path (LSP) must wait before traffic reverts to a primary 
path. If during this time the primary path experiences any connectivity problem or stability problem, the 
timer is restarted. 


If you have configured a value of O seconds for the revert-timer statement and traffic is switched to the 
secondary path, the traffic remains on that path indefinitely. It is never switched back to the primary path 
unless you intervene. 


Default 


60 seconds 


Options 
seconds —Value in seconds. 
Range: O through 65,535 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Path Protection in an MPLS Network (CLI Procedure) | 280 
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| resignal-minimum-bandwidth 
Syntax 


resignal-minimum-bandwidth; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 
[edit protocols mpls label-switched-path Isp-name auto-bandwidth] 


Release Information 
Statement introduced in Junos OS Release 12.2. 


Description 


Resignal the LSP using the configured minimum bandwidth when an LSP comes back up after going down. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Automatic Bandwidth Allocation for LSPs | 517 
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| resolution-map 


Syntax 


resolution-map name { 
mode (color-only | ip-color); 


Hierarchy Level 


[edit logical-systems name policy-options], 
[edit policy-options] 


Release Information 
Statement introduced in Junos OS Release 19.2R1-S1 on MX Series and PTX Series routers. 


Description 


Define a set of protocol next hop resolution modes. 


A resolution-map can be referred by a new resolution-map action of a policy statement, which is in turn 
applied to a VPN service through the routing-instance import-vrf. A given resolution-map may be shared 
by multiple policy-statements. 


Options 
name—Resolution Map name. 


mode-—List of resolution modes in order that defines fallback mechanism. 
Values: 
e color-only—Color-only protocol next hop resolution mode. 


e ip-color—Colored-IP protocol next hop resolution mode. 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Color-Based Mapping of VPN Services Overview 
Static Segment Routing Label Switched Path | 710 
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| responder (performance-monitoring) 


Syntax 


responder { 
delay { 
min-query-interval milliseconds; 


} 
loss { 
min-query-interval milliseconds; 


Hierarchy Level 


[edit protocols mpls oam performance-monitoring], 

[edit protocols mpls label-switched-path Isp-name oam performance-monitoring], 

[edit protocols mpls label-switched-path Isp-name primary path-name oam performance-monitoring], 
[edit protocols mpls label-switched-path Isp-name secondary path-name oam performance-monitoring] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Configure responder options. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Pro-Active Loss and Delay Measurements | 417 
On-Demand Packet Loss and Delay Measurement for UHP LSPs Overview | 388 
performance-monitoring (Protocols MPLS) | 1893 
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rpf-check-policy (Routing Options) 
Syntax 


rpf-check-policy policy; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options multicast], 
[edit routing-options multicast] 


Release Information 
Statement introduced in Junos OS Release 8.0. 
Statement introduced in Junos OS Release 12.3 for ACX Series routers. 


Description 

Enable you to control whether a reverse path forwarding (RPF) check is performed for a source and group 
entry before installing a route in the multicast forwarding cache. This makes it possible to use 
point-to-multipoint LSPs to distribute multicast traffic to Protocol Independent Multicast (PIM) islands 
situated downstream from the egress routers of the point-to-multipoint LSPs. 


Options 
policy—Name of the RPF check routing policy. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring a Multicast RPF Check Policy for Point-to-Multipoint LSPs | 691 
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| rsvp-error-hold-time 


Syntax 


rsvp-error-hold-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Amount of time MPLS retains RSVP PathErr messages and considers them for CSPF computations. The 
more time you configure, the more time a source node (ingress of an RSVP LSP) can have to learn about 
the failures of its LSP by monitoring PathErr messages transmitted from downstream nodes. 


Information from the PathErr messages is incorporated into subsequent LSP computations, which can 
improve the accuracy and speed of LSP setup. Some PathErr messages are also used to update traffic 
engineering database bandwidth information, reducing inconsistencies between the database and the 
network. 


Options 

seconds—Amount of time MPLS retains RSVP PathErr messages and considers them for CSPF computations. 
Range: O through 240 seconds 
Default: 25 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Improving Traffic Engineering Database Accuracy with RSVP PathErr Messages | 1115 
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| sampling (Protocols MPLS) 


Syntax 


sampling { 
cut-off-threshold percentile; 
use-average-aggregate; 
use-percentile percentile; 


Hierarchy Level 


[edit protocols mpls container-label-switched-path Isp-name splitting-merging] 


Release Information 
Statement introduced in Junos OS Release 14.2. 
Statement introduced in Junos OS Release 17.2R1 for the QFX Series switches. 


Description 


Configure traffic sampling. By default, sampling mode is set to Max Aggregate which means the system 
will compare each new sample with the previous sample. If the new sample is higher than the old sample, 
then the newer sample is considered Sampled Aggregate bandwidth 


Max Aggregate Example 


If normalization happens every 20min (TO, T20, T40..) then if at time TO the traffic rate is 185Gbps, and 
subsequently drops to 7.5Gbps at time T3, the max-aggregate sample for the current normalization window 
TO-T20 will be 185Gbps. When the current normalization window expires at time T20, we use the previous 
sampled max-aggregate of 185Gbps to calculate the split/merge activities of the next (or now current) 
normalization window between T20 - T4O. If traffic remains at 7.5Gbps for this second normalization 
period, then at time T40 the max-aggregate sample of 7.5Gbps would then be used for split/merge activities. 
Even though traffic volumes dropped at time T3, LSP split/merge activities would not occur until time T40 
which might be unexpected. This default behavior can be modified with use-average-aggregate or 
use-percentile to achieve alternative normalization behavior if desired. 


Options 

cut-off-threshold percentile—Specify the percentile value to be used as a cut-off threshold in removing 
outlier bandwidth samples. All the aggregate bandwidth samples determined as outliers are used for 
computing aggregate bandwidth used at the time of normalization. 
Default: O percentile (the ingress considers all aggregate bandwidth samples for normlaization.) 
Range: O through 100 
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use-average-aggregate—Specify the ingress router to take average of the aggregate samples for 
normalization. 


This option is mutually exclusive with the use-percentile configuration option. 


use-percentile percentile—Specify the ingress router to compute and use the pth percentile from all the 
bandwidth samples, and use that for normalization. 


This option is mutually exclusive with the use-average-aggregate configuration option. 
Range: O through 100 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


splitting-merging | 1953 
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| sbfd 


Syntax 


sbfd { 
remote-discriminator remote-discriminator; 


Hierarchy Level 


[edit protocols source-packet-routing source-routing-path name primary name bfd-liveness-detection (LSP)], 
[edit protocols source-packet-routing source-routing-path name secondary name bfd-liveness-detection (LSP)] 


Release Information 
Statement introduced in Junos OS Release 19.1R1. 


Description 


Configure seamless BFD (S-BFD) parameters in the source routing path. 


Options 
remote-discriminator—Remote discriminator of reflector 
Range: 1 through 4294967295 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Routing Engine-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label 
Resolution | 755 


bfd-liveness-detection (LSP) | 1735 
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| secondary (Protocols MPLS) 


Syntax 


secondary path-name { 
adaptive; 
admin-group { 
exclude [ group-names ]; 
include-all [ group-names ]; 
include-any [ group-names ]; 
} 
bandwidth bps; 
class-of-service cos-value; 
hop-limit number; 
no-cspf; 
no-decrement-ttl; 
optimize-timer seconds; 
preference preference; 
priority setup-priority reservation-priority; 
(record | no-record); 
retry-limit number; 
retry-timer seconds; 
select (manual | unconditional); 
standby; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify one or more secondary paths to use for the LSP. You can configure more than one secondary path. 
All secondary paths are equal, and the first one that is available is chosen. 


You can specify secondary paths even if you have not specified any primary paths. 


Optionally, you can specify preference, CoS, and bandwidth values for the secondary path, which override 
any equivalent values that you configure for the LSP (at the [edit mpls label-switched-path] hierarchy 
level). 


Options 


path-name—Name of a path that you created with the path statement. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Primary and Secondary LSPs | 570 
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1933 


| secondary 


Syntax 


secondary path-name { 
standby; 
} 


Hierarchy Level 


[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 


Description 
Specify one or more secondary paths to use for the label switched path (LSP). You can configure more 
than one secondary path. All secondary paths are equal, and the first one that is available is chosen. 


Options 


path-name —Name of a secondary path that you created with the path statement. 


The remaining statement is explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Path Protection in an MPLS Network (CLI Procedure) | 280 
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| segment 


Syntax 


segment { 
(pop | swap swap), 
description description; 
next-hop next-hop; 
sid-label; 


Hierarchy Level 


[edit logical-systems name protocols mpls static-label-switched-path], 

[edit logical-systems name routing-instances name protocols mpls static-label-switched-path], 
[edit protocols mpls static-label-switched-path], 

[edit routing-instances name protocols mpls static-label-switched-path] 


Release Information 
Statement introduced in Junos OS Release OS 18.1R1 for MX Series, PTX Series, and QFX Series. 


Description 

Static segment for segment routing. A static segment is identified by a unique name. This segment type is 
assigned a segment identifier (SID) which falls under a default range of 100000 through 1048575. The 
segment has label operation such as pop-and-forward for adjacency segment and swap-and-forward for 
prefix or node segment. For both types of label operation, the segment is assigned a next hop that specifies 
the remote IP address if the outgoing interface is a multi-access interface, or the name of the outgoing 
interface if the interface is a point-to-point interface. Static segment configuration is used to statically 
configure or provision the adjacency SIDs, node SIDs, and prefix SIDs on transit routers. 


Options 
pop—Pop the SID label 


swap—Swap the SID label to this label 
description—Text description of label-switched path 
next-hop—IPv4 address or interface of next-hop router 
sid-label—Segment identifier (SID) label 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing 
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RELATED DOCUMENTATION 


Static Segment Routing Label Switched Path | 710 
segment-list | 1936 
source-routing-path | 1948 
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| segment-list 
Syntax 


segment-list name { 

hop-name { 
(loose | strict); 
ip_address IP address; 
label number ; 
label-type node; 

} 

auto-translate { 
protected mandatory; 
unprotected mandatory; 


} 

dynamic; 

compute; 
inherit-label-nexthops; 


Hierarchy Level 


[edit logical-systems name protocols source-packet-routing], 
[edit protocols source-packet-routing] 


Release Information 

Statement introduced in Junos OS Release 17.4R1 for MX Series and PTX Series with FPC-PTX-P1-A. 
ip-address statement introduced in Junos OS Release 18.1R1 on MX Series routers. 
inherit-label-nexthops, node-type, and auto-translate statements introduced in Junos OS Release 19.1R1 
on MX Series routers. 

dynamic statement introduced in Junos OS Release 19.2R1 on all platforms. 

compute, loose, and strict statements introduced in Junos OS Release 19.1R1-S1 on MX Series routers. 


Description 

Specify an name to identify the segment routing list (used in traffic engineering policy) and the explicit 
path for source routing label switched path (LSPs) to traverse through traffic engineering segments. The 
segment list is essentially a stack of segment identifiers. 


Starting in Junos OS release 19.1R1 for MX and PTX Series routers, you can enable a translation service 
to translate next-hop IP addresses into the corresponding segment identifier (SID) labels. The translation 
service keeps track of the node reached at each hop. 


When configured, the segment-list of a segment routing traffic engineering (SR-TE) LSP accepts IP addresses 
for all the hops along the path. These IP addresses can be either the loopback address of a node, or the 
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IP address of a link, as identified by the node-type. When auto-translation is enabled, next hop IP addresses 
are automatically translated to corresponding SIDs using the translation service. A retry rate can be set 
for the retry timer at the source-packet-routing hierarchy level. 


NOTE: The segment list enables BGP and static segment routing LSP to steer traffic based on 
segment routing policies. When a segment list is used by the protocol BGP, the BGP protocol 
validates these segment identifiers and selects valid segments for traffic engineering. 
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Options 


<hop-name>—Indicates the next hop in the segment routing traffic engineering policy (SR-TE). 


e ip-address—Specify the IP address of the hop. For a segment-list to be used by a non-colored segment 
routing LSP, the first hop must specify an IP address. 


e label—Specify the SID label of the hop in a segment routing traffic engineering segment list. In static 
segment routing LSPs, the source routing path uses the segment list only if the second to Nth hop 
specifies segment identifiers (SID) labels. 


NOTE: The range is from O to 1,048,576 and is applies to BGP and static segment routing 
LSPs. 


e label-type—Use with the option below to indicate that the specified address is the IP address of the 
node, for example, its loopback address, as opposed to that of a link. 


e node—Hops that have been specified as node are translated to a prefix SID, which can be either 
anode SID or an anycast SID depending on the type of hop IP address. IP addresses not identified 
as node are consider to be a link. 


NOTE: If the first hop is anode, for LSP resolution to work correctly, inherit-label-nexthops 
must be enabled at either source-packet-routing hierarchy level, or at the relevant 
segment-list hierarchy level. 


e loose | strict—IP hops specified using router IDs in the sequence can be strict or loose hops. A strict 
hop must be directly connected to the previous node in the sequence. A loose hop is not necessarily 
directly connected to the previous node. 


NOTE: You can specify only router IDs as loose or strict hop constraints. Labels and other 
IP addresses are not supported as loose or strict hop constraints in Junos OS Release 
19.2R1-S1. 


auto-translate— This option must be enabled before a given segment list can use IP addresses instead of 
SIDs for any hop other than the first hop. In addition, all hops in the segment list must have IP addresses. 
If any hops on the list have both an IP address and a label configured, the label will be retained. Link 
addresses are only translated into labels if the preceding node advertises an adjacency SID for the 
address (otherwise translation fails). 
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NOTE: In Junos OS Release 19.1R1, for auto-translate to work for OSPF, RSVP for segment 
routing must be enabled on all participating interfaces. 


e protected—(Optional) Enable this option to ensure the adjacency SID is eligible to have a backup 
path, and that a B-flag is set in adjacency SID advertisements. Note that unless mandatory is also 
selected, the choice succeeds regardless. 


e mandatory—(Optional) Enable this option to have translation fail if any unprotected links are found 
in the hop-list. 


unprotected—(Optional) Enable this option to ensure that no backup path is calculated for a specific 
adjacency SID, and that a B-flag is not set in adjacency SID advertisements. Note that unless 
mandatory is also selected, the choice succeeds regardless. 


mandatory—(Optional) Enable this option to have translation fail if any protected links are found 
the hop-list. 


compute—(Optional) Enable use of explicit paths specified in segment list for path computation. 


inherit-label-nexthops—Inherit label next hops for first hop in this segment list that have both IP address 
and label configured in the first hop. 


You can configure the inherit-label-nexthops statement globally or individually for each segment list. 


The inherit-label-nexthops statement takes effect only when the segment list first hop has both IP 
address and SID label present. 


If the inherit-label-nexthops is not configured at the [edit protocols source-packet-routing segment-list] 
hierarchy, and the first hop in the segment list has both IP address and label specified, the default 
behavior is to use the IP address. 


The remaining statements are explained separately. Search for a statement in CLI Explorer or click a linked 
statement in the Syntax section for details. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Static Adjacency Segment Identifier for ISIS 

Static Segment Routing Label Switched Path | 710 

Segment Routing Traffic Engineering at BGP Ingress Peer Overview 
Understanding Static Segment Routing LSP in MPLS Networks | 711 
show spring-traffic-engineering | 2703 

extended-nexthop-color 


source-routing-path | 1948 





sr-preference-override 
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| select 


Syntax 


select (manual | unconditional); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 
[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify the conditions under which the path is selected to carry traffic. The manual and unconditional 
options are mutually exclusive. 


Options 
manual—The path is selected for carrying traffic if it is up and stable for at least the revert timer window 


(potentially before the revert timer has elapsed). Traffic is sent to other working paths if the current path 
is down or degraded (receiving errors). 


unconditional—The path is always selected for carrying traffic, even if it is currently down or degraded 
(receiving errors). 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Specifying the Conditions for Path Selection | 572 


1942 


| signal-bandwidth 
Syntax 


signal-bandwidth type; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name Isp-attributes], 
[edit protocols mpls label-switched-path Isp-name Isp-attributes] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify the bandwidth encoding of the signal used for path computation and admission control. 


Options 

type—Configure the type of bandwidth encoding used on the LSP. It can be any of the following values: 
10gigether, ds1, ds3, e1, e3, ethernet, fastether, gigether, stm-1, stm-4, stm-16, stm-64, stm-256, sts-1, 
vt1-5, or vt2. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Signal Bandwidth Type | 1265 
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| signaling 
Syntax 


signaling; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family inet-mdt], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family inet-mvpn], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name 
family inet-mdt], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name 
family inet-mvpn], 

[edit routing-instances routing-instance-name protocols bgp family inet-mdt], 

[edit routing-instances routing-instance-name protocols bgp family inet-mvpn], 

[edit routing-instances routing-instance-name protocols bgp group group-name family inet-mdt], 

[edit routing-instances routing-instance-name protocols bgp group group-name family inet-mvpn] 


Release Information 
Statement introduced in Junos OS Release 9.4. 
Statement introduced in Junos OS Release 11.1 for EX Series switches. 


Description 


Enable signaling in BGP. For multicast distribution tree (MDT) subaddress family identifier (SAFI) NLRI 
signaling, configure signaling under the inet-mdt family. For multiprotocol BGP (MBGP) intra-AS NLRI 
signaling, configure signaling under the inet-mvpn family. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Source-Specific Multicast for Draft-Rosen Multicast VPNs 
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| site (Layer 2 Circuits) 
Syntax 


site site-name { 

hot-standby; 

site-identifier identifier; 

site-preference preference-value { 
backup; 
primary; 

} 

interface interface-name { 
description text; 
remote-site-id remote-site-ID; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols |2vpn], 


[edit routing-instances routing-instance-name protocols |2vpn] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 11.1 for EX Series switches. 
hot-standby option introduced in Junos OS Release 14.2 for MX Series routers. 


Description 
Specify the site name, site identifier, and interfaces connecting to the site. Allows you to configure a remote 
site ID for remote sites. 


Options 
hot-standby—Turn on the protector behavior for the site. This keeps backup pseudowire in continuous 
standby mode and ready for traffic forwarding. 


site-identifier identifier—Numerical identifier for the site used as a default reference for the remote site 
ID. 


site-name—Name of the site. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Site 
Configuring an MPLS-Based Layer 2 VPN (CLI Procedure) 


site-identifier (Layer 2 Circuits) 


Syntax 


site-identifier identifier; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name protocols |2vpn site site-name], 
[edit routing-instances routing-instance-name protocols |2vpn site site-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 11.1 for EX Series switches. 


Description 


Specify the numerical identifier for the local Layer 2 VPN site. 


Options 
identifier—The numerical identifier for the Layer 2 VPN site, which can be any number from 1 
through 65,534. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Site 
Configuring an MPLS-Based Layer 2 VPN (CLI Procedure) 
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| smart-optimize-timer 
Syntax 


smart-optimize-timer seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Enable the smart optimization timer. When you enable the smart optimization timer on a router, the Junos 
OS operates on the assumption that the original LSP path is preferable to any alternate or secondary path. 
When you enable the smart optimization timer and an LSP fails and its traffic is switched to an alternate 
path, the smart optimization timer starts and waits 3 minutes (this time is configurable). After 3 minutes 
have passed, the LSP is switched back to the original path. If the original path fails again and the LSP is 
switched to an alternate path again, the router waits 1 hour before attempting to switch the LSP back to 
its original path. 


If you want to disable the smart optimizer, you can set it to zero. The smart-optimize-timer value in seconds 
indicates the time before which the LSP is switched back to its primary path in case the primary path 
becomes available. Otherwise, the time to wait is controlled by the optimize-timer, which is usually set to 
a high value. Some ISPs have the optimize-timer set to once a day. Sometimes after the smart optimizer 
causes the LSP to be placed back on its primary path, the primary path goes down again within 60 minutes. 
When this happens, the smart-optimize-timer is disabled automatically, and the optimize-timer (regular 
path optimization) goes into effect. This is to protect against a flapping link being used. 


Default 


The smart optimization timer is enabled by default. 


Options 
seconds—(Optional) Specify the number of seconds to wait before switching an LSP back to its original 
path. If you do not specify the number of seconds, the default value is used. 

Range: O through 65,535 seconds 

Default: 180 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
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routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Smart Optimize Timer for LSPs | 515 
Optimizing Signaled LSPs | 511 
optimize-aggressive | 1880 





optimize-timer | 1883 


soft-preemption (Protocols MPLS) 


Syntax 


soft-preemption; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Attempt to establish a new path for a preempted LSP before tearing it down. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring MPLS Soft Preemption | 501 
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| source-routing-path 


Syntax 


source-routing-path name { 
binding-sid binding-sid; 
color color; 
Isp-external-controller; 
metric value; 
no-ingress; 
primary name { 
Isp-external-controller; 
weight weight; 
} 
secondary name { 
weight weight; 
} 
sr-preference sr-preference; 
to to; 


Hierarchy Level 


[edit logical-systems name protocols source-packet-routing], 
[edit protocols source-packet-routing] 


Release Information 

Statement introduced in Junos OS Release 17.4R1. 

The metric, no-ingress, and secondary statements are introduced in Junos OS Release 18.1R1. 
Isp-external-controller statement introduced in Junos OS Release 20.1R1. 


Description 

Configure a source-routing label switched path (LSP) for steering traffic at an ingress router. Specify a 
binding segment identifier from the static label range. Configure other parameters such as color, weight, 
preference, and segment routing preference for traffic engineering. 


Starting with Junos OS Release 18.1R1, compute static noncolored segment routing LSPs for protocol 
SPRING-TE in an MPLS network. Configure parameters such as destination address, binding SIDs, primary 
segment, secondary segment, metric, and preference. These segment routing LSPs do not have a color 
associated with them. If an ingress route is not required for a non-colored segment routing LSP then the 
ingress route installation in inet.3 table can be disabled. 


Options 


name-—Specify a name to identify a source routing path. 
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binding-sid—(Optional) Specify the binding label to enable transit functionality for this tunnel. For a 
non-colored static segment routing LSP, the binding SID label of protocol SPRING-TE have a default 
preference value of 8 and a metric of 1. 


Range: 16 through 1,048,576 


color—(Colored segment routing LSPs only) Specify a color identifier for the tunnel endpoint. For noncolored 
segment routing LSPs, you do not have to configure the color parameter. 


Isp-external-controller—Enable external path computing capability for the device. See Isp-external-controller 
for more information. 


metric—Specify metric for routes downloaded for the non-colored static segment routing tunnel. 
Default: 1,000,000 through 1,048,575 
Range: 1 through 16,777,215 (for BGP) 


no-ingress—Disable ingress route that is not required for the non-colored static segment routing tunnel 


primary— Specify a primary segment list for the configured source routing path. 


The non-colored static segment routing LSP can have a maximum of 8 primary paths. incase of multiple 
operational primary paths, the PFE distributes the traffic over the paths based on the weight configured 
on the paths. If none of the paths have weights configured then the weights default to 1 making it an 
ECMP path. the paths become weighted ECMP if at least one of the paths have a non-zero weight. In 
both cases , when one or some of the paths fail, the PFE automatically re-balances the traffic over the 


remaining paths resulting in path protection. 


weight weight_value— Specify a percentage of the bandwidth with respect to the sum of weights of all 
paths for the primary segment list. If forwarding interfaces are also configured with weighted ECMP, 
then Junos OS applies hierarchical weighted ECMP. If the weight percentage is not configured, then 
only IGP weights are applied on the forwarding interfaces. 


secondary—Specify a secondary segment list for the configured non-colored static segment routing LSP. 


sr-preference— Configure a preference for segment routing routes for traffic engineering. BGP chooses 
a higher preference over a lower preference value. 


Range: 0 through 4,294,967,295 


to—Specify the IP address of the tunnel end-point 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


extended-nexthop-color 
segment-list | 1936 
source-packet-routing 
sr-preference-override 


Segment Routing Traffic Engineering at BGP Ingress Peer Overview 





Enable Segment Routing for the Path Computation Element Protocol | 1431 
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| source-routing-path-template 


Syntax 


source-routing-path-template name { 

bfd-liveness-detection; 

Idp-tunneling; 

metric metric; 

no-ingress; 

primary name { 
Isp-external-controller; 
weight weight; 

} 

secondary name; 

sr-preference sr-preference; 


Hierarchy Level 


[edit protocols source-packet-routing] 


Release Information 

Statement introduced in Junos OS Release 19.2R1. 

bfd-liveness-detection and Idp-tunneling options introduced in Junos OS Release 19.4R1. 
Isp-external-controller statement introduced in Junos OS Release 20.1R1. 


Description 


Configure a source-routing path template for dynamic creation of segment routing label-switched paths 
(LSPs). 


Options 


name—Name of the source routing path. 


bfd-liveness-detection—Configure Bidirectional Forwarding Detection (BFD) options for PCE-initiated 
segment routing LSP template. See bfd-liveness-detection for more information. 


Idp-tunneling—Allow LDP to use this LSP for tunneling. This configuration can be applied to PCE-initiated 
segment routing LSPs only. 


Isp-external-controller—Enable external path computing capability for the device. See Isp-external-controller 
for more information. 


metric—Metric for routes downloaded for this tunnel. 
Range: 1 through 16,777,215 
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no-ingress—Disable ingress functionality for this tunnel. 


primary name—Configure a named identifier for the segment-list that describes the primary segment 
routing path along which the packet is to be routed. This segment list must have the dynamic statement 
enabled for dynamic creation of segment routing LSPs. 


weight weight—(Optional) Specify the balance factor for this segment list in SR-TE tunnel. 


If the forwarding interfaces have weights assigned by IGP, then hierarchical weighted ECMP is applied. 
When weight is not specified, only the IGP weights are applied on the forwarding interfaces. 


secondary name—Configure a named identifier for the segment-list that describes the secondary segment 
routing path along which the packet is to be routed. This segment list must have the dynamic statement 
enabled for dynamic creation of segment routing LSPs. 


sr-preference—Segment routing preference for the segment routing traffic engineered (SPRING-TE) routes. 
A greater value indicates higher preference. 


The preference value of the routes programmed for the segment routing LSP is inherited from the 
preference value statement at the [edit protocols source-packet-routing hierarchy level. When this 
value is not configured, the default preference value of 8 is used. 


Range: O through 4,294,967,295 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Understanding Static Segment Routing LSP in MPLS Networks | 711 


source-routing-path-template-map 
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| splitting-merging 
Syntax 


splitting-merging { 
maximum-member-lsps number; 
maximum-signaling-bandwidth bps; 
merging-bandwidth bps; 
minimum-member-lsps number; 
minimum-signaling-bandwidth bps; 
normalization; 
sampling; 
splitting-bandwidth bps; 
splitting-merging-threshold percent; 


Hierarchy Level 


[edit protocols mpls container-label-switched-path Isp-name] 


Release Information 
Statement introduced in Junos OS Release 14.2. 
Statement introduced for QFX Series switches in Junos OS Release 15.1X53-D30. 


Description 


Perform splitting and merging. 


Options 

maximum-member-Isps number—Number of label-switched paths (LSPs) that a container LSP can have as 
member LSPs at maximum. 
Default: 1 


maximum-signaling-bandwidth bandwidth—Amount of bandwidth in bits per second (bps) that can be 
signaled for an LSP at maximum after normalization. When maximum-signaling-bandwidth is not 
configured, the value is derived from the splitting-bandwidth. 


When auto-bandwidth adjustment is done between two normalization events, per LSP auto-bandwidth 
configuration and thresholds are used instead of the splitting-bandwidth. 


Default: 1 bps 


merging-bandwidth bandwidth—Amount of bandwidth in bits per second (bps) that is used for merging 
during normalization. 
Default: 1 bps 
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minimum-member-Isps number—Number of LSPd that a container LSP can have as member LSPs at 
minimum. 


Default: 64 


minimum-signaling-bandwidth bandwidth—Amount of bandwidth in bits per second (bps) that can be 
signaled for an LSP at minimum after normalization. When minimum-signaling-bandwidth is not 
configured, the value is derived from the merging-bandwidth. 


When auto-bandwidth adjustment is done between two normalization events, per LSP auto-bandwidth 
configuration and thresholds are used instead of the merging-bandwidth. 
Default: 1 bps 


splitting-bandwidth bandwidth—Amount of bandwidth in bits per second (bps) that can be used for splitting 
during normalization. 


Default: 1 bps 


splitting-merging-threshold percent—Percentage changes in aggregate bandwidth relevant for splitting 
and merging. 


Default: 0% 
The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


container-label-switched-path | 1743 
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| spring-te (Dynamic Tunnels) 
Syntax 


spring-te { 
destination-networks name; 
source-routing-path-template name { 
(color [ color ... ] | color-any); 


Hierarchy Level 


[edit routing-options dynamic-tunnels], 


Release Information 
Statement introduced in Junos OS Release 19.2R1 on all platforms. 


Description 


Enable next hop-base dynamic tunnel mode. 


Options 
source-routing-path-template template-name—Configure template color mapping for segment routing 
traffic-engineered (SPRING-TE) dynamic LSP parameters. 


color—Specify set of color list to be mapped to corresponding SPRING-TE template. 


e When enabled, all templates should have color objects defined. 
e All destinations are assumed to be colored as well. 
e Acolor can be mapped to only one template at a given point in time. 


e Both the color and color-any statements can coexist. When the two statements are enabled together, 
preference is given to a specific color template than color-any. 


e Acolored and non-colored destination cannot co-exist in the same SR-TE configuration. 


color-any—Enables mapping of any color to corresponding SPRING-TE template. Only one color-any 
template can be configured for one SR-TE LSP. 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


| Understanding Static Segment Routing LSP in MPLS Networks | 711 


srgb-label-range 
Syntax 


srgb-label-range <range-start> <range-end> 


Hierarchy Level 


[edit protocols mpls label-range], 
[edit protocols ospf source-packet-routing srgb] 


Release Information 
Statement introduced in Junos OS Release 19.1 for MX Series routers. 


Description 

SRGB configured under mpls label-range is termed as global SRGB. The MPLS label range is based on the 
start range and the end range. The value of the start range indicates the start of the label range, and the 
value of the end range along with the value of the start range indicate the end of the label range. 


Options 


<range-start> <range-end>—Start range and end range of the global SRGB label block. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


source-packet-routing 
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| srlg 


Syntax 


srlg { 
srig-name { 
srlg-cost srlg-cost; 
srlg-value srlg-value; 


} 


Hierarchy Level 


[edit routing-options], 
[edit logical-systems logical-system-name routing-options] 
[edit protocols mpls interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 11.4. 
Statement introduced in Junos OS Release 12.3 for ACX Series routers. 


Description 


Configure Shared Risk Link Group (SRLG) parameters. 


Options 
srlg-cost srlg-cost—Specify a cost for the SRLG ranging from 1 through 65535. 


srlg-value srlg-value—Specify a Group ID for the SRLG ranging from 1 through 4294967295. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring SRLG | 201 
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| srlg-cost 


Syntax 


srlg-cost srlg-cost; 


Hierarchy Level 


[edit routing-options srlg], 
[edit logical-systems logical-system-name routing-options srlg] 


Release Information 
Statement introduced in Junos OS Release 11.4. 
Statement introduced in Junos OS Release 12.3 for ACX Series routers. 


Description 
Specify a cost for the Shared Risk Link Group (SRLG) ranging from 1 through 65535. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring SRLG | 201 
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| srlg-value 


Syntax 


srlg-value srlg-value; 


Hierarchy Level 


[edit routing-options srlg], 
[edit logical-systems logical-system-name routing-options srlg] 


Release Information 
Statement introduced in Junos OS Release 11.4. 
Statement introduced in Junos OS Release 12.3 for ACX Series routers. 


Description 
Specify a Group ID for the Shared Risk Link Group (SRLG) ranging from 1 through 4294967295. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring SRLG | 201 
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| standby 


Syntax 


standby; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 


[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Enable the path to remain up at all times to provide instant switchover if connectivity problems occur. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Hot Standby of Secondary Paths for LSPs | 573 
Configuring Path Protection in an MPLS Network (CLI Procedure) | 280 
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| standby 


Syntax 


standby; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 


[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for QFX Virtual Chassis and Virtual Chassis 
Fabric. 


Description 


Have the path remain up at all times to provide instant switchover if connectivity problems occur. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Hot Standby of Secondary Paths for LSPs | 573 


| static-label-switched-path 


Syntax 


static-label-switched-path Isp-name { 


bypass bypass-name { 


} 


bandwidth bps; 

description string; 

next-hop (address | interface-name | address/interface-name); 
push out-label; 

to address; 


ingress { 


} 


bandwidth bps; 
class-of-service cos-value; 
description string; 
install { 
destination-prefix <active>; 
} 
link-protection bypass-name name; 
metric metric; 
next-hop (address | interface-name | address/interface-name); 
node-protection bypass-name name next-next-label label; 
no-install-to-address; 
policing { 
filter filter-name; 
no-auto-policing; 
} 
preference preference; 
push out-label; 
to address; 


transit incoming-label { 


bandwidth bps; 

description string; 

link-protection bypass-name name; 

next-hop (address | interface-name | address/interface-name); 
node-protection bypass-name name next-next-label label; 
pop, 

swap out-label; 


Hierarchy Level 
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[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 
Statement introduced in Junos OS Release 10.1. 


Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Statement introduced in 19.4R1 for cRPD instances. 


Description 


Configure a static LSP. 


Options 


Isp-name—Name of the path. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Static LSPs | 574 
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| statistics (Protocols MPLS) 


Syntax 


statistics { 
auto-bandwidth (MPLS Statistics); 
file filename <files number> <size size> <world-readable | no-world-readable>; 
interval seconds; 
no-transit-statistics; 
traffic-class-statistics; 
transit-statistics-polling; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 
traffic-class-statistics option introduced in Junos OS Release 14.2. 

Statement introduced in Junos OS Release 17.2R1 for QFX10000 Series switches. 


Description 


Enable MPLS statistics collection and reporting. 


Options 
file filename—(Optional) Name of the file to receive the output. We recommend that you place MPLS 
tracing output in the file mpls-stat in the /var/log directory. 


files number—(Optional) Maximum number of trace files. When a trace file named file reaches its maximum 
size, it is renamed file.O, then file.1, and so on, until the maximum number of files is reached. Then, the 
oldest file is overwritten. 


Range: 2 or more 
Default: 2 files 


If you specify a maximum number of files, you also must specify a maximum file size with the size option. 


interval seconds—Interval at which to periodically collect statistics. 
Range: 1 through 65,535 
Default: 300 seconds 


no-world-readable—(Optional) Prevent users from reading the log file. 
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size size—(Optional) Maximum size of each file, in kilobytes (KB), megabytes (MB), or gigabytes (GB). When 
a file named file reaches this size, it is renamed file.O. When the file again reaches its maximum size, file.O 
is renamed file.1 and file is renamed file.O. This renaming scheme continues until the maximum number of 
files is reached. Then the oldest trace file is overwritten. 


If you specify a maximum file size, you also must specify a maximum number of files with the files option. 


world-readable—(Optional) Enable users to read the log file. 
Syntax: Syntax: xk to specify KB, xm to specify MB, or xg to specify GB 
Range: 10 KB through the maximum file size supported on your system 
Default: 1 MB 


traffic-class-statistics—(Optional) Create counters that maintain data traffic statistics per traffic class at 
the ingress of all types of LSPs and egress of ultimate hop popping (UHP) point-to-point LSPs. These 
counters are not created by default and are required to be configured to perform traffic-class-scoped loss 
measurement. 


transit-statistics-polling—(Optional) Enable the polling and display of MPLS statistics for LSPs transiting 
the router. By default, RSVP does not periodically poll for transit LSP statistics. You cannot configure this 
statement and the no-transit-statistics statement at the same time. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing and trace—To view this statement in the configuration. 
routing-control and trace-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring MPLS to Gather Statistics | 387 
Configuring Automatic Bandwidth Allocation for LSPs | 517 
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| swap 


Syntax 


swap out-label; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name transit incoming-label], 
[edit protocols mpls static-label-switched-path Isp-name transit incoming-label] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Remove the label at the top of the label stack and replace it with the specified label. Manually assigned 
incoming labels can have values from 1,000,000 through 1,048,575. This statement is used to configure 
static LSPs at transit routers. 


Options 
out-label—Manually assigned outgoing label value. 
Range: O through 1,048,575 


Default: If you do not define the out-label option, the original label value remains unchanged. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


pop | 1905 
push | 1913 
Configuring the Intermediate (Transit) and Egress Routers for Static LSPs | 578 


1967 


| switch-away-lsps 
Syntax 


switch-away-lsps; 


Hierarchy Level 


[edit logical-systems logical-systems-name protocols mpls interface interface-name], 
[edit protocols mpls interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 10.2. 


Description 

(MX Series routers only) Enable you to switch an LSP away from a network node using a bypass LSP. This 
feature could be used in maintenance of active networks when a network device needs to be replaced 
without interrupting traffic passing through the network. The LSPs can be either static or dynamic. Configure 
this statement only after you have configured and committed the always-mark-connection-protection-tlv 
statement. 


The always-mark-connection-protection-tlv statement marks all OAM traffic transiting this interface in 
preparation for switching the traffic to an alternate path based on the OAM functionality. When you 
configure the switch-away-lsps statement, traffic is switched to the bypass LSP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Switching LSPs Away from a Network Node | 804 


1968 


| switching-type 
Syntax 


switching-type (fiber | lambda | psc-1 | tdm); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name Isp-attributes], 
[edit protocols mpls label-switched-path Isp-name Isp-attributes] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify the switching method for the LSP. The switching method can be one of the following values: 


e fiber—Fiber switching 
e lambda—Lambda switching 
e psc-1—Packet switching 


e tdm—Time-division multiplexing (TDM) switching 
Default 
psc-1 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring MPLS LSPs for GMPLS | 1264 


1969 


| sync-active-path-bandwidth 
Syntax 


sync-active-path-bandwidth; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mplslabel-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name auto-bandwidth], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name auto-bandwidth], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name] 


Release Information 
Statement introduced in Junos OS Release 13.2. 


Description 

When you have a primary and a secondary path configuration, specify that a path needs to be signaled 
with the active-path bandwidth when the auto-bandwidth adjustment happens and that the secondary 
path synchronizes the bandwidth reservations to that of the primary path. 


When a primary path fails, bandwidth reservations are made by the secondary path on the links that it 
uses. If you include the sync-active-path-bandwidth statement, the secondary path releases the bandwidth 
it has reserved and adjusts its bandwidth after the primary path begins carrying traffic. 


For example, suppose the active path is a secondary path with a reserved bandwidth of 10 GB as a result 
of the automatic bandwidth adjustment. Then suppose there is a switchover from the secondary path to 
the primary path. After some time the primary path reserves 5 GB as a result of a new automatic adjustment. 
Without the sync-active-path-bandwidth statement, the secondary path does not release the 10 GB after 
a switchover occurs. That bandwidth is wasted. If the sync-active-path-bandwidth is included in the 
configuration, the secondary path adjusts its bandwidth to 5 GB along with the primary path. 


Default 

When you have a primary and a secondary path configuration, and the primary path fails, bandwidth 
reservations are made by the secondary path on the links that it uses. When the primary path comes back 
and the traffic switches over, the secondary path does not release its bandwidth reservations. 


Required Privilege Level 
routing—To view this statement in the configuration. 
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routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Disabling Constrained-Path LSP Computation | 483 
Configuring Explicit-Path LSPs | 564 


1971 


| te-class-matrix 


Syntax 


te-class-matrix { 
tenumber { 
priority priority; 
traffic-class { 
ctnumber priority priority; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls diffserv-te], 
[edit protocols mpls diffserv-te] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify the traffic engineering class matrix for a multiclass LSP or a DiffServ-aware traffic engineering LSP. 


Default 


The default traffic engineering class matrix is: 


te-class-matrix { 
teO traffic-class ctO priority 7; 
te1 traffic-class ct1 priority 7; 
te2 traffic-class ct2 priority 7; 
te3 traffic-class ct3 priority 7; 
te4 traffic-class ctO priority O; 
te5 traffic-class ct1 priority O; 
teé traffic-class ct2 priority O; 
te7 traffic-class ct3 priority O; 


If you define any of the traffic engineering classes, all the default values are dropped. 


Options 


ctnumber—Specify the number of the class type. It can be one of four values: ctO, ct1, ct2, or ct3. 
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priority priority—Specify the priority of the class type. It can be one of eight values from O through 7. 


tenumber—Specify the number of the traffic engineering class. It can be one of eight values: teO, te1, te2, 
te3, te4, te5, te6, or te7. You must configure the traffic engineering classes in order, starting with teO. 


traffic-class—Specify the traffic class for the traffic engineering class. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Traffic Engineering Classes | 1124 


1973 


| to 
Syntax 


to address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name bypass], 
[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name ingress], 
[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls static-label-switched-path Isp-name bypass], 

[edit protocols mpls static-label-switched-path Isp-name ingress] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 

Support for IPv6 addresses in static LSP configurations are provided in Junos OS Release 17.2R1. 


Description 


Specify the egress router of a dynamic LSP. 


Options 


address—|Pv4 or IPv6 address of the egress router. 


NOTE: IPv6 static LSPs are not supported at the [edit protocols mpls static-label-switched-path 
Isp-name ingress] hierarchy level. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Egress Router Address for LSPs | 486 


1974 


| traceoptions (Protocols MPLS) 


Syntax 


traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 
ted-export option introduced in Junos OS Release 14.2. 

ted-import option introduced in Junos OS Release 14.2. 

Isp-history option added in Junos OS Release 15.1. 


Description 


Configure MPLS tracing options at the protocol level or for a label-switched path. 


To specify more than one tracing operation, include multiple flag statements. 


Default 


The default MPLS protocol-level tracing options are inherited from the routing protocols traceoptions 
statement included at the [edit routing-options] hierarchy level. 


Options 
filename—Name of the file to receive the output of the tracing operation. All files are placed in the directory 
/var/log. We recommend that you place MPLS tracing output in the file mpls-log. 


files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its 
maximum size, it is renamed trace-file.0, then trace-file.1, and so on, until the maximum number of trace 
files is reached. Then the oldest trace file is overwritten. 

Range: 2 through 1000 

Default: 2 files 


If you specify a maximum number of files, you must also include the size statement to specify the maximum 
file size. 


flag—Tracing operation to perform. To specify more than one tracing operation, include multiple flag 


statements. 


MPLS Tracing Flags 


no-world-readable—(Optional) Allow only certain users to read the log file. 


size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB), or gigabytes (GB). 
When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again 
reaches this size, trace-file.O is renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming 
scheme continues until the maximum number of trace files is reached. Then the oldest trace file is 


all—Trace all operations 

autobw-state—Automatic bandwidth events. 
connection—All circuit cross-connect (CCC) activity 
connection-detail—Detailed CCC activity 

cspf—CSPF computations 

cspf-link—Links visited during CSPF computations 
cspf-node—Nodes visited during CSPF computations 
error—MPLS error packets 

graceful-restart—Trace MPLS graceful restart events 
Isp-history—Trace LSP history events 

Isping—Trace Isping packets and return codes 
nsr-synchronization—Trace NSR synchronization events 
nsr-synchronization-detail—Trace NSR synchronization events in detail 
state—All LSP state transitions 


static—Trace static label-switched path 


ted-export—Trace leaking of entries from Isdist.0 table into the traffic engineering database 


ted-import—Trace leaking traffic engineering database entries into the Isdist.0 table 


timer—Timer usage 


overwritten. 


Syntax: xk to specify KB, xm to specify MB, or xg to specify GB 


Range: 10 KB through the maximum file size supported on your system 
Default: 1. MB 


If you specify a maximum file size, you must also include the files statement to specify the maximum 


number of files. 
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world-readable—(Optional) Allow any user to read the log file. 


Required Privilege Level 
routing and trace—To view this statement in the configuration. 


routing-control and trace-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Tracing MPLS and LSP Packets and Operations | 1149 


1976 


| traffic-class (delay) 


Syntax 


traffic-class tc-value { 
average-sample-size sample size; 
padding-size size; 
query-interval milliseconds; 
rtt-delay-threshold rtt threshold value; 
twcd-delay-threshold twcd threshold value; 


Hierarchy Level 


[edit protocols mpls oam performance-monitoring querier delay], 

[edit protocols mpls label-switched-path Isp-name oam performance-monitoring querier delay], 

[edit protocols mpls label-switched-path Isp-name primary path-name oam performance-monitoring querier delay], 

[edit protocols mpls label-switched-path Isp-name secondary path-name oam performance-monitoring querier 
delay] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Configure traffic class specific options. 


Specify the traffic classes for which loss measurement has to be performed. This parameter takes one of 
the tc-all|tc-O|tc-1|tc-2|tc-3|tc-4|tc-5|tc-6|tc- 7|tc-none traffic-class values. For each traffic class, you can 
configure the respective parameters. 


To enable traffic-class parameters, configure the traffic-class-statistics configuration statement under the 
[edit protocol mpls statistic] hierarchy level. 


Options 
average-sample-size sample size—(Optional) Specify the number of samples used for calculating the average 
of various metrics. 
Default: 5 
Range: 1 through 30 


padding-size size—(Optional) Specify the delay-measurement message length, which is used to calculate 
the delay experienced by messages of different sizes. 


Default: O 
Range: 1 through 1500 
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query-interval milliseconds—Specify the minimum transmit interval, which signifies how often the loss 
measurement message is generated from the querier. 


Default: 10 seconds 
Range: 1000 through 4294967295 milliseconds 


rtt-delay-threshold rtt threshold value—Specify the round-trip delay threshold value. 
Range: 1 through 4294967295 microseconds 


twcd-delay-threshold twcd threshold value—Specify the two-way channel delay threshold value. 
Range: 1 through 4294967295 microseconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Pro-Active Loss and Delay Measurements | 417 
On-Demand Packet Loss and Delay Measurement for UHP LSPs Overview | 388 
performance-monitoring (Protocols MPLS) | 1893 


1979 


| traffic-class (loss) 


Syntax 


traffic-class tc-value { 
average-sample-size sample size; 
loss-threshold loss threshold value; 
loss-threshold-window number of samples for loss threshold; 
measurement-quantity bytes|packets; 
query-interval milliseconds; 


Hierarchy Level 


[edit protocols mpls oam performance-monitoring querier loss], 

[edit protocols mpls label-switched-path Isp-name oam performance-monitoring querier loss], 

[edit protocols mpls label-switched-path Isp-name primary path-name oam performance-monitoring querier loss], 
[edit protocols mpls label-switched-path Isp-name secondary path-name oam performance-monitoring querier loss] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Configure traffic class specific options. 


Specify the traffic classes for which loss measurement has to be performed. This parameter takes one of 
the tc-all|tc-O|tc-1|tc-2|tc-3|tc-4|tc-5|tc-6|tc- 7|tc-none traffic-class values. For each traffic class, you can 
configure the respective parameters. 


To enable traffic-class parameters, configure the traffic-class-statistics configuration statement under the 
[edit protocol mpls statistic] hierarchy level. 


Options 
average-sample-size sample size—(Optional) Specify the number of samples used for calculating the average 
of various metrics. 
Default: 5 
Range: 1 through 30 


loss-threshold loss threshold value—Specify the threshold value that will be used with loss-threshold-window 
to calculate the loss within specified window size. 


Range: 1 through 4294967295 


loss-threshold-window number of samples for loss threshold—Specify the number of samples used for loss 
threshold calculation. 
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Range: 1 through 30 


measurement-quantity bytes|packets—(Optional) Specify whether packet or byte loss is being measured 
at the querier. 


Default: packets 


query-interval milliseconds—Specify the minimum transmit interval, which signifies how often the loss 
measurement message is generated from the querier. 


Default: 10 seconds 
Range: 1000 through 4294967295 milliseconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Pro-Active Loss and Delay Measurements | 417 
On-Demand Packet Loss and Delay Measurement for UHP LSPs Overview | 388 
performance-monitoring (Protocols MPLS) | 1893 


1981 


| traffic-class (loss-delay) 


Syntax 


traffic-class tc-value { 
average-sample-size sample size; 
loss-threshold loss threshold value; 
loss-threshold-window number of samples for loss threshold; 
measurement-quantity bytes|packets; 
padding-size size; 
query-interval milliseconds; 
rtt-delay-threshold rtt threshold value; 
twcd-delay-threshold twcd threshold value; 


Hierarchy Level 


[edit protocols mpls oam performance-monitoring querier loss-delay], 
[edit protocols mpls label-switched-path Isp-name oam performance-monitoring querier loss-delay], 
[edit protocols mpls label-switched-path Isp-name primary path-name oam performance-monitoring querier 


loss-delay], 
[edit protocols mpls label-switched-path Isp-name secondary path-name oam performance-monitoring querier 
loss-delay] 


Release Information 
Statement introduced in Junos OS Release 15.1. 


Description 


Configure traffic class specific options. 


Specify the traffic classes for which loss measurement has to be performed. This parameter takes one of 
the tc-all|tc-O|tc-1|tc-2|tc-3|tc-4|tc-5|tc-6|tc- 7|tc-none traffic-class values. For each traffic class, you can 
configure the respective parameters. 


To enable traffic-class parameters, configure the traffic-class-statistics configuration statement under the 
[edit protocol mpls statistic] hierarchy level. 


Options 
average-sample-size sample size—(Optional) Specify the number of samples used for calculating the average 
of various metrics. 
Default: 5 
Range: 1 through 30 
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loss-threshold loss threshold value—Specify the threshold value that will be used with loss-threshold-window 
to calculate loss within specified window size. 


Range: 1 through 4294967295 


loss-threshold-window number of samples for loss threshold—Specify the number of samples used for loss 
threshold calculation. 


Range: 1 through 30 


measurement-quantity bytes|packets—(Optional) Specify whether packet or byte loss is being measured 
at the querier. 


Default: packets 


padding-size size—(Optional) Specify the delay-measurement message length, which is used to calculate 
the delay experienced by messages of different sizes. 


Default: O 
Range: 1 through 1500 


query-interval milliseconds—Specify the minimum transmit interval, which signifies how often the loss 
measurement message is generated from the querier. 


Default: 10 seconds 
Range: 1000 through 4294967295 milliseconds 


rtt-delay-threshold rtt threshold value—Specify the round-trip delay threshold value. 
Range: 1 through 4294967295 microseconds 


twcd-delay-threshold twcd threshold value—Specify the two-way channel delay threshold value. 
Range: 1 through 4294967295 microseconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Pro-Active Loss and Delay Measurements | 417 
On-Demand Packet Loss and Delay Measurement for UHP LSPs Overview | 388 
performance-monitoring (Protocols MPLS) | 1893 
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| traffic-engineering (Protocols MPLS) 


Syntax 


traffic-engineering (bgp | bgp-igp | bgp-igp-both-ribs | mpls-forwarding); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 12.1 for EX Series switches. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Select whether MPLS performs traffic engineering on BGP destinations only or on both BGP and IGP 
destinations. Affects only LSPs originating from this routing device, not transit or egress LSPs. 


Default 
bgp 


Options 


bgp—On BGP destinations only. Ingress routes are installed in the inet.3 routing table. 


bgp-igp—On both BGP and IGP destinations. Ingress routes are installed in the inet.O routing table. If IGP 
shortcuts are enabled, the shortcut routes are automatically installed in the inet.O routing table. 


bgp-igp-both-ribs—On both BGP and IGP destinations. Ingress routes are installed in the inet.O and inet.3 
routing tables. This option is used to support VPNs. 


mpls-forwarding—On both BGP and IGP destinations. Use ingress routes for forwarding only, not for 
routing. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Traffic Engineering for LSPs | 1065 
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Configuring MPLS on Provider Edge Switches Using IP-Over-MPLS | 68 
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| traffic-engineering 
Syntax 


traffic-engineering { 
disable; 


Hierarchy Level 


[edit protocols ospf | isis] 


Release Information 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Enable the traffic engineering features of the specified routing protocol. 


Default 


Traffic engineering is disabled. 


Starting in Junos OS release 15.1, traffic engineering is enabled by default whenever the IS-IS protocol is 
enabled. You can disable it by including the disable statement at the [edit protocols isis traffic-engineering] 
hierarchy level. For the EX3300, EX4200, EX4500, EX4550, EX8200 and XRE200, you can disable traffic 
engineering starting in Junos OS release 15.1R7. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring MPLS on EX8200 and EX4500 Switches | 42 

Configuring MPLS on Provider Edge EX8200 and EX4500 Switches Using Circuit Cross-Connect | 74 
Configuring MPLS on Provider Edge Switches Using IP-Over-MPLS | 68 

Configuring MPLS on EX8200 and EX4500 Provider Switches | 78 

Configuring an OSPF Network (J-Web Procedure) 

MPLS Applications User Guide 
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| traffic-engineering (Protocols BGP) 


Syntax 


traffic-engineering { 
unicast; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols bgp family], 

[edit logical-systems logical-system-name protocols bgp group group-name family], 

[edit logical-systems logical-system-name protocols bgp group group-name neighbor address family], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp family], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name 
family], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name 
neighbor address family], 

[edit protocols bgp family], 

[edit protocols bgp group group-name family], 

[edit protocols bgp group group-name neighbor address family], 

[edit routing-instances routing-instance-name protocols bgp family], 

[edit routing-instances routing-instance-name protocols bgp group group-name family], 

[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address family] 


Release Information 

Statement introduced in Junos OS Release 14.2. 

Statement introduced on QFX5100 switches in Junos OS Release 15.1 
Statement introduced on QFX10000 switches in Junos OS Release 17.1. 


Description 
Enable traffic engineering address family. This generates a multiprotocol address family indicator (AFI) and 
a subsequent address family identifier (SAFI) to be negotiated with the BGP peers. 


The BGP network layer reachability information (NLRI) information is exchanged between the peers only 
when the traffic engineering AFl and SAFI are shared between them. If the peers do not agree on the use 
of the AFI and SAFI, the connection between the peers is terminated. 


Options 
unicast—Include BGP-TE NLRI. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Example: Configuring Link State Distribution Using BGP | 1089 


1988 


| transit-Ilsp-association 


Syntax 


transit-Isp-association transit-association-Isp-group-name { 
from-1 address-of-associated-Isp-1; 
from-2 address-of-associated-Isp-2; 
Isp-name-1 name-of-associated-Isp-1; 
Isp-name-2 name-of-associated-Isp-2; 


Hierarchy Level 


[edit protocols mpls] 


Release Information 
Statement introduced in Junos OS Release 12.1. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Associate two label-swiched paths (LSPs) at a transit node to configure a path for sending and receiving 
GAL and G-Ach messages for MPLS-TP OAM. 


Options 


transit-association-Isp-group-name—Name of the transit association LSP group. 
from-1 address-of-associated-Isp-1—Address of the first associated LSP. 
from-2 address-of-associated-Isp-2—Address of the second associated LSP. 
Isp-name-1 name-of-associated-Isp-1—Name of the first associated LSP. 


Isp-name-2 name-of-associated-Isp-1—Name of the second associated LSP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring the MPLS Transport Profile for OAM | 1132 
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ultimate-hop-popping 
Syntax 


ultimate-hop-popping; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path label-switched-path-name], 
[edit protocols mpls], 

[edit protocols mpls label-switched-path label-switched-path-name] 


Release Information 
Statement introduced in Junos OS Release 12.3. 
Statement introduced in Junos OS Release 13.2 for PTX Series Packet Transport Routers. 


Description 

Enable ultimate-hop popping on LSPs. Configure this statement on the device at the LSP ingress. In 
ultimate-hop popping, the MPLS label is popped from the IP packet at the PE router. The IP address is 
checked in a second address lookup (also at the PE router), and then the packet is forwarded to its 
destination. 


Be aware of the following platform requirements and restrictions: 


e UHP LSPs using VT interfaces—Supported on all M Series, MX Series, T Series, and TX Matrix routers. 
e UHP LSPs using LSI interfaces—Supported on MX 3D Series routers only. 


e UHP LSP requirements for the egress PE device—For M Series and T Series routers, a VT interface is 
needed. 


e UHP LSPs and Layer 3 VPNs—UHP LSPs are supported for Layer 3 VPNs configured on MX 3D Series 
routers only. 


e UHP LSPs and VPLS—UHP LSPs are supported for VPLS configured on MX 3D Series routers only. You 
must configure the no-tunnel-services statement at the [edit routing-instances routing-instance-name 
protocols vpls] hierarchy level. 


Default 

Ultimate-hop popping is disabled by default on LSPs. Penultimate-hop popping is the default behavior. In 
penultimate-hop popping, the final MPLS label is popped from the IP packet at the last provider router in 
the network before being forwarded to the PE router. The PE router receives the packet and checks the 
IP address, and then the packet is forwarded to its destination. 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Ultimate-Hop Popping for LSPs | 560 
explicit-null | 1775 
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vrf-table-label 


Syntax 


vrf-table-label { 
source-class-usage; 
static; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name], 
[edit routing-instances routing-instance-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Support for the source-class-usage statement added in Junos OS Release 9.3. 

Statement introduced in Junos OS Release 11.1 for EX Series switches. 

Statement introduced in Junos OS Release 12.3 for ACX Series routers. 

Statement introduced in Junos OS Release 15.1F5 and 16.1R2 for PTX5000 routers with third-generation 
FPCs installed. 

Statement introduced in Junos OS Release 15.1F6 and 16.1R2 for PTX3000 routers with third-generation 
FPCs. 

Statement introduced in Junos OS Release 16.1X65 and 17.2R1 for PTX1000 routers. 

Statement introduced in cRPD Release 19.4R1. 

Support for the static statement added in Junos OS Release 17.2. 


Description 

Map the inner label of a packet to a specific VPN routing and forwarding (VRF) instance. This allows the 
examination of the encapsulated IP header. The first lookup is done on the VPN label to determine which 
VRF instance to refer to, and the second lookup is done on the IP header to determine how to forward 
packets to the correct end hosts. 


When you include the vrf-table-label statement in the configuration of a VRF routing instance, a 
label-switched interface (LSI) logical interface label is created and mapped to the VRF routing table. Any 
routes in the VRF routing table are advertised with the LSI logical interface label allocated for the VRF 
routing table. When packets destined for the VRF routing instance arrive on a core-facing interface, they 
are treated as if the enclosed IP packet arrived on the LSI interface and are then forwarded and filtered 
based on the correct table. 


All routes ina VRF routing instance configured with this option are advertised with one label allocated per 
VRF. 


1992 


NOTE: 

e The vrf-table-label statement is supported on PTX5000 and PTX3000 routers only when 
third-generation FPCs are installed on the router and enhanced-ip command is configured on 
the chassis. 


e Starting in Junos OS Release 17.2, you can configure the enhanced-ip command, which is 
supported on platforms using Modular Port Concentrators (MPCs) equipped with Junos Trio 
chipsets. You can also separate the MPLS labels used for different label spaces which provides 
more flexibility and scalability. The vrf-table-label space is increased to at least 16,000, if the 
platform can support the scale. 


Options 
The remaining statements are explained separately. 
Range: 16 through 1,048,575 for static label value. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Filtering Packets in Layer 3 VPNs Based on IP Headers 
Configuring EXP-Based Traffic Classification for VPLS 
Load Balancing and IP Header Filtering for Layer 3 VPNs 
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RSVP Configuration Statements 
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1995 


| admin-group 
Syntax 


admin-group { 
exclude [ group-names ]; 
include-all [ group-names ]; 
include-any [ group-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name], 
[edit protocols rsvp interface interface-name link-protection], 

[edit protocols rsvp interface interface-name link-protection bypass bypass-name] 


Release Information 
Statement introduced in Junos OS Release 9.2. 


Description 
Enable you to configure administrative groups for bypass label-switched paths (LSPs). You can configure 


administrative groups either globally for all bypass LSPs traversing an interface or for just a specific bypass 
LSP. 


Options 


exclude group-names—Specify the administrative groups to exclude for a bypass LSP. 
include-all group-names—Specify the administrative groups whose links the bypass LSP must traverse. 


include-any group-names—Specify the administrative groups whose links the bypass LSP can traverse. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Administrative Groups for Bypass LSPs | 379 
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| aggregate (Protocols RSVP) 


Syntax 


(aggregate | no-aggregate); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp peer-interface peer-interface-name], 
[edit protocols rsvp peer-interface peer-interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Control the use of RSVP aggregate messages on an interface or peer interface, as described below. 


NOTE: Starting in Junos OS Release 15.2, the aggregate statement is deprecated at the [edit 
protocols rsvp interface interface-name] and [edit logical-systems logical-system-name protocols 
rsvp interface interface-name] hierarchy levels, as RSVP message aggregation is enabled by 
default. 


e aggregate—Use RSVP aggregate messages. 
e no-aggregate—Do not use RSVP aggregate messages. 


Aggregate messages can pack multiple RSVP messages into a single transmission, thereby reducing 
network overhead and enhancing efficiency. The number of supportable sessions and processing overhead 
are significantly improved when aggregation is enabled. 


Not all routers connected to a subnet need to support aggregation simultaneously. Each RSVP router 
negotiates its intention to use aggregate messages on a per-neighbor basis. Only when both routers 
agree are aggregate messages sent. 


To have refresh reduction and reliable delivery, you must include the aggregate and reliable statements. 


Default 
Aggregation is enabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


RSVP Refresh Reduction | 781 
Configuring RSVP Refresh Reduction | 788 
reliable | 2051 


1998 


| authentication-key (Protocols RSVP) 


Syntax 


authentication-key key; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-namel], 

[edit logical-systems logical-system-name protocols rsvp peer-interface peer-interface-name], 
[edit protocols rsvp], 

[edit protocols rsvp interface interface-name], 

[edit protocols rsvp peer-interface peer-interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Authentication key (password). Neighboring routers use the password to verify the authenticity of packets 
sent from this interface or peer interface. To authenticate node hellos or remote messages between the 
Point of Local Repair (PLR) to the Merge Point (MP), enable authentication-key at the [edit protocols 
rsvp] hierarchy level. 


It is recommended to use the authentication-key configuration at the [edit protocols rsvp] hierarchy level 
for the RSVP node-neighbor. Because non-RSVP interfaces do not have RSVP authentication key, the 
authentication-key configuration allows the packets to arrive at any interface regardless of RSVP interfaces 
configuration being enabled or not. 


RSVP uses HMAC-MD5 authentication, which is defined in RFC 2104, HMAC: Keyed-Hashing for Message 
Authentication. 


All routers that are connected to the same IP subnet must use the same authentication scheme and 
password. 


Options 

key—Authentication password. It can be 1 through 16 contiguous digits or letters. Separate decimal digits 
with periods. Separate hexadecimal digits with periods and precede the string with Ox. If you include spaces 
in the password, enclose the entire password in quotation marks (""). 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Configuring RSVP Authentication | 791 


2000 


| bandwidth (Protocols RSVP) 


Syntax 


bandwidth bps; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-namel], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name], 
[edit protocols rsvp interface interface-name], 

[edit protocols rsvp interface interface-name link-protection], 

[edit protocols rsvp interface interface-name link-protection bypass bypass-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

For certain logical interfaces (such as Asynchronous Transfer Mode [ATM], Permanent Virtual Circuit 
[PVC], or Frame Relay), you cannot determine the correct bandwidth from the hardware. This statement 
enables you to specify the actual available bandwidth. 


This statement also enables you to specify the bandwidth for a bypass label switched path (LSP). If you 
have configured multiple bypasses, this statement is mandatory and is applied to all of the bypass LSPs. 


Default 


The hardware raw bandwidth is used. 


Options 

bps—Bandwidth in bits per second. You can specify this as an integer value. If you do so, count your zeros 
carefully, or you can use the abbreviations k (for a thousand), m (for a million), or g (for a billion [also called 
a thousand million)). 


Range: Any positive integer 


Default: O (no bandwidth is reserved) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Configuring the Bandwidth for Bypass LSPs | 380 
Configuring Link Protection on Interfaces Used by LSPs | 377 
Configuring Bypass LSPs | 379 


2002 


| bypass (Signaled LSP) 
Syntax 


bypass bypass-name { 
bandwidth bps; 
description text; 
hop-limit number; 
no-cspf; 
path address <strict | loose>; 
priority setup-priority reservation-priority; 
subscription subscription-percentage; 
to address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 
[edit protocols rsvp interface interface-name link-protection] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

description option was added in Junos OS Release 10.4. 

subscription subscription-percentage option introduced in Junos OS Release 19.2R1 on all platforms. 


Description 

Enables you to configure specific bandwidth and path constraints for a bypass LSP. It is possible to 
individually configure multiple bypass LSPs. If you do not configure the bypass LSPs individually, they all 
share the same path and bandwidth constraints. 


If you specify the bandwidth, hop-limit, and path statements for the bypass LSP, these values take 
precedence over the values configured at the [edit protocols rsvp interface interface-name link-protection] 
hierarchy level. The other attributes (subscription, no-node-protection, and optimize-timer) are inherited 
from the general constraints. 


Options 


bypass-name—(Required) Specify a name for the bypass LSP. The name can be up to 64 characters. 


description—Provides a textual description of the bypass LSP. Enclose any descriptive text that includes 
spaces in quotation marks (""). Any descriptive text you include is displayed in the output of the show 
mpls Isp bypass detail command and has no effect on the operation of the bypass LSP. The description 
text can be no more than 80 characters in length. 


2003 


subscription subscription-percentage—(Optional) Specify the subscription percentage per manual bypass 
LSP. The subscription percentage configured under a particular manual bypass LSP overrides the 
subscription percentage configured commonly for all manual bypass LSPs under an interface. 
Range: O through 65000 


to address—(Required) Specify the address for the interface of the immediate next-hop node (for link 
protection) or the next-next-hop node (for node-link protection). The address specified determines 
whether this is a link protection bypass or a node-link protection bypass. On multiaccess networks 
(for example, a LAN), this address is also used to specify which next-hop node is being protected. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Bypass LSPs | 379 


2004 


| bypass (Static LSP) 


Syntax 


bypass bypass-name { 
bandwidth bps; 
description string; 
next-hop (address | interface-name | address/interface-name); 
push out-label; 
to address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls static-label-switched-path Isp-name], 
[edit protocols mpls static-label-switched-path Isp-name] 


Release Information 
Statement introduced before Junos OS Release 10.1. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Configure specific bandwidth and path constraints for a bypass ingress LSP. It is possible to configure 
multiple bypass LSPs individually. If you do not, they all share the same path and bandwidth constraints. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Static LSPs | 574 


2005 


| chained-composite-next-hop 
Syntax 


chained-composite-next-hop { 
ingress; 
transit; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options forwarding-table], 
[edit routing-options forwarding-table] 


NOTE: The [edit logical-systems] hierarchy level is not supported on the QFX10000 switches. 


Release Information 

Statement introduced in Junos OS Release 12.1. 

Statement introduced in Junos OS Release 12.3 for ACX Series routers. 
Statement introduced in Junos OS Release 15.1 for QFX10000 Series switches. 


Description 


Allows you to configure the chained composite next hops for devices handling ingress or transit traffic in 
the network. 


Chained composite next hops help to facilitate the handling of large volumes of transit traffic in the core 
of large networks by allowing the router to process much larger volumes of routes. A chained composite 
next hop allows the router to direct sets of routes sharing the same destination to a common forwarding 
next hop, rather than having each route also include the destination. In the event that a network destination 
is changed, rather than having to update all of the routes sharing that destination with the new information, 
just the shared forwarding next hop is updated with the new information. The chained composite next 
hops continue to point to this forwarding next hop which now contains the new destination. 


On platforms containing only MPCs, such as PTX Series Packet Transport Routers, the MX80 router, the 
MX2020 router, and the QFX10000 switches, chained composite next hops are enabled by default. On 
MX Series 5G Universal Routing Platforms containing both DPC and MPC FPCs and on T4000 Core Routers 
containing MPC and FPCs, chained composite next hops are disabled by default and need to be explicitly 
configured. 


2006 


To explicitly configure chained composite next hops, include the enhanced-ip statement at the [edit chassis 
network-services] hierarchy level. However, take the following into consideration when enabling the 
enhanced-ip mode: 


e Non-service DPCs do not work with enhanced network services mode options. Only MPCs, MS-DPCs, 
and MS-MPCs provide support for the enhanced-ip configuration. 


e If you configure chained composite next hops on MX Series routers with both MPCs, and DPCs or DPCEs, 
the network services mode must be changed from enhanced-ip to ethernet for the DPC or DPCE to 
come online. 


You can verify the FPC status in such cases, using the show chassis fpc command output, where the 
DPCs and DPCEs are marked as FPC misconfiguration. 


NOTE: 
e When chained composite next hops are enabled on a device, the BGP connections are reset. 


e On MX Series routers with DPCs or DPCEs, only the I3vpn option is supported under the 
ingress configuration statement; all other configuration options and functionality are not 
supported. 


e The transit statement and the associated functionality is supported only on PTX Packet 
Transport Routers and QFX10000 switches. 


e On MX Series routers, removing the chained-composite-next-hop statement from a PE device 
configuration causes all IBGP sessions to be torn down and triggers the BGP session to flap 
as well. A similar change on a router configured as a route reflector does not have any effect, 
however. 


The following is a sample system log message that is generated to record such an event: 


Now ) 653162212670 host PET rpdlo94 li bopepeeremgmemcetlears5 995: 
NOTIFICATION sent to 10.0.100.2 (External AS 100): code 6 (Cease) subcode 











4 (Administratively Reset), Reason: Management session cleared BGP 


neighbor 


e Starting with Junos OS Release 17.2, you cannot configure chained-composite-next-hop 
ingress I3vpn extended-space on a logical system. 


The remaining statements are explained separately. See CLI Explorer. 


Default 
This statement is disabled by default. 


2007 


Options 
ingress—Enable or disable composite chained next hop for ingress traffic. 
transit—(PTX and QFX10000) Enable or disable composite chained next hop for transit traffic. Starting in 


Junos OS Release 14.1, the transit I3vpn statement is enabled by default on PTX Series Packet Transport 
Routers only. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Accepting Route Updates with Unique Inner VPN Labels in Layer 3 VPNs 

Chained Composite Next Hops for Transit Devices for VPNs 

Example: Configuring Chained Composite Next Hops for Direct PE-PE Connections in VPNs 
ingress 


transit (Chained Composite Next Hops) | 2475 





2008 


| class-of-service (Protocols RSVP) 


Syntax 


class-of-service cos-value; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name], 
[edit protocols rsvp interface interface-name link-protection], 

[edit protocols rsvp interface interface-name link-protection bypass bypass-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 

Class-of-service (CoS) value given to all packets in the bypass LSP. You can specify a single CoS value for 
all the bypass LSPs traversing an interface. You can also configure CoS values for specific bypass LSPs 
traversing an interface. 


The CoS value might affect the scheduling or queuing algorithm of traffic traveling along an LSP. 


Options 
cos-value—CoS value. A higher value typically corresponds to a higher level of service. 

Range: O through 7 

Default: If you do not specify a CoS value, the IP precedence bits from the packet's IP header are used as the 
packet’s CoS value. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Class of Service for Bypass LSPs | 381 


2009 


| destination-networks 


Syntax 


destination-networks prefix; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options dynamic-tunnels 
tunnel-name], 

[edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name rsvp-te entry], 

[edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name], 

[edit routing-instances routing-instance-name routing-options dynamic-tunnels tunnel-name], 

[edit routing-instances routing-instance-name routing-options dynamic-tunnels tunnel-name rsvp-te entry], 

[edit routing-options dynamic-tunnels tunnel-name], 

[edit routing-options dynamic-tunnels tunnel-name rsvp-te entry] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3 for ACX Series routers. 


Description 


Specify the IPv4 prefix range for the destination network. Only tunnels within the specified IPv4 prefix 
range can be created. 

Options 

prefix—Destination prefix of the network. 

Required Privilege Level 


routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring GRE Tunnels for Layer 3 VPNs 
Dynamic Tunnels Overview 


Configuring RSVP Automatic Mesh | 807 


2010 


| devices 


Syntax 


devices device-names; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced in Junos OS Release 8.1. 


Description 

Specifies one of the virtual tunnel (VT) interfaces to de-encapsulate the egress traffic for ultimate-hop 
popping on point-to-multipoint LSPs. If no device is specified, the selection process is performed 
automatically. 


Default 


The device selection process is performed automatically if no device is configured. Junos OS selects one 
of the available VT interfaces to de-encapsulate the egress traffic. 


Options 
device-names—Specify which VT interfaces are used to handle the RSVP traffic. 


Range: 0 to 8 devices 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Enabling Ultimate-Hop Popping on Point-to-Multipoint LSPs | 815 
Understanding Redundant Virtual Tunnel Interfaces in MBGP MVPNs 
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| disable (Protocols RSVP) 


Syntax 


disable; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 

[edit logical-systems logical-system-name protocols rsvp graceful-restart], 

[edit logical-systems logical-system-name protocols rsvp interface interface-namel], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 
[edit logical-systems logical-system-name protocols rsvp peer-interface peer-interface-name], 
[edit protocols rsvp], 

[edit protocols rsvp graceful-restart], 

[edit protocols rsvp interface interface-name], 

[edit protocols rsvp interface interface-name link-protection], 

[edit protocols rsvp peer-interface peer-interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Explicitly disable RSVP or RSVP graceful restart. Explicitly disable link protection on the specified interface. 


Default 


RSVP is enabled on interfaces and peer interfaces configured with the RSVP interface statement. RSVP 
graceful restart is enabled on the router. Link protection is disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Minimum RSVP Configuration | 785 
Configuring RSVP Graceful Restart | 822 
Configuring Link Protection on Interfaces Used by LSPs | 377 
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| dynamic-bidirectional-transport 


Syntax 


dynamic-bidirectional-transport { 
template template; 


} 


Hierarchy Level 


[edit protocols rsvp peer-interface peer-interface-name] 


Release Information 
Statement introduced in Junos OS Release 14.2. 


Description 


Enable the dynamic setup of associated bidirectional packet LSP for transporting non-packet Generalized 
Multiprotocol Label Switching (GMPLS) label-switched path (LSP). 


Options 


template template—Name of the template for the dynamic bidirectional packet LSP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


2013 


| fast-reroute (Protocols RSVP) 


Syntax 


fast-reroute optimize-timer seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement added in Junos OS Release 7.5. 
Statement introduced in Junos OS Release 14.1 for the QFX Series. 


Description 


Configure the optimize timer for fast reroute. The optimize timer triggers a periodic optimization process 
that recomputes the fast reroute detour LSPs to use network resources more efficiently. 


Options 

seconds—Specify the number of seconds between fast reroute detour LSP optimizations. 
Range: O through 65,535 seconds 
Default: O (disabled) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Optimization Interval for Fast Reroute Paths | 477 


2014 


| graceful-deletion-timeout 


Syntax 


graceful-deletion-timeout seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify the time, in seconds, before completing graceful deletion of signaling. 


Options 

seconds—Time before completing graceful deletion of signaling. 
Range: 1 through 300 seconds 
Default: 30 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Graceful Deletion Timeout Interval | 1268 


| graceful-restart (Protocols RSVP) 


Syntax 


graceful-restart { 
disable; 
helper-disable; 
maximum-helper-recovery-time seconds; 
maximum-helper-restart-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options], 
[edit protocols rsvp], 
[edit routing-options] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 
Configure graceful restart on the router. You must configure the graceful-restart statement at the [edit 
routing-options] hierarchy level to enable graceful restart on the router. 


Options 


disable—Disable graceful restart on the router or for RSVP. 


helper-disable—Disable RSVP graceful restart helper mode (this option is only available at the [edit protocols 
rsvp] hierarchy level). 


Default: Helper mode is enabled by default. 


maximum-helper-recovery-time seconds—The maximum length of time the router stores the state of 
neighboring routers when they undergo a graceful restart. The value applies to all neighboring routers, so 
it should be based on the time that the slowest RSVP neighbor requires for restart. 

Default: 180 seconds 

Range: 1 through 3600 seconds 


maximum-helper-restart-time seconds—The maximum length of time the router waits between when it 
discovers that a neighboring router has gone down and when it declares the neighbor down. This value is 
applied to all neighboring routers, so it should be based on the time that the slowest RSVP neighbor requires 
for restart. 

Default: 20 seconds 

Range: 1 through 1800 seconds 


2015 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| Configuring RSVP Graceful Restart | 822 


hello-acknowledgements 


Syntax 


hello-acknowledgements; 


Hierarchy Level 


[edit logical-systems logical-systems-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced in Junos OS Release 10.2. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Enable hello messages from nonsession neighbors to be acknowledged with a hello acknowledgment 
message. Once hello acknowledgments are enabled, the router continues to acknowledge hello messages 
from any nonsession RSVP neighbors unless the interface itself goes down or the configuration is changed 
by an administrator. 


Default 


Hello acknowledgments are disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Hello Acknowledgments for Nonsession RSVP Neighbors | 803 


2016 


2017 


| hello-interval (Protocols RSVP) 


Syntax 


hello-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-name], 

[edit logical-systems logical-system-name protocols rsvp peer-interface peer-interface-name], 
[edit protocols rsvp interface interface-name], 

[edit protocols rsvp peer-interface peer-interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Enable the sending of hello packets on the interface. 


Options 
seconds—Length of time between hello packets. A value of O disables the sending of hello packets on the 
interface. 

Range: 1 through 60 seconds 


Default: 9 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the RSVP Hello Interval | 790 


| hop-limit 
Syntax 


hop-limit number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name fast-reroute], 

[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name (primary | 
secondary) path-name], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name], 

[edit protocols mpls], 

[edit protocols mpls label-switched-path Isp-name], 

[edit protocols mpls label-switched-path Isp-name fast-reroute], 

[edit protocols mpls label-switched-path Isp-name (primary | secondary) path-name], 

[edit protocols rsvp interface interface-name link-protection], 

[edit protocols rsvp interface interface-name link-protection bypass bypass-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Specify the maximum number of routers that an LSP can traverse. This limit can be applied to any of the 
following: 


e LSPs—The configured hop limit includes the ingress and egress routers. You can specify a hop limit for 
an LSP and for both primary and secondary paths. 


e Fast reroute detour—Specify the number of additional routers a fast reroute detour can traverse relative 
to the protected LSP. For example, if an LSP traverses 4 routers, any detour for the LSP can be no more 
than 10 router hops, including the ingress and egress routers. 


e Link protection bypass—Specify the maximum number of routers that a link protection bypass can 
traverse. 


Options 

number—Maximum number of hops. 
Range: 2 through 255 (for an LSP or for a link protection bypass); O through 255 (for fast reroute) 
Default: 255 (for an LSP or for a link protection bypass); 6 (for fast reroute) 


2018 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Fast Reroute | 474 
Limiting the Number of Hops in LSPs | 516 
Configuring the Hop Limit for Bypass LSPs | 381 


2019 


2020 


| interface (Protocols RSVP) 


Syntax 


interface interface-name { 
disable; 
(aggregate | no-aggregate); 
authentication-key key; 
bandwidth bps; 
hello-interval seconds; 
link-protection { 
disable; 
admin-group { 
exclude [ group-names ]; 
include-all [ group-names ]; 
include-any [ group-names ]; 
} 
bandwidth bps; 
bypass bypass-name { 
bandwidth bps { 
ctO bps; 
ct1 bps; 
ct2 bps; 
ct3 bps; 
} 
description text; 
class-of-service cos-value; 
hop-limit number; 
no-cspf; 
path address <strict | loose>; 
priority setup-priority reservation-priority; 
to address; 
} 
class-of-service cos-value; 
hop-limit number; 
max-bypasses number; 
no-cspf; 
no-node-protection; 
optimize-timer seconds; 
path address <strict | loose>; 
priority setup-priority reservation-priority; 
subscription percentage; 
} 
(reliable | no-reliable); 
subscription percentage { 


ctO percentage; 
ct1 percentage; 
ct2 percentage; 
ct3 percentage; 


} 
update-threshold threshold; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Enable RSVP on one or more router interfaces. 


Default 
RSVP is disabled on all interfaces. 


Options 
interface-name—Name of an interface. To configure all interfaces, specify all. For details about specifying 
interfaces, see the Junos OS Network Interfaces Library for Routing Devices. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Minimum RSVP Configuration | 785 


2021 


2022 


| keep-multiplier 
Syntax 


keep-multiplier number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Specify a value used by RSVP to calculate timer values for network outages, and declare that a reservation 
or a neighbor is down. It indicates the number of messages that can be lost before a particular state is 
declared stale and must be deleted. The keep multiplier directly affects the lifetime of an RSVP state. 


Starting in Junos OS Release 16.1, for MX Series routers and PTX Series routers, the default RSVP message 
refresh time, to which this multiplier is applied, has increased from 30 seconds to 20 minutes. The higher 
message refresh time provides support for RSVP Refresh Reduction Extensions, and improved scaling for 
MPLS traffic-engineered LSPs, as defined in RFC 2961. The changes are backward compatible so if any 
nodes in the two-hop neighborhood do not support the higher refresh time, the updated node will 
automatically fall back to the previous default refresh time to prevent error or tear down messages. 


Options 

number—Multiplier value. 
Range: 1 through 255 
Default: 3 


NOTE: For MX Series routers and PTX Series routers (running Junos OS release 16.1 or later), this 
multiplier is applied to a default refresh time of 20 minutes. In earlier Junos OS releases, and for 
other platforms, the default refresh time remains 30 seconds. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


2023 


RELATED DOCUMENTATION 


Configuring Timers for RSVP Refresh Messages | 808 


2024 


| label-switched-path-template (Multicast) 


Syntax 


label-switched-path-template { 
(default-template | Isp-template-name); 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name provider-tunnel rsvp-te], 

[edit logical-systems logical-system-name routing-instances routing-instance-name provider-tunnel ingress-replication 
label-switched-path], 

[edit logical-systems logical-system-name routing-instances routing-instance-name provider-tunnel selective group 
address source source-address rsvp-te], 

[edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name rsvp-te entry-name], 

[edit protocols mvpn inter-region-segmented template template-name region region-name ingress-replication 
label-switched-path], 

[edit protocols mvpn inter-region-segmented template template-name region region-name rsvpe-te], 

[edit protocols mvpn inter-region-template template template-name all-regions ingress-replication 
label-switched-path], 

[edit protocols mvpn inter-region-template template template-name all-regions rsvp-te], 

[edit routing-instances routing-instance-name provider-tunnel ingress-replication label-switched-path], 

[edit routing-instances routing-instance-name provider-tunnel rsvp-te], 

[edit routing-instances routing-instance-name provider-tunnel selective group address source source-address rsvp-te], 

[edit routing-options dynamic-tunnels tunnel-name rsvp-te entry-name] 

[edit routing-instances instance-name provider-tunnel] 


Release Information 

Statement introduced in Junos OS Release 8.5. 

Statement introduced in Junos OS Release 18.2. under the heirarchy level [edit routing-instances 
instance-name provider-tunnell] 


Description 

Specify the LSP template. An LSP template is used as the basis for other dynamically generated LSPs. This 
feature can be used for a number of applications, including point-to-multipoint LSPs, flooding VPLS traffic, 
configuring ingress replication for IP multicast using MBGP MVPNs, and to enable RSVP automatic mesh. 
There is no default setting for the label-switched-path-template statement, so you must configure either 
the default-template using the default-template option, or you must specify the name of your preconfigured 
LSP template. 


Options 
default-template—Specify that the default LSP template be used for the dynamically generated LSPs. 


Isp-template-name—Specify the name of an LSP to be used as a template for the dynamically generated 
LSPs. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Ingress Replication for IP Multicast Using MBGP MVPNs 
Configuring Point-to-Multipoint LSPs for an MBGP MVPN 

Configuring Dynamic Point-to-Multipoint Flooding LSPs 

Configuring RSVP Automatic Mesh | 807 





2025 


2026 


| link-protection (RSVP) 


Syntax 


link-protection { 
disable; 
admin-group { 
exclude [ group-names ]; 
include-all [ group-names ]; 
include-any [ group-names ]; 
} 
bandwidth bps; 
bypass bypass-name { 
bandwidth bps { 
ctO bps; 
ct1 bps; 
ct2 bps; 
ct3 bps; 
} 
description text; 
class-of-service cos-value; 
hop-limit number; 
no-cspf; 
path address <strict | loose>; 
priority setup-priority reservation-priority; 
to address; 
} 
class-of-service cos-value; 
hop-limit number; 
max-bypasses number; 
no-cspf; 
no-node-protection; 
optimize-timer seconds; 
path address <strict | loose>; 
priority setup-priority reservation-priority; 
subscription percentage; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-namel], 
[edit protocols rsvp interface interface-name] 


Release Information 


2027 


Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 14.1X53-D10 for the QFX Series and for EX4600 switches. 


Description 

Enable link protection on the specified interface. Using link protection, you can configure a network to 
reroute traffic quickly around broken links. To fully enable link protection, you also need to configure the 
link-protection statement at the [edit protocols mpls label-switched-path Isp-name] hierarchy level. You 
can configure single or multiple bypasses for protected interface. 


Default 


Link protection is disabled. 


Options 
no-node-protection—Disable node-link protection on the RSVP interface. Link protection remains active. 
When this option is configured, the router can only initiate a next-hop bypass, not a next-next-hop bypass. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Link Protection on Interfaces Used by LSPs | 377 
link-protection (Dynamic LSPs) | 1826 


2028 


| load-balance (Protocols RSVP) 


Syntax 


load-balance { 
bandwidth; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Load-balance traffic between RSVP LSPs. 


Options 
bandwidth—Load-balance traffic between RSVP LSPs based on the bandwidth configured for each LSP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Load Balancing Across RSVP LSPs | 806 


2029 


| max-bypasses 


Syntax 


max-bypasses number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-namel], 
[edit protocols rsvp interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Range modified in Junos OS Release 9.3. 


Description 

Specify the maximum number of dynamic bypass LSPs permitted for protecting this interface. When this 
option is configured, multiple bypasses for link protection are enabled. Call admission control (CAC) is also 
enabled. The limit on bypasses configured applies only to dynamically generated bypass LSPs. By default, 
this option is disabled and only one dynamic bypass LSP is enabled for each interface. If you configure 
max-bypasses, you must also configure the bandwidth statement. 


Options 
number—Configure the maximum number of bypass LSPs. If you configure a value of 0, no dynamic bypass 
LSPs are allowed to be established for the interface. Only static bypass LSPs can be configured. 

Range: O through 99 

Default: 1 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Maximum Number of Bypass LSPs | 381 


2030 


no-local-reversion 


Syntax 


local-reversion; 
no-local-reversion; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced in Junos OS Release 10.4. 


Description 
Disable RSVP local revertive mode as specified in RFC 4090, Fast Reroute Extensions to RSVP-TE for LSP 
Tunnels. 


NOTE: For Junos OS Release 16.1 running on MX Series or PTX Series routers, no-local-reversion 
is enabled by default, that is, local reversion is not running, and the statement has been 
deprecated. To enable local reversion, use the local-reversion statement. 


RSVP local revertive mode is supported on all Juniper Networks routers running Junos OS. It is the default 
behavior. If you include this statement, the Juniper Networks router uses global revertive mode instead. 
You might need to disable RSVP local revertive mode on Juniper Networks routers if your network includes 
equipment that does not support this mode. 


The following information can also be found in RFC 4090. Refer to the RFC for additional information. 
When an LSP fails, the connection can be repaired locally using a traffic protection mechanism such as 
fast reroute. To restore the LSP to a full working path, RFC 4090 specifies the following strategies: 


e Local revertive mode—Upon detecting that the path is restored, the point of local repair (PLR) resignals 
each of the LSPs that were formerly routed over the restored path. Every LSP successfully resignaled 
along the restored path is switched back. 


e Global revertive mode—The ingress router of each tunnel is responsible for reoptimizing the LSPs that 
used the failed path. There are several potential reoptimization triggers: RSVP error messages, inspection 
of OSPF LSAs or IS-IS LSPs, and timers. This re-optimization process can proceed as soon as the failure 
is detected. It is not tied to the restoration of the failed path. 


Required Privilege Level 


2031 


routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


2032 


| node-hello 


Syntax 


(node-hello | no-node-hello); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced in Junos OS Release 10.0. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Enable node-ID based RSVP hellos globally on all of the RSVP interfaces on the router to allow Juniper 
Networks routers to interoperate with the equipment of other vendors. By default, the Junos OS uses 
interface-based RSVP hellos;node-ID based RSVP hellos are disabled. If you have not enabled RSVP node 
IDs on the router, Junos OS does not accept any node-ID hello packets. 


NOTE: For Junos OS Release 16.1 running on MX Series or PTX Series routers, when using 
enhanced FRR, node-ID based hellos are enabled by default. To disable node-id based hello 
sessions, use the no-node-hello statement. 


NOTE: If link-protection is enabled, remote node hellos that are initiated by the Point of Local 
Repair (PLR) to Node Protecting Merge Point (NP-MP) are enabled automatically. Similarly, if 
no-enhanced-frr-profile is enabled (that is, enhanced FRR is off), remote node hellos are 
automatically disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring RSVP Node-ID Hellos | 793 


2033 


no-enhanced-frr-bypass | 2041 


2034 


no-adjacency-down-notification (Protocols IS-IS) 


Syntax 


no-adjacency-down-notification; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols isis interface interface-name], 
[edit protocols isis interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 8.0. 


Description 


Disable adjacency down notification for IS-IS to allow for migration from IS-IS to OSPF without disruption 
of the RSVP neighbors and associated RSVP-signaled label-switched paths (LSPs). 


Whenever IS-IS is deactivated, the IS-IS adjacencies are brought down. IS-IS signals to RSVP to bring down 
any RSVP neighbors associated with the IS-IS adjacencies, and this further causes the associated LSPs 
signaled by RSVP to go down as well. 


A similar process occurs whenever OSPF is deactivated. The OSPF neighbors are brought down. OSPF 
signals to RSVP to bring down any of the RSVP neighbors associated with the OSPF neighbors, and this 
further causes the associated LSPs signaled by RSVP to go down as well. 


If you need to migrate from IS-IS to OSPF or from OSPF to IS-IS, the internal gateway protocol (IGP) 
notification to RSVP for an adjacency or neighbor down event needs to be ignored. Using the 
no-adjacency-down-notification or no-neighbor-down-notification statements, you can disable IS-IS 
adjacency down notification or OSPF neighbor down notification, respectively, until the migration is 
complete. The network administrator is responsible for configuring the statements before the migration, 
and then removing them from the configuration afterward, so that IGP notification can function normally. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


no-neighbor-down-notification | 2038 


2035 


| no-authentication-check (Protocols RSVP) 


Syntax 


no-authentication-check; 


Hierarchy Level 


[edit protocols rsvp], 


Release Information 
Statement introduced in Junos OS Release 18.4R1. 


Description 


Skip authentication check for received messages. 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


RSVP Authentication | 776 


2036 


| no-cspf (Protocols RSVP) 


Syntax 


no-cspf; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name], 
[edit protocols rsvp interface interface-name link-protection], 

[edit protocols rsvp interface interface-name link-protection bypass bypass-name] 


Release Information 
Statement introduced in Junos OS Release 7.5. 


Description 
Disable CSPF computation on all bypass LSPs or on a specific bypass LSP. You need to disable CSPF for 
link protection to function properly on interarea paths. 


Default 
CSPF is enabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Disabling CSPF for Bypass LSPs | 382 


2037 


| no-interface-hello 


Syntax 


no-interface-hello; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced in Junos OS Release 10.0. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Explicitly disable RSVP interface hellos globally on the router. 


NOTE: For Junos OS Release 16.1 running on MX Series or PTX Series routers, the behavior of 
this statement has changed. On these platforms, rather than disabling RSVP interface hellos 
globally, the no-interface-hello command triggers a switch back to the previous profile for all 
label-switched paths (LSPs.) 


This type of configuration might be necessary in networks where the Juniper Networks router has numerous 
RSVP connections with equipment from other vendors. However, if you disable RSVP interface hellos 
globally, you can also configure a hello interval on an RSVP interface using the hello-interval statement. 
This configuration disables RSVP interface hellos globally but enables RSVP interface hellos on the specified 
interface. This configuration might be necessary in a heterogeneous network where some devices support 
RSVP node-ID hellos and other devices support RSVP interface hellos. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring RSVP Node-ID Hellos | 793 
hello-interval (Protocols RSVP) | 2017 


2038 


| no-neighbor-down-notification 
Syntax 


no-neighbor-down-notification; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id interface interface-name], 
[edit protocols ospf area area-id interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 8.0. 


Description 


Disable neighbor down notification for OSPF to allow for migration from OSPF to IS-IS without disruption 
of the RSVP neighbors and associated RSVP-signaled LSPs. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


2039 


| no-node-id-subobject 
Syntax 


no-node-id-subobject; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced in Junos OS Release 9.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Disable the record route object (RRO) node-ID subobject for compatibility with earlier versions of Junos 
OS. 


NOTE: For Junos OS Release 16.1 running on MX Series or PTX Series routers, the behavior of 
this statement has changed. On these platforms, rather than disabling the record route object 
(RRO) node ID sub-object, the no-node-id-subobject command triggers a switch back to the 
previous profile for all label-switched paths (LSPs). 


To interoperate with other vendors’ equipment, Junos OS supports the RRO node-ID subobject for use 
in inter-AS link and node protection configurations. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Inter-AS Node and Link Protection | 386 


2040 


no-p2mp-sublsp 
Syntax 


no-p2mp-sublsp; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced in Junos OS Release 9.2. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Reject Resv messages that include the S2L_SUB_LSP object. By default, Resv messages that include the 
S2L_SUB_LSP object are accepted. However, in a network which includes Juniper Networks devices 
running both Junos OS Release 9.2 and later and Junos OS Release 9.1 and earlier, it is necessary to 
configure the no-p2mp-sublsp statement on devices running Junos OS Release 9.2 and later to ensure 
that point-to-multipoint LSPs function properly. 


Default 
Resv messages that include the S2L_SUB_LSP object are accepted. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Preserving Point-to-Multipoint LSP Functioning with Different Junos OS Releases | 694 


2041 


| no-enhanced-frr-bypass (Protocols RSVP) 


Syntax 


no-enhanced-frr-bypass; 


Hierarchy Level 


[edit protocols rsvp ] 


Release Information 
Statement introduced in Junos OS Release 15.2R1. 


Description 

Enable no-enhanced-frr-bypass to turn off all Fast reroute (FRR) facility protection enhancements, which 
includes improved LSP scaling and enhanced RSVP message handling, and reduce the default refresh time 
to 30 seconds. 


FRR is enabled by default for MX Series and PTX Series routers starting in Junos OS Release 15.2R1. 


Default 
This feature, no-enhanced-frr-bypass, is disabled by default. That is, enhanced FRR is enabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


RSVP Refresh Reduction | 781 


2042 


| node-link-protection (Protocols MPLS) 


Syntax 


node-link-protection; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls label-switched-path Isp-name], 
[edit protocols mpls label-switched-path Isp-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 14.1X53-D10 for the QFX Series and for EX4600 switches. 


Description 

Enable node and link protection on the specified LSP. To fully enable node and link protection, you also 
need to include the link-protection statement at the [edit protocols rsvp interface interface-name] hierarchy 
level. 


Default 


Node and link protection is disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Node Protection or Link Protection for LSPs | 385 
MPLS Feature Support on QFX Series and EX4600 Switches | 11 
Understanding Interprovider and Carrier-of-Carriers VPNs | 1312 


2043 


| optimize-timer (Protocols RSVP) 


Syntax 


optimize-timer seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 
[edit protocols rsvp interface interface-name link-protection] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 

Configure an optimize timer for a bypass LSP. The optimize timer initiates a periodic optimization process 
that reshuffles data LSPs among bypass LSPs to achieve the most efficient use of network resources. The 
optimization process attempts to either minimize the number of bypasses currently in use, minimize the 
total amount of bandwidth reserved for all bypasses, or both. 


Options 

seconds—Specify the number of seconds between optimizations. 
Range: O through 65,535 seconds 
Default: O (disabled) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Optimization Interval for Bypass LSPs | 383 


2044 


| path (Protocols RSVP) 


Syntax 


path address <strict | loose>; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name], 
[edit protocols rsvp interface interface-name link-protection], 

[edit protocols rsvp interface interface-name link-protection bypass bypass-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 
Configure an explicit path (a sequence of strict or loose routes) to control where and how a bypass LSP is 
established. If multiple bypasses are configured, they all will use the same explicit path. 


Default 
No path is configured. CSPF automatically calculates the path the bypass LSP takes. 


Options 

address—|P address of each transit router in the LSP. You must specify the address or hostname of each 
transit router, although you do not need to list each transit router if its type is loose. As an option, you 
can include the ingress and egress routers in the path. Specify the addresses in order, starting with the 
ingress router (optional) or the first transit router, and continuing sequentially along the path until reaching 
the egress router (optional) or the router immediately before the egress router. 


Default: If you do not specify any routers explicitly, no routing limitations are imposed on the bypass LSP. 


loose—(Optional) The next address in the path statement is loose. The LSP can traverse other routers 
before reaching this router. 
Default: strict 


strict—(Optional) The LSP must go to the next address specified in the path statement without traversing 
other nodes. This is the default. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| Configuring an Explicit Path for Bypass LSPs | 383 


peer-interface (Protocols RSVP) 


Syntax 


peer-interface peer-interface-name { 
disable; 
(aggregate | no-aggregate); 
authentication-key key; 
dynamic-bidirectional-transport template template; 
hello-interval seconds; 
(reliable | no-reliable); 


Hierarchy Level 


[edit protocols rsvp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


dynamic-bidirectional-transport template template option introduced in Junos OS Release 14.2. 


Description 


Configure the name of the LMP peer device. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring RSVP and OSPF for LMP Peer Interfaces 


2045 


2046 


| pop-and-forward (Protocols RSVP) 


Syntax 


pop-and-forward { 
application-label depth depth; 
} 


Hierarchy Level 


[edit logical-systems name protocols rsvp], 

[edit logical-systems name routing-instances name protocols rsvp], 
[edit protocols rsvp], 

[edit routing-instances name protocols rsvp] 


Release Information 
Statement introduced in Junos OS Release 18.1R1 on MX Series routers, PTX Series routers, and vMX. 


Description 


Specify RSVP pop-and-forward LSP tunnel-specific global parameters. The application label depth (AppLD) 
value must be configured uniformly across the RSVP-TE network. 


Options 
application-label depth depth—Specify the maximum number of service labels. 


Range: O through 3 
Default: 1 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Pop-and-Forward LSP Configuration | 697 
show rsvp pop-and-forward | 2510 
pop-and-forward (Protocols MPLS) | 1906 
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preemption 
Syntax 


preemption { 
(aggressive | disabled | normal); 
soft-preemption { 
cleanup-timer seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Control RSVP session preemption. 


Default 


normal 


Options 
aggressive—Preempt RSVP sessions whenever bandwidth is insufficient to handle all sessions. A session 
is preempted whenever bandwidth is lowered or a new higher-priority session is established. 


disabled—Do not preempt RSVP sessions. 


normal—Preempt RSVP sessions to accommodate new higher-priority sessions when bandwidth is 
insufficient to handle all sessions. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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Preempting RSVP Sessions | 809 
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| priority (Protocols RSVP) 


Syntax 


priority setup-priority reservation-priority; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection bypass bypass-name], 
[edit protocols rsvp interface interface-name link-protection], 

[edit protocols rsvp interface interface-name link-protection bypass bypass-namel], 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 

Configure the setup priority and reservation priority for a bypass LSP. If insufficient link bandwidth is 
available during session establishment, the setup priority is compared with other setup priorities for 
established sessions on the link to determine whether some of them should be preempted to accommodate 
the new session. The session with the lower-hold priority is preempted. 


Options 
reservation-priority—Reservation priority, used to keep a reservation after it has been set up. A smaller 
number has a higher priority. The priority must be greater than or equal to the setup priority to prevent 
preemption loops. 

Range: O through 7, where 0 is the highest and 7 is the lowest priority. 


Default: O (Once the session is set up, no other session can preempt it.) 


setup-priority—Setup priority. 
Range: O through 7, where 0 is the highest and 7 is the lowest priority. 


Default: 7 (The session cannot preempt any existing sessions.) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Priority and Preemption for Bypass LSPs | 384 
Configuring Priority and Preemption for LSPs | 502 
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| refresh-time 


Syntax 


refresh-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Set the refresh time. 


Options 

seconds—Refresh time. 
Range: 1 through 65,535 
Default: 30 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Timers for RSVP Refresh Messages | 808 
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| reliable 


Syntax 


(reliable | no-reliable); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-namel], 

[edit logical-systems logical-system-name protocols rsvp peer-interface peer-interface-name], 
[edit protocols rsvp interface interface-name], 

[edit protocols rsvp peer-interface peer-interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Enable reliable message delivery on the interface. 


To have both refresh reduction and reliable delivery, enable both the aggregate and reliable statements. 


NOTE: For Junos OS Release 16.1 running on MX Series or PTX Series routers, setting no-reliable 
on an interface automatically disables the fast reroute (FRR) scalability enhancements, including 
refresh reduction, for all label-switched paths (LSPs) traversing the interface. 


Default 


Starting in Junos OS Release 16.1R1, all refresh reduction extensions are enabled by default. 


Prior to Junos OS Release 16.1R1, the reliable option is disabled by default. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring RSVP Refresh Reduction | 788 
aggregate | 1996 
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| no-enhanced-frr-bypass | 2041 


| rsvp 


Syntax 


rsvp; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols], 
[edit protocols] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Enable Resource Reservation Protocol (RSVP) signaling. 
You must include the rsvp statement in the configuration to enable RSVP on the router. 


The primary purpose of RSVP in Junos OS for EX Series switches is to support dynamic signaling within 
label switched paths (LSPs). 


Default 
RSVP is disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Minimum RSVP Configuration | 785 

Example: Configuring MPLS on EX8200 and EX4500 Switches | 42 

Configuring MPLS on Provider Edge EX8200 and EX4500 Switches Using Circuit Cross-Connect | 74 
Configuring MPLS on EX8200 and EX4500 Provider Switches | 78 
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| rsvp-te (Routing Options) 
Syntax 


rsvp-te entry-name { 
destination-networks network-prefix; 
label-switched-path-template (Multicast) { 
default-template; 
template-name; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options dynamic-tunnels tunnel-name], 
[edit routing-options dynamic-tunnels tunnel-name] 


Release Information 
Statement introduced in Junos OS Release 10.1. 
Statement introduced in Junos OS Release 12.3 for ACX Series routers. 


Description 
Enable RSVP to automatically establish LSPs for any new PE router added to a full mesh of LSPs. To enable 
this feature, you must configure the rsvp-te statement on all of the PE routers in the full mesh. 


Options 
entry-name—Specify the entry for the RSVP tunnel. 


The other options are explained separately. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring RSVP Automatic Mesh | 807 
Configuring Dynamic Point-to-Multipoint Flooding LSPs 
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| setup-protection 


Syntax 


setup-protection; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Description 

The facility-backup fast reroute mechanism can provide setup protection for LSPs which are in the process 
of being signaled. Both point-to-point LSPs and point-to-multipoint LSPs are supported. You should 
configure the setup-protection statement on each of the routers along the LSP path on which you want 
to enable LSP setup protection. You should also configure IGP traffic engineering on all of the routers on 
the LSP path. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring RSVP Setup Protection | 805 
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| soft-preemption (Protocols RSVP) 


Syntax 


soft-preemption { 
cleanup-timer seconds; 


} 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp preemption], 
[edit protocols rsvp preemption] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Enable soft preemption to attempt to establish a new path for a preempted LSP before tearing it down. 


Options 

cleanup-timer—A value of O disables soft preemption. 
Range: O through 10800 seconds 
Default: 30 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring MPLS Soft Preemption | 501 


| static-label-switched-path 


Syntax 


static-label-switched-path Isp-name { 


bypass bypass-name { 


} 


bandwidth bps; 

description string; 

next-hop (address | interface-name | address/interface-name); 
push out-label; 

to address; 


ingress { 


} 


bandwidth bps; 
class-of-service cos-value; 
description string; 
install { 
destination-prefix <active>; 
} 
link-protection bypass-name name; 
metric metric; 
next-hop (address | interface-name | address/interface-name); 
node-protection bypass-name name next-next-label label; 
no-install-to-address; 
policing { 
filter filter-name; 
no-auto-policing; 
} 
preference preference; 
push out-label; 
to address; 


transit incoming-label { 


bandwidth bps; 

description string; 

link-protection bypass-name name; 

next-hop (address | interface-name | address/interface-name); 
node-protection bypass-name name next-next-label label; 
pop, 

swap out-label; 


Hierarchy Level 
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[edit logical-systems logical-system-name protocols mpls], 
[edit protocols mpls] 


Release Information 
Statement introduced in Junos OS Release 10.1. 


Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Statement introduced in 19.4R1 for cRPD instances. 


Description 


Configure a static LSP. 


Options 


Isp-name—Name of the path. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Static LSPs | 574 
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| subscription 
Syntax 


subscription percentage { 
ctO percentage; 
ct1 percentage; 
ct2 percentage; 
ct3 percentage; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-name], 

[edit logical-systems logical-system-name protocols rsvp interface interface-name link-protection], 
[edit protocols rsvp interface interface-name], 

[edit protocols rsvp interface interface-name link-protection] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Configure the amount of bandwidth subscribed to a class type (when you have enabled Differentiated 
Services) or bypass LSP (when you have enabled link protection). subscription is the percentage of the 
link bandwidth that can be used for the RSVP reservation process. 


Options 
ctnumber percentage—Percentage of the class-type bandwidth allowed for reservations. If you specify a 
value greater than 100, you are oversubscribing the class type. You can specify bandwidth subscriptions 
for class types O through 3. This option is not available for bypass LSPs. 

Range: O through 65,000 

Default: 100 percent 


percentage—Percentage of the class-type or bypass LSP bandwidth allowed for reservations. If you specify 
a value greater than 100, you are oversubscribing the class type or bypass LSP. 

Range: O through 65,000 

Default: 100 percent 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Configuring the Bandwidth Subscription Percentage for LSPs | 568 
Configuring the Amount of Bandwidth Subscribed for Bypass LSPs | 384 
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| traceoptions (Protocols RSVP) 


Syntax 


traceoptions { 
enhanced-frr ; 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag <flag-modifier> <disable>; 

} 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Enable RSVP-level trace options. 


Default 


The default RSVP-level trace options are those inherited from the routing protocols traceoptions statement 
included at the [edit routing-options] hierarchy level. 


Options 
disable—(Optional) Disable the tracing operation. You can use this option to disable a single operation 
when you have defined a broad group of tracing operations, such as all. 


enhanced-frr —(Optional) Enable this option to trace internal events and state changes related to the FRR 
facility protection enhancements associated with the increased RSVP scaling introduced in Junos OS 
Release 16.1. 


filename—Name of the file to receive the output of the tracing operation. Enclose the name within quotation 
marks. All files are placed in the directory /var/log. We recommend that you place RSVP tracing output 
in the file rsvp-log. 


files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its 
maximum size, it is renamed trace-file.0, then trace-file.1, and so on, until the maximum number of trace 
files is reached. Then the oldest trace file is overwritten. 

Range: 2 through 1000 

Default: 2 files 
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If you specify a maximum number of files, you must also include the size statement to specify the maximum 


file size. 


flag—Tracing operation to perform. To specify more than one tracing operation, include multiple flag 


statements. 


all—All tracing operations 
error—All detected error conditions 
event—RSVP-related events 


io-event [detail] [disable] —Enable tracing of events that occur within the RSVP I/O task; can only be 
configured for the master routing instance. The trace output is generally independent of routing instance. 


io-packets [detail] [disable] [receive] [send] —Enable tracing of messages as they are received from the 
network or as they are sent out. This flag can be configured independently for each routing instance. 
Both bundled and individual messages are identified. Use detail to show all objects contained in the 
message. Use send and receive to limit tracing to outgoing or incoming packets. 


Imp—RSVP-LMP interactions 
packets—All RSVP packets 
path—All path messages 
pathtear—PathTear messages 
resv—Resv messages 
resvtear—ResvTear messages 
route—Routing information 


state—Session state transitions, including when RSVP-signaled LSPs come up and go down. 


flag-modifier—(Optional) Modifier for the tracing flag. You can specify one or more of these modifiers: 


detail—Provide detailed trace information 
receive—Packets being received 


send—Packets being transmitted 


no-world-readable—(Optional) Enable only certain users to read the log file. 
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size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB), or gigabytes (GB). 
When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again 
reaches this size, trace-file.O is renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming 
scheme continues until the maximum number of trace files is reached. Then the oldest trace file is 
overwritten. 


Syntax: xk to specify KB, xm to specify MB, or xg to specify GB 
Range: 10 KB through the maximum file size supported on your system 
Default: 1. MB 


If you specify a maximum file size, you must also include the files statement to specify the maximum 
number of files. 


world-readable—(Optional) Enable any user to read the log file. 


Required Privilege Level 
routing and trace—To view this statement in the configuration. 
routing-control and trace-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Tracing RSVP Protocol Traffic | 816 
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transit 


Syntax 


transit incoming-label { 
bandwidth bps; 
description string; 
link-protection bypass-name name; 
member-interface member-interface; 
next-hop (address | interface-name | address/interface-name); 
node-protection bypass-name name next-next-label label; 
pop, 
stitch { 
bandwidth bps; 
description string; 
link-protection bypass-name name; 
next-hop (address | interface-name | address/interface-name); 
node-protection bypass-name name next-next-label label; 
} 


swap out-label; 


Hierarchy Level 


[edit logical-systems name protocols mpls static-label-switched-path name], 

[edit logical-systems name routing-instances name protocols mpls static-label-switched-path name], 

[edit logical-systems name tenants name routing-instances name protocols mpls static-label-switched-path name], 
[edit protocols mpls static-label-switched-path name], 

[edit routing-instances name protocols mpls static-label-switched-path name], 

[edit tenants name routing-instances name protocols mpls static-label-switched-path name] 


Release Information 

Statement introduced in Junos OS Release 10.1. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 

switch option introduced in Junos OS Release 14.1X53-D25. 

member-interface option introduced in Junos OS Release 17.4R1 for the MX Series and PTX 5000. 


Description 


Configure a transit static LSP. 
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NOTE: When configuring transit static LSPs with label operation as stitch, the configured 
next-hop can only be a valid IP address and not an interface name. 


Options 
incoming-label—Incoming label value. 
Range: 1000000 through 1048575 


member-interface—Aggregated Ethernet (AE) member interface name. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Static LSPs | 574 


Configuring Static Adjacency Segment Identifier for Aggregate Ethernet Member Links Using Single-Hop 
Static LSP | 764 
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| tunnel-services (RSVP) 


Syntax 


tunnel-services { 
devices device-names; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp], 
[edit protocols rsvp] 


Release Information 
Statement introduced in Junos OS Release 8.1. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Enable ultimate-hop popping on point-to-multipoint LSPs. The Junos OS selects one of the available virtual 
tunnel (VT) interfaces to de-encapsulate the egress traffic. By default, the selection process is performed 
automatically. 


Default 
Ultimate-hop popping is disabled. 


Options 
devices device-names—Specify which VT interfaces are used to handle the RSVP traffic. 


Range: 0 to 8 devices 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Enabling Ultimate-Hop Popping on Point-to-Multipoint LSPs | 815 
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ultimate-hop-popping 
Syntax 


ultimate-hop-popping; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols mpls], 

[edit logical-systems logical-system-name protocols mpls label-switched-path label-switched-path-name], 
[edit protocols mpls], 

[edit protocols mpls label-switched-path label-switched-path-name] 


Release Information 
Statement introduced in Junos OS Release 12.3. 
Statement introduced in Junos OS Release 13.2 for PTX Series Packet Transport Routers. 


Description 

Enable ultimate-hop popping on LSPs. Configure this statement on the device at the LSP ingress. In 
ultimate-hop popping, the MPLS label is popped from the IP packet at the PE router. The IP address is 
checked in a second address lookup (also at the PE router), and then the packet is forwarded to its 
destination. 


Be aware of the following platform requirements and restrictions: 


e UHP LSPs using VT interfaces—Supported on all M Series, MX Series, T Series, and TX Matrix routers. 
e UHP LSPs using LSI interfaces—Supported on MX 3D Series routers only. 


e UHP LSP requirements for the egress PE device—For M Series and T Series routers, a VT interface is 
needed. 


e UHP LSPs and Layer 3 VPNs—UHP LSPs are supported for Layer 3 VPNs configured on MX 3D Series 
routers only. 


e UHP LSPs and VPLS—UHP LSPs are supported for VPLS configured on MX 3D Series routers only. You 
must configure the no-tunnel-services statement at the [edit routing-instances routing-instance-name 
protocols vpls] hierarchy level. 


Default 

Ultimate-hop popping is disabled by default on LSPs. Penultimate-hop popping is the default behavior. In 
penultimate-hop popping, the final MPLS label is popped from the IP packet at the last provider router in 
the network before being forwarded to the PE router. The PE router receives the packet and checks the 
IP address, and then the packet is forwarded to its destination. 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Ultimate-Hop Popping for LSPs | 560 
explicit-null | 1775 
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| update-threshold 


Syntax 


update-threshold { 
threshold-percent; 
threshold-value threshold-value; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols rsvp interface interface-namel], 
[edit protocols rsvp interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 
threshold-value option introduced in Junos OS Release 19.4R1 on all platforms. 


Description 


Adjust the threshold at which a change in bandwidth triggers an interior gateway protocol (IGP) update. 


Options 

threshold-percent—Specify the percentage change in reserved bandwidth to trigger IGP update. 
Default: 10 percent 
Range: 0.001 through 20 percent 


threshold-value threshold-value—Specify the change in reserved bandwidth to trigger IGP update. (is 
capped at 20% of link bandwidth). 


If the threshold-value is configured to greater than 20% of bandwidth on that link, the threshold-value 
is capped at 20% of bandwidth. 


For instance, if bandwidth on an interface is 1Gbps, and the threshold-value is configured greater 
than 200Mbps, the threshold-value is capped at 200Mbps. The threshold-percent is displayed as 
20.000% and the threshold-value as 200Mbps. 
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NOTE: The two options, threshold-percent and threshold-value, are mutually exclusive. You can 
configure only one option at a given point in time to generate an IGP update for lower bandwidth 
reservations. As a result, when one option is configured, the other option is calculated and 
displayed on the CLI. 


For instance, on a link of 1Gbps, if the threshold-percent is configured to 5%, the threshold-value 
is calculated and displayed as 5}0Mbps. Similarly, if the threshold-value is configured to 50m, 
then the threshold-percent is calculated and displayed as 5%. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the RSVP Update Threshold on an Interface | 791 


CHAPTER 22 


LDP Configuration Statements 


IN THIS CHAPTER 


allow-subnet-mismatch | 2073 
authentication-algorithm | 2074 
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ecmp | 2088 
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explicit-null (Protocols LDP) | 2090 
export (Protocols LDP) | 2091 
failure-action (Protocols LDP) | 2092 

fec | 2093 

graceful-restart (Protocols LDP) | 2095 
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helper-disable (LDP) | 2097 
holddown-interval | 2098 

hold-time (Protocols LDP) | 2099 
ignore-Isp-metrics | 2100 
igp-synchronization | 2101 

import (Protocols LDP) | 2102 
ingress-policy | 2103 

interface (Protocols LDP) | 2104 
keepalive-interval | 2105 


keepalive-timeout | 2106 
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|2-smart-policy | 2107 

label-withdrawal-delay | 2108 

Idp | 2109 

Idp-synchronization | 2111 

log-updown (Protocols LDP) | 2112 

make-before-break (LDP) | 2113 

mapping-server-entry | 2114 

maximum-neighbor-recovery-time | 2115 

mlidp-inband-signalling (Protocols Multipoint LDP) | 2116 
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mofrr-disjoint-upstream-only (Multicast-Only Fast Reroute ina PIM Domain) | 2119 
mofrr-no-backup-join (Multicast-Only Fast Reroute ina PIM Domain) | 2120 
mofrr-primary-path-selection-by-routing (Multicast-Only Fast Reroute) | 2121 
neighbor (Protocols LDP) | 2122 

no-forwarding | 2123 

oam (Protocols LDP) | 2124 

p2mp (Protocols LDP) | 2126 

p2mp-ldp-next-hop | 2128 

periodic-traceroute | 2129 

policing (Protocols LDP) | 2131 

policy (Multicast-Only Fast Reroute) | 2132 

policy (Protocols Multipoint LDP) | 2135 

preference (Protocols LDP) | 2136 

prefix-segment (Routing Options) | 2137 

prefix-segment-range | 2138 

reconnect-time | 2140 

recovery-time | 2141 

session (Protocols LDP) | 2142 

session-group | 2144 

session-protection | 2146 

source-packet-routing | 2147 

stream-protection (Multicast-Only Fast Reroute) | 2148 
strict-targeted-hellos | 2149 

targeted-hello | 2150 
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traceoptions (Protocols LDP) | 2151 
track-igp-metric | 2154 
track-igp-metric (LSP) | 2155 
traffic-statistics (Protocols LDP) | 2156 
transport-address | 2158 

version (BFD) | 2160 
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| allow-subnet-mismatch 


Syntax 


allow-subnet-mismatch; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp interface interface-name], 
[edit protocols Idp interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 9.3. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Ignore the LDP subnet check. For Junos OS Release 8.4 and later releases, an LDP source address subnet 


check was added for the neighbor establishment procedure. The source address in the LDP link hello 
packet is matched against the interface address. 


Default 


The source address in the LDP link hello packet is matched against the interface address. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Ignoring the LDP Subnet Check | 1052 
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| authentication-algorithm 


Syntax 


authentication-algorithm algorithm; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols bgp], 

[edit logical-systems logical-system-name protocols bgp group group-name], 

[edit logical-systems logical-system-name protocols bgp group group-name neighbor address], 

[edit logical-systems logical-system-name protocols Idp session session-address], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name 
neighbor address], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp session session-address], 

[edit logical-systems logical-system-name routing-options bmp], 

[edit logical-systems logical-system-name routing-options bmp station station-name], 

[edit protocols bgp], 

[edit protocols bgp group group-name], 

[edit protocols bgp group group-name neighbor address], 

[edit protocols Idp session session-address], 

[edit routing-instances routing-instance-name protocols bgp], 

[edit routing-instances routing-instance-name protocols bgp group group-name], 

[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address], 

[edit routing-instances routing-instance-name protocols Idp session session-address], 

[edit routing-options bmp], 

[edit routing-options bmp station station-name] 


Release Information 

Statement introduced in Junos OS Release 7.6. 

Statement introduced for BGP in Junos OS Release 8.0. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 

Statement introduced for BMP in Junos OS Release 13.2X51-D15 for the QFX Series. 
Statement introduced for BMP in Junos OS Release 13.3. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Configure an authentication algorithm type. 
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NOTE: Keep the following points in mind when you configure the authentication algorithm in 
an IPsec proposal: 


e When both ends of an IPsec VPN tunnel contain the same IKE proposal but different IPsec 
proposals, an error occurs and the tunnel is not established in this scenario. For example, if 
one end of the tunnel contains router 1 configured with the authentication algorithm as 
hmac-sha- 256-128 and the other end of the tunnel contains router 2 configured with the 
authentication algorithm as hmac-md5-96, the VPN tunnel is not established. 


e When both ends of an IPsec VPN tunnel contain the same IKE proposal but different IPsec 
proposals, and when one end of the tunnel contains two IPsec proposals to check whether a 
less secure algorithm is selected or not, an error occurs and the tunnel is not established. For 
example, if you configure two authentication algorithms for an IPsec proposal as 
hmac-sha-256-128 and hmac-md5-96 on one end of the tunnel, router 1, and if you configure 
the algorithm for an IPsec proposal as hmac-md5-96 on the other end of the tunnel, router 2, 
the tunnel is not established and the number of proposals mismatch. 


When you configure two IPsec proposals at both ends of a tunnel, such as the 
authentication-algorithm hmac-sha-256-128 and authentication- algorithm hmac-md5-96 
statements at the [edit services ipsec-vpn ipsec proposal proposal-name] hierarchy level on 


one of the tunnel, router 1 (with the algorithms in two successive statements to specify the 
order), and the authentication-algorithm hmac-md5-96 and authentication- algorithm 
hmac-sha-256-128 statements at the [edit services ipsec-vpn ipsec proposal proposal-name] 
hierarchy level on one of the tunnel, router 2 (with the algorithms in two successive statements 
to specify the order, which is the reverse order of router 1), the tunnel is established in this 
combination as expected because the number of proposals is the same on both ends and they 
contain the same set of algorithms. However, the authentication algorithm selected is 
hmac-md5-96 and not the stronger algorithm of hmac-sha-256-128. This method of selection 
of the algorithm occurs because the first matching proposal is selected. Also, for a default 
proposal, regardless of whether the router supports the Advanced Encryption Standard (AES) 
encryption algorithm, the 3des-cbc algorithm is chosen and not the aes-cfb algorithm, which 
is because of the first algorithm in the default proposal being selected. In the sample scenario 
described here, on router 2, if you reverse the order of the algorithm configuration in the 
proposal so that it is the same order as the one specified on router 1, hmac-sha-256-128 is 
selected as the authentication method. 


You must be aware of the order of proposals in an IPsec policy at the time of configuration if 


you want the matching of proposals to happen in a certain order of preference, such as the 
strongest algorithm to be considered first when a match is made when both policies from the 
two peers have a proposal. 
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Options 
algorithm—Specify one of the following types of authentication algorithms: 
e aes-128-cmac-96—Cipher-based message authentication code (AES128, 96 bits). 
e hmac-sha-1-96—Hash-based message authentication code (SHA1, 96 bits). 
e md5—Message digest 5. 
Default: hmac-sha-1-96 


NOTE: The default is not displayed in the output of the show bgp bmp command unless a key or 
key-chain is also configured. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Router Authentication for BGP 
Configuring BGP Monitoring Protocol Version 3 
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| authentication-key (Protocols LDP) 


Syntax 


authentication-key md5-authentication-key; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp session address], 
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp session address], 
[edit protocols Idp session address], 


[edit routing-instances routing-instance-name protocols Idp session address] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Configure the MD5 authentication signature. The maximum length of the authentication signature is 69 
characters. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the TCP MD5 Signature for LDP Sessions | 1048 
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| authentication-key-chain (Protocols LDP) 


Syntax 


authentication-key-chain key-chain; 


Hierarchy Level 


[edit logical-systems name protocols Idp session address], 

[edit logical-systems name routing-instances instance-name protocols Idp session address], 
[edit protocols Idp session address], 

[edit routing-instances instance-name protocols Idp session address] 


Release Information 

Statement introduced in Junos OS Release 8.0. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Apply and enable an authentication keychain to the routing device. Note that the referenced key chain 
must be defined. When configuring the authentication key update mechanism for LDP, you cannot commit 
the 0.0.0.0/allow statement with authentication keys or key chains. The CLI issues a warning and fails to 
commit such configurations. 


NOTE: You must also configure an authentication algorithm using the authentication-algorithm 
statement. 


Options 
key-chain—Authentication keychain name. It can be up to 126 characters. Characters can include any ASCII 
strings. If you include spaces, enclose all characters in quotation marks (“ ”). 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Authentication Key Update Mechanism for BGP and LDP Routing Protocols 
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Configuring Miscellaneous LDP Properties | 1045 
authentication-algorithm | 2074 
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| auto-targeted-session 


Syntax 


auto-targeted-session { 
maximum-sessions seconds; 
teardown-delay seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 
[edit protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 14.2. 


Description 
Configure session parameters for LDP sessions established with the remote LFA node that are automatically 


targeted using the loopback addresses. Configure parameters of automatically targeted sessions for remote 
LFA only. 


Options 

maximum-sessions seconds —Specify the maximum number of auto-targeted LDP sessions allowed. Include 
this statement to optimize the use of router memory. 
Default: 100 
Range: 1 through 1000 


teardown-delay seconds —Specify the minimum time period for which the auto-targeted session must be 
alive before tearing down the auto-targeted LDP sessions to the remote LFA node. Include this 
statement to prevent rapid route-resolution in case of temporary change in IGP topology. 


Default: 90 seconds 
Range: 1 through 300 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


no-eligible-remote-backup 
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remote-backup-calculation 


| bfd-liveness-detection (Protocols LDP) 


Syntax 


bfd-liveness-detection { 
detection-time threshold milliseconds; 
ecmp; 
failure-action { 
remove-nexthop; 
remove-route; 
} 
holddown-interval seconds; 
minimum-interval milliseconds; 
minimum-receive-interval milliseconds; 
minimum-transmit-interval milliseconds; 
multiplier detection-time-multiplier, 
no-adaptation; 
transmit-interval { 
minimum-interval milliseconds; 
threshold milliseconds; 
} 


version (0 | 1 | automatic); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp oam], 

[edit logical-systems logical-system-name protocols Idp oam fec address], 
[edit protocols Idp oam], 

[edit protocols Idp oam fec address] 


Release Information 

Statement introduced in Junos OS Release 7.6. 

Support for the bfd-liveness-detection statement at the [edit protocols Idp oam fec address] hierarchy 
level and the ecmp option added in Junos OS Release 9.0. 

Support for the failure-action statement with the remove-nexthop and remove-route options and the 
holddown-interval statement added in Junos OS Release 9.4. 


Description 
Enable Bidirectional Forwarding Detection (BFD) for all MPLS LSPs or for just a specific LSP. 


Options 


minimum-interval—Minimum transmit and receive interval. 
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Range: 50 through 255,000 milliseconds 
Default: 50 


minimum-receive-interval—Minimum receive interval. 
Range: 50 through 255,000 milliseconds 
Default: 50 


minimum-transmit-interval—Minimum transmit interval. 
Range: 50 through 255,000 milliseconds 
Default: 50 


multiplier—Detection time multiplier. 
Range: 50 through 255 
Default: 3 


The other options are explained separately. 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring BFD for LDP LSPs | 908 
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| deaggregate 


Syntax 


deaggregate | no-deaggregate; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Control forwarding equivalence class (FEC) deaggregation on the router. The use of the deaggregate 
statement in LDP is a standard practice that we recommend for LDP deployments. 


Default 


Deaggregation is disabled on the router. 


Options 
deaggregate—Deaggregate FECs. 


no-deaggregate—Agegregate FECs. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring FEC Deaggregation | 905 
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| disable (Protocols LDP) 


Syntax 


disable; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp graceful-restart], 

[edit logical-systems logical-system-name protocols Idp interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp interface 
interface-namel], 

[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options graceful-restart], 

[edit protocols Idp graceful-restart], 

[edit protocols Idp interface interface-name], 

[edit routing-instances routing-instance-name protocols Idp interface interface-name], 

[edit routing-instances routing-instance-name routing-options graceful-restart] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Explicitly disable LDP on an interface, or explicitly disable LDP graceful restart. 


Default 


LDP is enabled on interfaces configured with the LDP interface statement. LDP graceful restart is 
automatically enabled when graceful restart is enabled under the [edit routing-options] hierarchy level. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Enabling and Disabling LDP | 868 
Configuring LDP Graceful Restart | 893 
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| dod-request-policy 
Syntax 


dod-request-policy dod-request-policy-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 
[edit protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 12.2. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Specify the name of the LDP downstream on demand request policy. The dod-request-policy statement 


performs exact match, as a result, LDP sends label request messages only for those FECs matching in the 
downstream on demand request policy. 


Options 


dod-request-polcy-name—Specify the name of the downstream on demand request policy. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring LDP Downstream on Demand | 978 
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| downstream-on-demand 


Syntax 


downstream-on-demand; 


Hierarchy Level 


[edit logical systems logical-system-name protocols Idp session session-address], 
[edit protocols Idp session session-address] 


Release Information 
Statement introduced in Junos OS Release 12.2. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Enable LDP downstream on demand on the LDP session. LDP is widely deployed in downstream unsolicited 
advertisement mode. As service providers integrate the access and aggregation networks into a single 
MPLS domain, LDP downstream on demand is needed to distribute the bindings between access and 
aggregation networks to minimize the workload for the access node (AN) control plane and to avoid the 
storage of tens of thousands of label bindings from upstream aggregation nodes. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring LDP Downstream on Demand | 978 
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| ecmp 
Syntax 


ecmp; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp oam bfd-liveness-detection], 

[edit logical-systems logical-system-name protocols Idp oam fec address bfd-liveness-detection], 
[edit protocols Idp oam bfd-liveness-detection], 

[edit protocols Idp oam fec address bfd-liveness-detection] 


Release Information 
Statement introduced in Junos OS Release 8.5. 
Statement introduced in Junos OS Release 15.1X53-D30 for QFX Series switches. 


Description 

Allows LDP to establish BFD sessions for all ECMP paths configured for the specified FEC. If you configure 
the ecmp statement, you must also configure the periodic-traceroute statement for the specified FEC. If 
you do not do so, the commit operation fails. You can configure the periodic-traceroute statement at the 
global hierarchy level ([edit protocols Idp oam]) while only configuring the ecmp statement for a specific 
FEC ([edit protocols Idp oam fec address bfd-liveness-detection]). 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring ECMP-Aware BFD for LDP LSPs | 911 
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| egress-policy 
Syntax 


egress-policy [ policy-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Control the prefixes advertised into LDP. 


Default 
Only the loopback address is advertised. 


Options 


policy-names—Name of one or more routing policies. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Prefixes Advertised into LDP from the Routing Table | 904 
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| explicit-null (Protocols LDP) 


Syntax 


explicit-null; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Advertise label O to the egress router of a label-switched path (LSP). 


Default 


If you do not include the explicit-null statement in the MPLS configuration, label 3 (implicit null) is advertised. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring MPLS and LDP to Pop the Label on the Ultimate-Hop Router | 1046 
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| export (Protocols LDP) 


Syntax 


export [ policy-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Apply policy filters to outbound LDP label bindings. Filters are applied to all label bindings from all neighbors. 


Options 


policy-names—Name of one or more routing policies. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Filtering Outbound LDP Label Bindings | 899 
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| failure-action (Protocols LDP) 


Syntax 


failure-action { 
remove-nexthop; 
remove-route; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp oam bfd-livenesss-detection], 

[edit logical-systems logical-system-name protocols Idp oam fec address bfd-livenesss-detection], 
[edit protocols Idp oam bfd-livenesss-detection], 

[edit protocols Idp oam fec address bfd-livenesss-detection] 


Release Information 
Statement introduced in Junos OS Release 9.4. 


Description 

Configure route and next-hop properties in the event of a BFD session failure event on an LDP LSP. The 
failure event could be an existing BFD session that has gone down or could be a BFD session that never 
came up. LDP adds back the route or next hop when the relevant BFD session comes back up. 


Options 
remove-nexthop—Remove a route corresponding to a next hop of the LSP’s route at the ingress node 
when a BFD session failure event is detected. 


remove-route—Remove the route corresponding to an LSP from the appropriate routing tables when a 
BFD session failure event is detected. If the LSP is configured with ECMP and a BFD session corresponding 
to any path goes down, the route is removed. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring a Failure Action for the BFD Session on an LDP LSP | 912 


| fec 


Syntax 


fec fec-address { 


bfd-liveness-detection { 


} 


detection-time threshold milliseconds; 
ecmp; 
failure-action { 
remove-nexthop; 
remove-route; 
} 
holddown-interval milliseconds; 
ingress-policy ingress-policy-name; 
minimum-interval milliseconds; 
minimum-receive-interval milliseconds; 
minimum-transmit-interval milliseconds; 
multiplier detection-time-multiplier, 
no-adaptation; 
transmit-interval { 
minimum-interval milliseconds; 
threshold milliseconds; 
} 


version (0 | 1 | automatic); 


no-bfd-liveness-detection; 


periodic-traceroute { 


disable; 

exp exp-value; 

fanout fanout-value; 
frequency minutes; 
paths number-of-paths; 
retries retry-attempts; 
source address; 

ttl ttl-value; 

wait seconds; 


Hierarchy Level 


[edit logical-systems logical-systems-name protocols Idp oam], 


[edit protocols Idp oam] 
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Release Information 

Statement introduced in Junos OS Release 8.5. 

Statement introduced in Junos OS Release 12.2 for EX Series switches. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Allows you to configure BFD for a specific LDP forwarding equivalence class (FEC). 


Options 
fec-address—Specify the FEC address. 


The other statements are explained separately. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring BFD for LDP LSPs | 908 
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| graceful-restart (Protocols LDP) 


Syntax 


graceful-restart { 
disable; 
helper-disable; 
maximum-neighbor-recovery-time value; 
reconnect-time seconds; 
recovery-time value; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Configure LDP graceful restart on the LDP master protocol instance or for a specific routing instance. 


NOTE: When you alter the graceful restart configuration at either the [edit routing-options 
graceful-restart] or [edit protocols Idp graceful-restart] hierarchy levels, any running LDP session 
is automatically restarted to apply the graceful restart configuration. This behavior mirrors the 
behavior of BGP when you alter its graceful restart configuration. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LDP Graceful Restart | 893 


2096 


| hello-interval (Protocols LDP) 


Syntax 


hello-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp interface interface-name], 

[edit logical-systems logical-system-name protocols Idp targeted-hello], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp interface 
interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp targeted-hello], 

[edit protocols Idp interface interface-name], 

[edit protocols Idp targeted-hello], 

[edit routing-instances routing-instance-name protocols Idp interface interface-name], 

[edit routing-instances routing-instance-name protocols Idp targeted-hello] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Support for LDP targeted hellos added in Junos OS Release 9.5. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Control the LDP timer that regulates how often hello messages are sent. You can control the rate both 
link hello messages and targeted hello messages are sent depending on the hierarchy level at which you 
configure the hello-interval statement. 


Options 
seconds—Length of time between transmission of hello packets. 
Range: 1 through 65,535 seconds 


Default: 5 seconds for link hello messages, 15 seconds for targeted hello messages 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the LDP Timer for Hello Messages | 869 
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helper-disable (LDP) 


Syntax 


helper-disable; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp graceful-restart], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp graceful-restart], 
[edit protocols Idp graceful-restart], 

[edit routing-instances routing-instance-name protocols Idp graceful-restart] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Disable helper mode for LDP graceful restart. When helper mode is disabled, a router cannot help a 
neighboring router that is attempting to restart LDP. 


Default 


Helper mode is enabled by default on all routing protocols (including LDP) that support graceful restart. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LDP Graceful Restart | 893 
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| holddown-interval 


Syntax 


holddown-interval holddown-interval; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp oam bfd-livenesss-detection], 

[edit logical-systems logical-system-name protocols Idp oam fec address bfd-livenesss-detection], 
[edit protocols Idp oam bfd-livenesss-detection], 

[edit protocols Idp oam fec address bfd-livenesss-detection] 


Release Information 
Statement introduced in Junos OS Release 9.4. 


Description 
Specify how long the BFD session should be up before adding the route or next hop. Specifying a time of 
O seconds causes the route or next hop to be added as soon as the BFD session comes back up. 


Options 
holddown-interval—Number of seconds the BFD session should remain up before adding the route or next 
hop. 

Default: 0 seconds 

Range: O through 65,535 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Holddown Interval for the BFD Session | 913 
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hold-time (Protocols LDP) 


Syntax 


hold-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp interface interface-name], 

[edit logical-systems logical-system-name protocols Idp targeted-hello], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp interface 
interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp targeted-hello], 

[edit protocols Idp interface interface-name], 

[edit protocols Idp targeted-hello], 

[edit routing-instances routing-instance-name protocols Idp interface interface-name], 

[edit routing-instances routing-instance-name protocols Idp targeted-hello] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Support for LDP targeted hellos added in Junos OS Release 9.5. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Specify how long an LDP node should wait for a hello message before declaring a neighbor to be down. 
This value is sent as part of a hello message so that each LDP node tells its neighbors how long to wait. 
You can specify times for both link hello messages and targeted hello messages depending on the hierarchy 
level at which you configure the hold-time statement. 


Options 
seconds—Hold-time value. 
Range: 1 through 65,535 seconds 


Default: 15 seconds for link hello messages, 45 seconds for targeted hello messages 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Delay Before LDP Neighbors Are Considered Down | 870 
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| ignore-Isp-metrics 
Syntax 


ignore-Isp-metrics; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf traffic-engineering shortcuts], 
[edit protocols ospf traffic-engineering shortcuts] 


Release Information 
Statement introduced in Junos OS Release 7.5. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Cause OSPF to ignore the RSVP LSP metric. 


Some other vendors use an OSPF metric of 1 for the loopback address. Juniper Networks routers use an 
OSPF metric of O for the loopback address. This can cause interoperability problems when you configure 
LDP tunneling over RSVP LSPs in heterogeneous networks. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Enabling LDP over RSVP-Established LSPs in Heterogeneous Networks | 1047 
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| igp-synchronization 
Syntax 


igp-synchronization holddown-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 9.5. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Configure the time the LDP waits before informing the IGP that the LDP neighbor and session for an 
interface are operational. For large networks with numerous FECs, you might need to configure a longer 
value to allow enough time for the LDP label databases to be exchanged. 


Options 
holddown-interval seconds—Time the LDP waits before informing the IGP that the LDP neighbor and 
session for an interface are operational. 

Default: 10 seconds 

Range: 10 through 60 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LDP Synchronization with the IGP on the Router | 1051 
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| import (Protocols LDP) 


Syntax 


import [ policy-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Apply policy filters to received LDP label bindings. Filters are applied to all label bindings from all neighbors. 


Options 


policy-names—Name of one or more routing policies. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Filtering Inbound LDP Label Bindings | 896 
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| ingress-policy 
Syntax 


ingress-policy [ ingress-policy-names ]; 


Hierarchy Level 


[edit logical-system logical-system-name protocols Idp entropy-label], 
[edit logical-system logical-system-name protocols Idp oam], 

[edit protocols Idp entropy-label], 

[edit protocols Idp oam] 


Release Information 

Statement introduced in Junos OS Release 9.4. 

Statement introduced at the [edit protocols Idp entropy-label] hierarchy level in Junos OS Release 14.1. 
Statement introduced in Junos OS Release 17.2R1 for QFX10000 Series switches. 


Description 


Configure an LDP ingress policy for either the entropy label or Operation, Administration, and Management 
(OAM). 


For OAM, configure the ingress policy to choose which forwarding equivalence classes (FECs) need to 
have OAM enabled. If the FEC passes through the policy or if the FEC is explicitly configured, OAM is 
enabled for a FEC. For FECs chosen using a policy, the BFD parameters configured under [edit protocols 
Idp oam bfd-liveness-detection] are applied. 


Options 


ingress-policy-names—Specify the names of the ingress policies. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring OAM Ingress Policies for LDP | 1148 
Configuring the Entropy Label for LSPs | 534 
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| interface (Protocols LDP) 


Syntax 


interface interface-name { 
disable; 
hello-interval seconds; 
hold-time seconds; 
transport-address (interface | loopback); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Enable LDP on one or more router interfaces. 


Default 


LDP is disabled on all interfaces. 


Options 


interface-name—Name of an interface. To configure all interfaces, specify all. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Enabling and Disabling LDP | 868 
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| keepalive-interval 


Syntax 


keepalive-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Set the keepalive interval value. 


Options 

seconds—Keepalive value. 
Range: 1 through 65,535 
Default: 10 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Interval for LDP Keepalive Messages | 871 
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| keepalive-timeout 


Syntax 


keepalive-timeout seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Set the keepalive timeout value. The keepalive timeout defines the amount of time that the neighbor LDP 
node waits before determining that the session has failed. 


Options 

seconds—Keepalive timeout value. 
Range: 1 through 65,535 
Default: 30 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the LDP Keepalive Timeout | 872 
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| |2-smart-policy 
Syntax 


|2-smart-policy; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 8.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Prevent LDP from exporting IPv4 FECs over sessions with Layer 2 neighbors only. IPv4 FECs received 
over such sessions are filtered out. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LDP IPv4 FEC Filtering | 907 


2108 


| label-withdrawal-delay 


Syntax 


label-withdrawal-delay seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 9.1. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Delay the withdrawal of labels to reduce router workload during IGP convergence. 


Options 

seconds—Configure the number of seconds to wait before withdrawing labels for the LDP LSPs. 
Default: 60 seconds 
Range: O through 300 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Label Withdrawal Timer | 1051 
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| Idp 


Syntax 


Idp { 
auto-targeted-session; 
(deaggregate | no-deaggregate); 
dual-transport ; 
egress-policy [ policy-names ]; 
entropy-label; 
explicit-null; 
export [ policy-names ]; 
family (Protocols LDP); 
graceful-restart; 
igp-synchronization; 
import [ policy-names]; 
interface (interface-name | all); 
keepalive-interval seconds; 
keepalive-timeout seconds; 
log-updown; 
longest-match; 
make-before-break; 
neighbor; 
no-forwarding; 
oam; 
p2mp; 
policing; 
preference preference; 
session; 
session-group; 
session-protection; 
strict-targeted-hellos; 
traceoptions; 
track-igp-metric; 
traffic-statistics; 
transport-address (address | interface | router-id); 
transport-preference [ipv4 | ipv6]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols], 
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols], 
[edit protocols], 
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[edit routing-instances routing-instance-name protocols] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 11.1 for EX Series switches. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 

dual-transport statement introduced in Junos OS Release 16.1 for the M320 Series, MX Series, and PTX 
Series. 

family statement introduced in Junos OS Release 16.1 for the M320 Series, MX Series, and PTX Series. 
transport-preference option introduced in Junos OS Release 16.1 for the M320 Series, MX Series, and 
PTX Series. 


Description 


Enable LDP routing on the router or switch. 
You must include the Idp statement in the configuration to enable LDP on the router or switch. 


Default 
LDP is disabled on the router. 


Options 

transport-preference ipv4 | ipv6— Select the preferred transport for TCP connection when both IPv4 and 
IPvé6 are enabled. If transport-preference ipv4 is configured, LDP will attempt to establish the TCP 
connection using IPv4. If transport-preference ipvé is configured, LDP will attempt to establish the 
TCP connection using IPvé. 


Default: ipvé 


The remaining statements are explained separately. Search for a statement in CLI Explorer or click a linked 
statement in the Syntax section for details. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Minimum LDP Configuration | 868 
Enabling and Disabling LDP | 868 
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| Idp-synchronization 


Syntax 


Idp-synchronization { 
disable; 


hold-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf interface interface-name], 
[edit logical-systems logical-system-name routing-instances routing-instance-name 
protocols ospf interface interface-name], 

[edit protocols ospf interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf interface interface-name] 


Release Information 
Statement introduced in Junos OS Release 7.5. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Enable synchronization by advertising the maximum cost metric until LDP is operational on the link. 


Options 


The other statements are explained separately. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LDP Synchronization with the IGP on LDP Links | 1050 
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| log-updown (Protocols LDP) 


Syntax 


log-updown { 
trap disable; 
} 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Disable LDP traps on the router, logical system, or routing instance. 


Options 
trap disable—Disable LDP traps. 


Default: LDP traps are enabled on the router. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Disabling SNMP Traps for LDP | 1050 
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| make-before-break (LDP) 


Syntax 


make-before-break { 
timeout seconds; 
switchover-delay seconds; 


} 


Hierarchy Level 


[edit protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 12.3. 


Description 
Configures make before break (MBB) for multicast LDP (MLDP) link protection to ensure minimum packet 
loss when attempting to signal a new label-switched path (LSP) before tearing down the old LSP path. 


Options 

timeout seconds—Specify a value to change a make -before-break timeout for point-to-multipoint LSPs. 
Even if an MBB acknowledgment is not received for a point-to-multipoint LSP before the specified 
timeout period expires, the label-switching router (LSR) performs an MBB switchover from the old 
LSR to the new upstream LSR. 
Range: 1 through 300 seconds 
Default: 30 seconds 


switchover-delay seconds—Specify a value to change switchover delay for a point-to-multipoint LSP from 
the old LSR to the new upstream LSR. If an MBB acknowledgment is received on a point of local repair 
(PLR) router, the PLR waits for the specified seconds to switch its upstream LSR from the old LSR to 
the new LSR. 
Range: 1 through 300 seconds 
Default: 30 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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| Example: Configuring LDP Link Protection | 915 


| mapping-server-entry 


Syntax 


mapping-server-entry mapping-server-name { 
prefix-segment prefix; 
prefix-segment-range prefix-segment-range-name; 


Hierarchy Level 


[edit logical-systems name routing-instances name routing-options source-packet-routing], 
[edit logical-systems name routing-options source-packet-routing], 

[edit routing-instances name routing-options source-packet-routing], 

[edit routing-options source-packet-routing] 


Release Information 
Statement introduced in Junos OS Release 18.2R1. 


Description 
Configure an LDP mapping server to enable interoperability between islands of devices supporting only 
segment routing and only LDP in an LDP network domain. 


The mapping server configuration can be included an on any device in the segment routing network. 


Options 


mapping-server-entry-name—Name of the LDP mapping server. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing 
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| maximum-neighbor-recovery-time 
Syntax 


maximum-neighbor-recovery-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp graceful-restart], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp graceful-restart], 
[edit protocols Idp graceful-restart], 

[edit routing-instances routing-instance-name protocols Idp graceful-restart] 


Release Information 

Statement introduced before Junos OS Release 7.4. Statement changed from maximum-recovery-time 
to maximum-neighbor-recovery-time in Junos OS Release 9.1. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify the maximum amount of time to wait before giving up an attempt to gracefully restart. 


Options 

seconds—Configure the maximum recovery time, in seconds. 
Range: 120 through 1800 seconds 
Default: 140 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Recovery Time and Maximum Recovery Time | 895 
Configuring Graceful Restart Options for LDP 


recovery-time 
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| mldp-inband-signalling (Protocols Multipoint LDP) 


Syntax 


mldp-inband-signalling { 
policy policy-name; 


} 


Hierarchy Level 


[edit logical-systems logical-system-name protocols pim], 
[edit protocols pim], 


Release Information 

Statement introduced in Junos OS Release 13.2. 

Support added in Junos OS Release 18.2R1 for using this command in conjunction with distributed MLD 
or distributed IGMP. 


Description 
Multipoint LDP (mLDP) in-band signalling lets you carry multicast traffic across an existing IP/MPLS 
backbone, while avoiding the use of PIM in the provider core. 


On the label-edge router (LER), enable PIM to use mLDP in-band signaling for the upstream neighbors 
when the LER does not detect a PIM upstream neighbor. On the egress nodes, configure the MPLS LSP 
root in the PIM configuration, using the policy statement. 


When used in conjunction with distributed MLD or distributed IGMP, mLDP inband signalling supports 
interconnecting separate PIM domains via a MPLS-based core. To enable the inter-working, chassis 
network-services enhanced-ip must be enabled and you need to set the dynamic-profiles profile-name 
protocols igmp|mid interface interface-name to distributed. Enabling this command, mldp-inband-signalling, 
has PIM act as a multipoint LDP inband edge router. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Multipoint LDP In-Band Signaling for Point-to-Multipoint LSPs | 1003 
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| mofrr-asm-starg (Multicast-Only Fast Reroute in a PIM Domain) 


Syntax 


mofrr-asm-starg; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast 
stream-protection], 

[edit logical-systems logical-system-name routing-options multicast stream-protection], 

[edit routing-instances routing-instance-name routing-options multicast stream-protection], 

[edit routing-options multicast stream-protection] 


Release Information 
Statement introduced in Junos OS Release 14.1. 
Statement introduced in Junos OS Release 17.4R1 for QFX Series switches. 


Description 


Enable mofrr-asm-starg to include any-source multicast (ASM) for (*,G) joins in the Multicast-only fast 
reroute (MoFRR). 


NOTE: mofrr-asm-starg applies to IP-PIM only. When enabled for group G, *,G will undergo 
MoFRR as long as there is no S#,G for Group G. In other words, *,G MoFRR will cease and any 
old states will be torn down when S#,G is created. Note too, that mofrr-asm-starg is not supported 
for mLDP (since mLDP itself does not support *,G). 


In a PIM domain with MoFRR enabled, the default for stream-protection is S,G routes only. 


Context: Multicast-only fast reroute (MoFRR) can be used to reduce traffic loss in a multicast distribution 
tree in the event of link down. To employ MoFRR, a downstream router is configured with an alternative 
path back towards the source, over which it receives a backup live stream of the same multicast traffic. 
That router propagates the same (S,G) join toward both upstream neighbors in order to create duplicate 
multicast trees. If a failure is detected on the primary tree, the router switches to the backup tree to prevent 
packet loss. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Understanding Multicast-Only Fast Reroute | 945 
Example: Configuring Multicast-Only Fast Reroute ina PIM Domain 
Example: Configuring Multicast-Only Fast Reroute in a PIM Domain on Switches 


Example: Configuring Multicast-Only Fast Reroute in a Multipoint LDP Domain | 956 
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| mofrr-disjoint-upstream-only (Multicast-Only Fast Reroute in a PIM Domain) 


Syntax 


mofrr-disjoint-upstream-only; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast 
stream-protection], 

[edit logical-systems logical-system-name routing-options multicast stream-protection], 

[edit routing-instances routing-instance-name routing-options multicast stream-protection], 

[edit routing-options multicast stream-protection] 


Release Information 
Statement introduced in Junos OS Release 14.1. 
Statement introduced in Junos OS Release 17.4R1 for QFX Series switches. 


Description 
When you configure multicast-only fast reroute (MoFRR) in a PIM domain, allow only a disjoint RPF (an 
RPF on a separate plane) to be selected as the backup RPF path. 


In a multipoint LDP MoFRR domain, the same label is shared between parallel links to the same upstream 
neighbor. This is not the case in a PIM domain, where each link forms a neighbor. The 
mofrr-disjoint-upstream-only statement does not allow a backup RPF path to be selected if the path goes 
to the same upstream neighbor as that of the primary RPF path. This ensures that MoFRR is triggered only 
on a topology that has multiple RPF upstream neighbors. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding Multicast-Only Fast Reroute | 945 
Example: Configuring Multicast-Only Fast Reroute ina PIM Domain 


Example: Configuring Multicast-Only Fast Reroute in a PIM Domain on Switches 





Example: Configuring Multicast-Only Fast Reroute in a Multipoint LDP Domain | 956 
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| mofrr-no-backup-join (Multicast-Only Fast Reroute in a PIM Domain) 


Syntax 


mofrr-no-backup-join; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast 
stream-protection], 

[edit logical-systems logical-system-name routing-options multicast stream-protection], 

[edit routing-instances routing-instance-name routing-options multicast stream-protection], 

[edit routing-options multicast stream-protection] 


Release Information 
Statement introduced in Junos OS Release 14.1. 
Statement introduced in Junos OS Release 17.4R1 for QFX Series switches. 


Description 
When you configure multicast-only fast reroute (MoFRR) in a PIM domain, prevent sending join messages 
on the backup path, but retain all other MoFRR functionality. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding Multicast-Only Fast Reroute | 945 
Example: Configuring Multicast-Only Fast Reroute ina PIM Domain 
Example: Configuring Multicast-Only Fast Reroute in a PIM Domain on Switches 


Example: Configuring Multicast-Only Fast Reroute in a Multipoint LDP Domain | 956 
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| mofrr-primary-path-selection-by-routing (Multicast-Only Fast Reroute) 


Syntax 


mofrr-primary-path-selection-by-routing; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast 
stream-protection], 

[edit logical-systems logical-system-name routing-options multicast stream-protection], 

[edit routing-instances routing-instance-name routing-options multicast stream-protection], 

[edit routing-options multicast stream-protection] 


Release Information 
Statement introduced in Junos OS Release 14.1. 
Statement introduced in Junos OS Release 17.4R1 for QFX Series switches. 


Description 

MoFRR is supported on both equal-cost multipath (ECMP) paths and non-ECMP paths. Unicast loop-free 
alternate (LFA) routes need to be enabled to support MoFRR on non-ECMP paths. LFA routes are enabled 
with the link-protection statement in the interior gateway protocol (IGP) configuration. When you enable 
link protection on an OSPF or IS-IS interface, Junos OS creates a backup LFA path to the primary next 
hop for all destination routes that traverse the protected interface. 


In the context of load balancing, MoFRR prioritizes the disjoint backup in favor of load balancing the 
available paths. 


For Junos OS releases before 15.1R7, for both ECMP and Non-ECMP scenarios, the default MoFRR 
behavior was sticky , that is, if the Active link went down, the Active Path selection would give preference 
to Backup Path for the transition. The Active Path would not follow the unicast selected gateway 


Starting in Junos OS Release 15.1R7 however, the default behavior for non-EMCP scenarios is to be 
nonsticky, that is, the selection of Active Path strictly follows unicast selected gateway. MoFRR no longer 
chooses a unicast LFA path to become the MoFRR Active path; only a unicast LFA path can be selected 
to become MoFRR Backup. 


Default 


By default, the backup path gets promoted to be the primary path when MoFRR is configured in a PIM 
domain. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Understanding Multicast-Only Fast Reroute | 945 
Example: Configuring Multicast-Only Fast Reroute ina PIM Domain 
Example: Configuring Multicast-Only Fast Reroute in a PIM Domain on Switches 


Example: Configuring Multicast-Only Fast Reroute in a Multipoint LDP Domain | 956 


| neighbor (Protocols LDP) 


Syntax 


neighbor neighbor-address; 


Hierarchy Level 


[edit protocols Idp], 


Release Information 
Statement introduced in Junos OS Release 14.2R1 on all platforms. 


Description 


Configure an LDP targeted neighbor. 


LDP sends a targeted hello message to the configured remote neighbor with a targeted 

request-send-targeted hello message (T) bit set. If the remote neighbor allows receipt of asymmetric hello 
messages, or if it is configured with the source address as the targeted neighbor, it responds with a targeted 
hello message. The receipt of a targeted hello message establishes a targeted adjacency with the remote 
neighbor as described in RFC 5036. Subsequently, a targeted session is established to the remote neighbor. 


Options 
neighbor-address—IP address of the remote LDP neighbor. 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Minimum LDP Configuration | 868 
Enabling and Disabling LDP | 868 
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| no-forwarding 


Syntax 


no-forwarding; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Do not add ingress routes to the inet.0 routing table even if traffic-engineering bgp-igp (configured at the 
[edit protocols mpls] hierarchy level) is enabled. 


Default 


The no-forwarding statement is disabled. Ingress routes are added to the inet.O routing table instead of 
the inet.3 routing table when traffic-engineering bgp-igp is enabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Preventing Addition of Ingress Routes to the inet.0 Routing Table | 1046 


Configuring Virtual-Router Routing Instances in VPNs 
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| oam (Protocols LDP) 


Syntax 


oam { 
bfd-liveness-detection { 
detection-time threshold milliseconds; 
ecmp; 
failure-action { 
remove-nexthop; 
remove-route; 
} 
holddown-interval milliseconds; 
ingress-policy ingress-policy-name; 
minimum-interval milliseconds; 
minimum-receive-interval milliseconds; 
minimum-transmit-interval milliseconds; 
multiplier detection-time-multiplier, 
no-adaptation; 
transmit-interval { 
minimum-interval milliseconds; 
threshold milliseconds; 
} 
version (0 | 1 | automatic); 
} 
fec fec-address; 
ingress-policy ingress-policy-name; 
Isp-ping-interval seconds; 
periodic-traceroute { 
disable; 
exp exp-value; 
fanout fanout-value; 
frequency minutes; 
paths number-of-paths; 
retries retry-attempts; 
source address; 
ttl ttl-value; 


wait seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp] 
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[edit protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 7.6. 
Isp-ping-interval option introduced in Junos OS Release 9.4. 


Description 
Configure Operation, Administration, and Maintenance (OAM) and Bidirectional Forwarding Detection 
(BFD) protocol for LDP. 


Options 
fec fec-address—Specify the forwarding equivalence class (FEC) address. You must either specify a FEC 
address or configure an OAM ingress policy to ensure that the BFD session comes up. 


Isp-ping-interval seconds—Specify the duration of the LSP ping interval in seconds. To issue a ping on an 
LDP-signaled LSP, use the ping mpls Idp command. 

Default: 60 seconds 

Range: 30 through 3,600 seconds 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring BFD for LDP LSPs | 908 
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| p2mp (Protocols LDP) 


Syntax 


p2mp { 
no-rsvp-tunneling; 
recursive; 


root-address root-address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 11.2. 
no-rsvp-tunneling option added in Junos OS Release 16.1R5. 


Description 
Enable point-to-multipoint MPLS LSPs in an LDP-signaled LSP. 


Options 
no-rsvp-tunneling—(Optional) Disable LDP point-to-multipoint LSPs from using RSVP-TE LSPs for tunneling, 
and use LDP paths instead. 


NOTE: The no-rsvp-tunneling option is introduced in Junos OS Release 16.1R5, 17.3R1, 
17.2R2, 16.2R3, and later releases. 


Starting in Junos OS Release 12.3R1, Junos OS provides support for Multipoint LDP (M-LDP) for 
Targeted LDP (T-LDP) sessions with unicast replication, in addition to link sessions. As a result, the 
default behavior of M-LDP over RSVP tunneling is similar to unicast LDP. However, because T-LDP 
is chosen over LDP and link sessions to signal point-to-multipoint LSPs, the no-rsvp-tunelling option 
enables LDP natively throughout the network. 


recursive—(Optional) Configure point-to-multipoint recursive parameters, including route. 


root-address root-address—(Optional) Specify the root address of the point-to-multipoint LSP. 


Required Privilege Level 


2127 


routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Point-to-Multipoint LDP LSPs as the Data Plane for Intra-AS MBGP MVPNs 
Point-to-Multipoint LSPs Overview | 657 
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| p2mp-ldp-next-hop 
Syntax 


p2mp-ldp-next-hop { 
root-address root-address{ 
Isp-id id; 
} 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options static route 
destination-prefix], 

[edit logical-systems logical-system-name routing-options static route destination-prefix], 

[edit routing-instances routing-instance-name routing-options static route destination-prefix]. 

[edit routing-options static route destination-prefix] 


Release Information 
Statement introduced in Junos OS Release 13.3. 


Description 

Specify a point-to-multipoint LDP label-switched path (LSP) as the next hop for a static route, and configure 
a root and provide an Isp-id on that LDP-signalled label-switched path. 

Options 


root-address root address— Specify the root address of the point-to-multipoint LSP. 


Isp-id id— Specify the generic LSP identifier. The range is 1 through 65535. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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periodic-traceroute 


Syntax 


periodic-traceroute { 
disable; 
exp exp-value; 
fanout fanout-value; 
frequency minutes; 
paths number-of-paths; 
retries retry-attempts; 
source address; 
ttl ttl-value; 


wait seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp oam], 

[edit logical-systems logical-system-name protocols Idp oam fec fec-address], 
[edit protocols Idp oam], 

[edit protocols Idp oam fec fec-address] 


Release Information 

Statement introduced in Junos OS Release 8.4. 

Support added at the [edit protocols Idp oam] and [edit logical-systems logical-system-name protocols Idp 
oan] hierarchy levels in Junos OS Release 9.0. 

Statement introduced in Junos OS Release 12.2 for EX Series switches. 


Description 


Enable tracing of forwarding equivalence classes (FECs) for LDP LSPs. 


Options 

disable—(Optional) Disable tracing for a specific FEC. This option is available at the [edit protocols Idp 
oam fec fec-address periodic-traceroute] and [edit logical-systems logical-system-name protocols Idp oam 
fec fec-address periodic-traceroute] hierarchy levels only. 


exp exp-value—(Optional) Specify the class of service to use when sending probes. 
Default: 7 
Range: O through 7 


fanout fanout-value—(Optional) Specify the maximum number of next hops to search per node. 
Default: 16 


2130 


Range: 1 though 16 


frequency minutes—(Optional) Specify the interval between traceroute attempts. 
Default: 60 minutes 


Range: 15 through 120 minutes 


paths number-of-paths—(Optional) Specify the maximum number of paths to search. 
Default: 3 
Range: 1 through 255 


retries retry-attempts—(Optional) Specify the number of attempts to senda probe to a specific node before 
giving up. 

Default: 3 

Range: 1 through 9 


source address—(Optional) Specify the IPv4 source address to use when sending probes. 


ttl value—(Optional) Specify the maximum time-to-live value. Nodes that are beyond this value are not 
traced. 


Default: 64 
Range: 1 through 255 


wait seconds—(Optional) Specify the wait interval before resending a probe packet. 
Default: 10 seconds 
Range: 5 though 15 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LDP LSP Traceroute | 1052 
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| policing (Protocols LDP) 


Syntax 


policing { 
fec fec-address { 
ingress-traffic filter-name; 
transit-traffic filter-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Enable policing of forwarding equivalence classes (FECs) for LDP. 


Options 
fec fec-address—Specify the address for the FEC. 


ingress-traffic filter-name—Specify the name of the filter for policing ingress FEC traffic. 


transit-traffic filter-name—Specify the name of the filter for policing transit FEC traffic. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Policers for LDP FECs | 906 
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| policy (Multicast-Only Fast Reroute) 


Syntax 


policy policy-name; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast 
stream-protection], 

[edit logical-systems logical-system-name routing-options multicast stream-protection], 

[edit routing-instances routing-instance-name routing-options multicast stream-protection], 

[edit routing-options multicast stream-protection] 


Release Information 
Statement introduced in Junos OS Release 14.1. 
Statement introduced in Junos OS Release 17.4R1 for QFX Series switches. 


Description 

When you configure multicast-only fast reroute (MoFRR), apply a routing policy that filters for a restricted 
set of multicast streams to be affected by your MoFRR configuration. You can apply filters that are based 
on source or group addresses. 


For example: 


routing-options { 
multicast { 
stream-protection { 
policy mofrr-select; 


} 
policy-statement mofrr-select { 
termA { 
from { 
source-address-filter 225.1.1.1/32 exact; 
} 
then { 
accept; 


term B { 
from { 


source-address-filter 226.0.0.0/8 orlonger; 
} 
then { 

accept; 


} 
term C { 
from { 
source-address-filter 227.1.1.0/24 orlonger; 
source-address-filter 227.4.1.0/24 orlonger; 
source-address-filter 227.16.1.0/24 orlonger; 
} 
then { 
accept; 


} 
term D { 
from { 
source-address-filter 227.1.1.1/32 exact; 


} 
then { 
reject; #MoFRR disabled 


} 
term E { 
from { 
route-filter 227.1.1.0/24 orlonger; 
} 


then accept; 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Understanding Multicast-Only Fast Reroute | 945 
Example: Configuring Multicast-Only Fast Reroute ina PIM Domain 
Example: Configuring Multicast-Only Fast Reroute in a PIM Domain on Switches 


Example: Configuring Multicast-Only Fast Reroute in a Multipoint LDP Domain | 956 
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| policy (Protocols Multipoint LDP) 


Syntax 


policy policy-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols pim mldp-inband-signalling], 
[edit protocols pim mldp-inband-signalling] 


Release Information 
Statement introduced in Junos OS Release 13.2. 


Description 
Multipoint LDP (M-LDP) in-band signaling enables you to carry multicast traffic across an existing IP/MPLS 
backbone, while avoiding the use of PIM in the provider core. 


On the egress nodes of the point-to-multipoint LSP, specify an M-LDP join translation filter policy where 
PIM messages are translated into M-LDP FEC bindings. The policy statement is needed when internal BGP 
(IBGP) is not available in the core site or to override IBGP-based LSP root detection. 


The filter policy is configured at the [edit policy-options] hierarchy level. The policy generally specifies 
one or more source-address filters and the point-to-multipoint LDP root IP address using the p2mp-Isp-root 
policy action. 


Options 


policy-name—Name of a policy configured at the [edit policy-options] hierarchy level. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Multipoint LDP In-Band Signaling for Point-to-Multipoint LSPs | 1003 
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| preference (Protocols LDP) 


Syntax 


preference preference; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit protocols Idp interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit protocols Idp interface interface-name], 

[edit routing-instances routing-instance-name protocols Idp interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Set the route preference level for LDP routes. 


Options 
preference—Preferred value. 
Range: O through 255 
Default: 9 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LDP Route Preferences | 892 
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| prefix-segment (Routing Options) 
Syntax 


prefix-segment prefix-segment { 
index index; 


Hierarchy Level 


[edit logical-systems name routing-instances name routing-options source-packet-routing mapping-server-entry], 
[edit logical-systems name routing-options source-packet-routing mapping-server-entry], 

[edit routing-instances name routing-options source-packet-routing mapping-server-entry], 

[edit routing-options source-packet-routing mapping-server-entry] 


Release Information 
Statement introduced in Junos OS Release 18.2R1. 


Description 


Configure the IP address and index number of the prefix segment for the LDP mapping server. 


Options 


prefix-segment—IP address of the prefix segment. 


index index—Prefix segment index. 
Range: O through 199999 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


LDP Mapping Server for Interoperability of Segment Routing with LDP Overview | 1040 
source-packet-routing | 2147 
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| prefix-segment-range 
Syntax 


prefix-segment-range prefix-segment-range-name { 
attached; 
domain-wide-flooding; 
no-node-segment; 
size size; 
start-index start-index; 


start-prefix start-prefix; 


Hierarchy Level 


[edit logical-systems name routing-instances name routing-options source-packet-routing mapping-server-entry], 
[edit logical-systems name routing-options source-packet-routing mapping-server-entry], 

[edit routing-instances name routing-options source-packet-routing mapping-server-entry], 

[edit routing-options source-packet-routing mapping-server-entry] 


Release Information 
Statement introduced in Junos OS Release 18.2R1. 
attached, domain-wide-flooding, and no-node-segment options introduced in Junos OS Release 19.1R1. 


Description 


Configure the prefix segment range for the LDP mapping server. 


Options 


prefix-segment-range-name—Name of the prefix segment range. 


attached—(Optional) Set the flag in IS-IS mapping server advertisement to indicate that the prefixes and 
SIDs advertised in the SID or Label Binding TLV are directly connected to their originators. 


domain-wide-flooding—(Optional) Set an S flag in the IS-IS mapping server advertisement to indicate that 
the SID or Label Binding TLV is flooded across the entire routing domain. 


no-node-segment—(Optional) Clear the node segment flag in the mapping server prefix segment to indicate 
that the prefix has originated from a single node. 


size size—Size of prefix segment range. 
Range: 1 through 1024 


start-index start-index—Include start index. 
Range: O through 199999 
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start-prefix start-prefix—Include start prefix. 


Required Privilege Level 
e routing—To view this statement in the configuration. 


e routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


LDP Mapping Server for Interoperability of Segment Routing with LDP Overview | 1040 
source-packet-routing | 2147 
mapping-server-entry | 2114 
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| reconnect-time 


Syntax 


reconnect-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp graceful-restart], 
[edit protocols Idp graceful-restart], 
[edit routing-instances routing-instance-name protocols Idp graceful-restart] 


Release Information 
Statement introduced in Junos OS Release 9.1. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Specify the length of time required to reestablish a Label Distribution Protocol (LDP) session after graceful 
restart. 


Options 

seconds—Time required for reconnection. 
Range: 30 through 300 
Default: 60 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LDP Graceful Restart | 893 on MPLS Applications User Guide 
Configuring Graceful Restart Options for LDP 
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| recovery-time 


Syntax 


recovery-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp graceful-restart], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp graceful-restart], 
[edit protocols Idp graceful-restart], 

[edit routing-instances routing-instance-name protocols Idp graceful-restart] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify the amount of time a router waits for LDP to restart gracefully. 


Options 

seconds—Configure the recovery time, in seconds. 
Range: 120 through 1800 seconds 
Default: 140 seconds 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Recovery Time and Maximum Recovery Time | 895 
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| session (Protocols LDP) 


Syntax 


session session-address { 
authentication-algorithm (aes-128-cmac-96 | hmac-sha-1-96 | md5); 
authentication-key authentication-key; 
authentication-key-chain authentication-key-chain; 
downstream-on-demand downstream-on-demand; 
(mtu-discovery | no-mtu-discovery); 
transport-address transport-address; 


Hierarchy Level 


[edit logical-systems name protocols Idp], 

[edit logical-systems name routing-instances name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances name protocols Idp] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

authentication-algorithm statement introduced in Junos OS Release 7.6. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 
transport-address option introduced in Junos OS Releasse 19.1R1 for all platforms. 


Description 


Configure LDP session parameters by specifying the session destination address. 


Options 


session-address—Session destination address. 


authentication-algorithm—Authentication algorithm name. 


Values: 
e aes-128-cmac-96—Cipher-based Message Authentication Code (AES128) (96 bits). 


e hmac-sha-1-96—Hash-based Message Authentication Code (SHA1) (96 bits). 


e md5—Message Digest 5. 


authentication-key—MD5 authentication key. 
authentication-key-chain—Key chain name. 


downstream-on-demand—Configure downstream on demand label distribution mode. 
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mtu-discovery—Enable TCP path MTU discovery. 
no-mtu-discovery—Disable TCP path MTU discovery. 


transport-address transport-address—|P address used for TCP sessions to the LDP neighbors that have 
targeted-LDP adjacencies. 


You cannot configure this statement for LDP sessions that have discovered adjacencies. 


The transport-address configuration can be rejected at the time of validation, if there is no interface 
with the configured IP address. 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Configuring the TCP MD5 Signature for LDP Sessions | 1048 
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| session-group 
Syntax 


session-group name { 
authentication-algorithm (aes-128-cmac-96 | hmac-sha-1-96 | md5); 
authentication-key authentication-key; 
authentication-key-chain authentication-key-chain; 
downstream-on-demand; 
(mtu-discovery | no-mtu-discovery); 
transport-address transport-address; 


Hierarchy Level 


[edit logical-systems name protocols Idp], 

[edit logical-systems name routing-instances name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances name protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 16.1. 
transport-address option introduced in Junos OS Releasse 19.1R1 for all platforms. 


Description 


Specify the prefix address of the aggregated group of LDP neighbors for the remote end of the LDP session. 


The session-group statement is useful when an LDP neighbor is dynamic; for instance, in the case of 
remote loop free alternate (LFA), a targeted or indirect LDP neighbor is automatically picked from any of 
the nodes in the network. 


The session-group statement can also be used for configuring authentication for a prefix group, as LDP 
authentication for all sessions or authentication at the interface level is not supported. 


The remaining statements are explained separately. See CLI Explorer. 


Options 


name-—Session destination address or prefix length. 


authentication-algorithm—Authentication algorithm name. 


Values: 
e aes-128-cmac-96—Cipher-based Message Authentication Code (AES128) (96 bits) 


e hmac-sha-1-96—Hash-based Message Authentication Code (SHA1) (96 bits) 
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e md5—Message Digest 5 


authentication-key—MD5 authentication key. 

authentication-key-chain—Authentication key chain name. 
downstream-on-demand—Configure downstream on demand label distribution mode. 
mtu-discovery | no-mtu-discovery—Enable and disable TCP path MTU discovery, respectively. 


transport-address transport-address—|P address used for TCP sessions to the LDP neighbors that have 
targeted-LDP adjacencies, and fall under the same IP subnet. 


You cannot configure this statement for LDP sessions that have discovered adjacencies. 


The transport-address configuration can be rejected at the time of validation, if there is no interface 
with the configured IP address. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the TCP MD5 Signature for LDP Sessions | 1048 
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| session-protection 


Syntax 


session-protection { 
timeout seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Description 

Configure when an LDP session is torn down and resignaled after the router stops receiving hello messages 
from a neighboring router. You might want to modify this behavior to prevent an LDP session from being 
unnecessarily terminated and reestablished. The LDP session remains up for the duration specified as long 
as the routers maintain IP network connectivity. 


Options 
timeout seconds—Time in seconds before the LDP session is torn down and resignaled. 
Range: 1 through 65,535 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LDP Session Protection | 1050 
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| source-packet-routing 


Syntax 


mapping-server-entry mapping-server-entry; 


Hierarchy Level 


[edit logical-systems name routing-instances name routing-options], 
[edit logical-systems name routing-options], 

[edit routing-instances name routing-options], 

[edit routing-options] 


Release Information 
Statement introduced in Junos OS Release 18.2R1. 


Description 
Configure interoperability between islands of devices supporting only segment routing and LDP in an LDP 
network domain where there is gradual deployment of segment routing. 


Required Privilege Level 
routing 
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| stream-protection (Multicast-Only Fast Reroute) 


Syntax 


stream-protection { 
mofrr-asm-starg; 
mofrr-disjoint-upstream-only; 
mofrr-no-backup-join; 
mofrr-primary-path-selection-by-routing; 
policy policy-name; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name routing-options multicast], 
[edit logical-systems logical-system-name routing-options multicast], 

[edit routing-instances routing-instance-name routing-options multicast], 

[edit routing-options multicast] 


Release Information 
Statement introduced in Junos OS Release 14.1. 
Statement introduced in Junos OS Release 17.4R1 for QFX Series switches. 


Description 


Enable multicast-only fast reroute (MoFRR) on a routing or switching device. MoFRR minimizes packet 
loss in a network when there is a link failure. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding Multicast-Only Fast Reroute | 945 
Example: Configuring Multicast-Only Fast Reroute in a PIM Domain 


Example: Configuring Multicast-Only Fast Reroute in a PIM Domain on Switches 





Example: Configuring Multicast-Only Fast Reroute in a Multipoint LDP Domain | 956 
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| strict-targeted-hellos 


Syntax 


strict-targeted-hellos; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Prevent LDP sessions from being established with remote neighbors that have not been specifically 
configured. LDP peers will not respond to targeted hellos coming from a source that is not one of the 
configured remote neighbors. 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Enabling Strict Targeted Hello Messages for LDP | 871 
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| targeted-hello 


Syntax 


targeted-hello { 
hello-interval seconds; 
hold-time seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced in Junos OS Release 9.5. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Specify the LDP timer and LDP hold time for targeted hellos. 


Options 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the LDP Timer for Hello Messages | 869 
Configuring the Delay Before LDP Neighbors Are Considered Down | 870 
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| traceoptions (Protocols LDP) 


Syntax 


traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag <flag-modifier> <disable>; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

match-on address option for the filter flag modifier added in Junos OS Release 10.4. 
nsr-synchronization and p2mp-nsr-synchronization operations for flag statement introduced in Junos OS 
Release 13.3. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Specify LDP protocol-level trace options. 


Default 


The default LDP protocol-level trace options are inherited from the routing protocols traceoptions statement 
included at the [edit routing-options] hierarchy level. 


Options 
disable—(Optional) Disable the tracing operation. You can use this option to disable a single operation 
when you have defined a broad group of tracing operations, such as all. 


file filename—Name of the file to receive the output of the tracing operation. Enclose the name within 
quotation marks. All files are placed in the directory Idp-log. We recommend that you place LDP tracing 
output in the file Idp-log. 


files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its 
maximum size, it is renamed trace-file.0, then trace-file.1, and so on, until the maximum number of trace 
files is reached. Then the oldest trace file is overwritten. 

Range: 2 through 1000 

Default: 2 files 
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If you specify a maximum number of files, you must also include the size statement to specify the maximum 
file size. 


flag flag—Tracing operation to perform. To specify more than one tracing operation, include multiple flag 
statements. 


e address—Operation of address and address withdrawal messages 
e binding—Label-binding operations 


error—Error conditions 


event—Protocol events 


initialization—Operation of initialization messages 


label—Operation of label request, label map, label withdrawal, and label release messages 


notification—Operation of notification messages 


nsr-synchronization— Nonstop active routing synchronization events 


e p2mp-nsr-synchronization—Point-to-multipoint nonstop active routing synchronization events 


packets—Equivalent to setting address, initialization, label, notification, and periodic flags (see also the 
filter flag modifier) 


path—Label-switched path operations 


periodic—Operation of hello and keepalive messages 
e route—Operation of route messages 
e state—Protocol state transitions 


flag-modifier—(Optional) Modifier for the tracing flag. You can specify one or more of these modifiers: 


e detail—Provide detailed trace information. 
e disable—Disable this trace flag. 


e filter—Filter to apply to this flag. The filter flag modifier can be applied only to the route, path, and 
binding flags. This flag modifier has the following options: 


e match-on—Match on argument specified. The match-on option has the following suboptions: 


e address—Filter based on the source and destination addresses of packets. Available for the packets 
flag option only. 


e fec—Filter based on the FEC associated with the traced object. 
e policy policy-name—Specify the filter policy. 
e receive—Packets being received. 


e send—Packets being transmitted. 
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no-world-readable—(Optional) Prevent all users from reading the log file. 


size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB), or gigabytes (GB). 
When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again 
reaches this size, trace-file.O is renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming 
scheme continues until the maximum number of trace files is reached. Then the oldest trace file is 
overwritten. 


Syntax: xk to specify KB, xm to specify MB, or xg to specify GB 
Range: 10 KB through the maximum file size supported on your system 
Default: 1. MB 


If you specify a maximum file size, you must also include the files statement to specify the maximum 
number of files. 


world-readable—(Optional) Enable any user to read the log file. 


Required Privilege Level 
routing and trace—To view this statement in the configuration. 
routing-control and trace-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Tracing LDP Protocol Traffic | 1056 


Network Management and Monitoring Guide 
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| track-igp-metric 
Syntax 


track-igp-metric; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 

Statement introduced in Junos OS Release 18.4R1 on MX5, MX10, MX40, MX104, MX204, MX240, 
MX480, MX960, MX2008, MX2010, MX2020, MX10003, and MX10008 routers. 

Statement introduced in Junos OS Release 18.4R1 on PTX1000, PTX3000, PTX5000, PTX10002-60C, 
PTX10008, and PTX10016 routers. 


Description 
Cause the IGP route metric to be used for the LDP routes instead of the default LDP route metric (the 
default LDP route metric is 1). 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LDP to Use the IGP Route Metric | 1045 
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| track-igp-metric (LSP) 
Syntax 


track-igp-metric <install-v4-prefixes> <install-v6-prefixes>; 


Hierarchy Level 


The hierarchy level for track-igp-metric globally enabled for all LSPs: 


[edit protocols mpls] 


The hierarchy level for track-igp-metric at the per LSP level: 


[edit protocols mpls label-switched-pathpathname], 
Release Information 
Statement introduced in Junos OS Release 18.4R1. 


Description 


Track IGP metric for LSP install prefixes 


Options 


install-v4-prefixes—Track IGP metric for IPV4 prefixes. 


install-v6-prefixes—Track IGP metric for IPV6 prefixes. 


Required Privilege Level 
routing 


RELATED DOCUMENTATION 


Install Prefix IGP Overview 
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| traffic-statistics (Protocols LDP) 


Syntax 


traffic-statistics { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
interval seconds; 
no-penultimate-hop; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit routing-instances routing-instance-name protocols Idp] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


LDP traffic statistics display the amount of traffic passed through a router for a particular FEC. 


Options 
file filename—Name of the file to receive the output of the LDP statistics operation. Enclose the name 
within quotation marks. All files are placed in the directory /var/log. 


files number—(Optional) Maximum number of LDP statistics files. When a statistics file named Idp-stat 
reaches its maximum size, it is renamed Idp-stat.0, then Idp-stat.1, and so on, until the maximum number 
of LDP statistics files is reached. Then the oldest file is overwritten. 


Range: 2 through 1000 
Default: 2 files 


If you specify a maximum number of files, you also must include the size statement to specify the maximum 
file size. 


interval seconds—(Optional) Specify the interval at which the statistics are polled and written to the file. 
Default: 300 seconds (5 minutes) 


no-penultimate-hop—(Optional) Do not collect traffic statistics on the penultimate hop router. 


no-world-readable—(Optional) Prevent all users from reading the log file. 
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size size—(Optional) Maximum size of each statistics file, in kilobytes (KB), megabytes (MB), or gigabytes 
(GB). When a statistics file named Idp-stat reaches this size, it is renamed Idp-stat.0. When Idp-stat again 
reaches this size, Idp-stat.0 is renamed Idp-stat.1 and Idp-stat is renamed Idp-stat.0. This renaming scheme 
continues until the maximum number of statistics files is reached. Then the oldest statistics file is overwritten. 

Syntax: xk to specify KB, xm to specify MB, or xg to specify GB 

Range: 10 KB through the maximum file size supported on your system 

Default: 1 MB 


If you specify a maximum file size, you also must also include the files statement to specify the maximum 
number of files. 


world-readable—(Optional) Enable log file access for all users. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Collecting LDP Statistics | 1053 
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| transport-address 


Syntax 


transport-address (address | interface | router-id); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp], 

[edit logical-systems logical-system-name protocols Idp interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols Idp], 
[edit protocols Idp], 

[edit protocols Idp interface interface-name], 

[edit routing-instances routing-instance-name protocols Idp interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 
address option introduced in Junos OS Release 19.1R1 for all platforms. 


Description 

Enables you to configure the IP address used to specify the TCP session for the LDP session. Routers must 
first establish a TCP session between one another before they can establish an LDP session. The TCP 
session enables the routers to exchange the label advertisements needed for the LDP session. To establish 
the TCP session, each router must learn the other router's transport address. The transport address is an 
IP address used to identify the TCP session over which the LDP session will run. 


Default 


router-id 


Options 


address—Use the specified IP address as the transport address for the LDP session. 


interface—Use the first IP address on the interface as the transport address for any LDP sessions to 
neighbors that can be reached over that interface. You cannot specify the interface option when there 
are multiple parallel links to the same LDP neighbor, because the LDP specification requires that the 
same transport address be advertised on all interfaces to the same neighbor. If LDP detects multiple 
parallel links to the same neighbor, it disables interfaces to that neighbor one by one until the condition 
is cleared, either by disconnecting the neighbor on an interface or by specifying the router-id option. 


router-id—Use router identifier as the transport address. Unless otherwise configured, the router identifier 
is the loopback address. 


Required Privilege Level 
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interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Specifying the Transport Address Used by LDP | 901 
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| version (BFD) 


Syntax 


version (0 | 1 | automatic); 


Hierarchy Level 


[edit logical-systems logical-system-name protocols Idp oam bfd-liveness-detection], 

[edit logical-systems logical-system-name protocols Idp oam fec address bfd-liveness-detection], 
[edit system services dhcp-local-server liveness-detection method bfd], 

[edit system services dhcp-local-server dhcpvé6 liveness-detection method bfd], 

[edit forwarding-options dhcp-relay liveness-detection method bfd], 

[edit forwarding-options dhcp-relay dhcpvé liveness-detection method bfd], 

[edit system services dhcp-local-server group group-name liveness-detection method bfd], 

[edit system services dhcp-local-server dhcpvé group group-name liveness-detection method bfd], 
[edit forwarding-options dhcp-relay group group-name liveness-detection method bfd], 

[edit forwarding-options dhcp-relay dhcpvé group group-name liveness-detection method bfd], 
[edit protocols Idp oam bfd-liveness-detection], 

[edit protocols Idp oam fec address bfd-liveness-detection] 


Release Information 
Statement introduced in Junos OS Release 12.1. 
Statement introduced in Junos OS Release 12.3R2 for EX Series switches. 


Description 


Configure the BFD protocol version to detect. 


Options 
O—Use BFD protocol version O. 


1—Use BFD protocol version 1. 


automatic—Autodetect the BFD protocol version. 


Default: automatic 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring Group Liveness Detection with BFD for DHCP Local Server Clients 
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Example: Configuring Global Liveness Detection with BFD for DHCP Relay Agent Clients 
Configuring BFD for LDP LSPs | 908 


CHAPTER 23 


CCC and TCC Configuration Statements 


IN THIS CHAPTER 


connections (Circuits) | 2163 
encapsulation (Logical Interface) | 2165 
encapsulation | 2170 

interface-switch | 2177 
|2circuit-control-passthrough | 2178 
Isp-switch | 2179 

output-interface (CCC) | 2180 
p2mp-receive-switch | 2181 
p2mp-transmit-switch | 2182 


remote-interface-switch | 2183 
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| connections (Circuits) 


Syntax 


connections { 
interface-switch connection-name { 
interface interface-name.unit-number, 
} 
Isp-switch connection-name { 
transmit-Isp label-switched-path; 
receive-|sp label-switched-path; 
} 
p2mp-receive-switch { 
output-interface [ interface-name.unit-number ]; 
receive-p2mp-lsp receiving-point-to-multipoint-Isp; 
} 
p2mp-transmit-switch { 
input-interface interface-name.unit-number; 
transmit-p2mp-lsp transmitting-point-to-multipoint-Isp; 
} 
remote-interface-switch connection-name { 
interface interface-name.unit-number,; 
receive-|sp label-switched-path; 
transmit-Isp label-switched-path; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols], 
[edit protocols] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Define the connection between two circuits in a CCC connection. 


Options 


The remaining statements are explained separately. See CLI Explorer. 


NOTE: The edit logical-systems hierarchy is not available on QFabric systems. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Layer 2 Switching Cross-Connects Using CCC | 1321 
Configuring MPLS LSP Tunnel Cross-Connects Using CCC | 1331 
Configuring TCC | 1336 

Configuring CCC Switching for Point-to-Multipoint LSPs | 1345 





2164 


2165 


| encapsulation (Logical Interface) 
Syntax 


encapsulation (atm-ccc-cell-relay | atm-ccc-vc-mux | atm-cisco-nlpid | atm-mlppp-lic | atm-nlpid | atm-ppp-lic | 
atm-ppp-vc-mux | atm-snap | atm-tcc-snap | atm-tcc-vc-mux | atm-vc-mux | ether-over-atm-llc | 
ether-vpls-over-atm-lIlc | ether-vpls-over-fr | ether-vpls-over-ppp | ethernet | ethernet-ccc | ethernet-vpls | 
ethernet-vpls-fr | frame-relay-ccc | frame-relay-ether-type | frame-relay-ether-type-tcc | frame-relay-ppp | 
frame-relay-tcc | gre-fragmentation | multilink-frame-relay-end-to-end | multilink-ppp | ppp-over-ether | 
ppp-over-ether-over-atm-llc | vlan-bridge | vlan-ccc | vlan-vci-ccc | vlan-tcc | vlan-vpls | vxlan); 


Hierarchy Level 


[edit interfaces interface-name unit logical-unit-number], 

[edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number], 
[edit interfaces rlsq number unit logical-unit-number] 

[edit protocols evpn] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 12.1X48 for PTX Series Packet Transport Routers 
(ethernet,vlan-ccc, and vlan-tcc options only). 

Statement introduced in Junos OS Release 12.2 for the ACX Series Universal Metro Routers. Only the 
atm-ccc-cell-relay and atm-ccc-vc-mux options are supported on ACX Series routers. 

Statement introduced in Junos OS Release 17.3R1 for QFX10000 Series switches (ethernet-ccc and 
vlan-ccc options only). 


Description 


Configure a logical link-layer encapsulation type. Not all encapsulation types are supported on the switches. 
See the switch CLI. 


Starting in Junos OS Release 20.1R1, aggregated ethernet interfaces supports VLAN TCC (Translational 
cross-connect) encapsulation on MX series platforms. See “Configuring VLAN TCC Encapsulation” on 
page 1305 for more details. Non-ethernet media types, SONET and ATM interfaces are only supported. It 
is expected that the user will have the member links of aggregated ethernet with supported hardware for 
configuring VLAN TCC encapsulation and no commit check is performed externally for the aggregated 
ethernet (AE) interfaces. 


Options 


atm-ccc-cell-relay—Use ATM cell-relay encapsulation. 


atm-ccc-vc-mux—Use ATM virtual circuit (VC) multiplex encapsulation on CCC circuits. When you use 
this encapsulation type, you can configure the ccc family only. 


atm-cisco-nlpid—Use Cisco ATM network layer protocol identifier (NLPID) encapsulation. When you use 
this encapsulation type, you can configure the inet family only. 


atm-mlppp-llc—For ATM2 IQ interfaces only, use Multilink Point-to-Point (MLPPP) over AAL5 LLC. For 
this encapsulation type, your router must be equipped with a Link Services or Voice Services PIC. MLPPP 
over ATM encapsulation is not supported on ATM2 IQ OC48 interfaces. 


atm-nlpid—Use ATM NLPID encapsulation. When you use this encapsulation type, you can configure the 
inet family only. 


atm-ppp-Ilc—(ATM2 IQ interfaces and MX Series routers with MPC/MIC interfaces using the ATM MIC 
with SFP only) Use PPP over AAL5 LLC encapsulation. 


atm-ppp-vc-mux—(ATM2 IQ interfaces and MX Series routers with MPC/MIC interfaces using the ATM 
MIC with SFP only) Use PPP over ATM AAL5 multiplex encapsulation. 


atm-snap—(All interfaces including MX Series routers with MPC/MIC interfaces using the ATM MIC with 
SFP) Use ATM subnetwork attachment point (SNAP) encapsulation. 


atm-tcc-snap—Use ATM SNAP encapsulation on translational cross-connect (TCC) circuits. 


atm-tcc-vc-mux—Use ATM VC multiplex encapsulation on TCC circuits. When you use this encapsulation 
type, you can configure the tcc family only. 


atm-vc-mux—(All interfaces including MX Series routers with MPC/MIC interfaces using the ATM MIC 
with SFP) Use ATM VC multiplex encapsulation. When you use this encapsulation type, you can configure 
the inet family only. 


ether-over-atm-llc—(All IP interfaces including MX Series routers with MPC/MIC interfaces using the ATM 
MIC with SFP) For interfaces that carry IP traffic, use Ethernet over ATM LLC encapsulation. When you 
use this encapsulation type, you cannot configure multipoint interfaces. 


ether-vpls-over-atm-Ilc—For ATM2 IQ interfaces only, use the Ethernet virtual private LAN service (VPLS) 
over ATM LLC encapsulation to bridge Ethernet interfaces and ATM interfaces over a VPLS routing instance 
(as described in RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5). Packets from the 
ATM interfaces are converted to standard ENET2/802.3 encapsulated Ethernet frames with the frame 
check sequence (FCS) field removed. 


ether-vpls-over-fr—For E1, T1, E3, T3, and SONET interfaces only, use the Ethernet virtual private LAN 
service (VPLS) over Frame Relay encapsulation to support Bridged Ethernet over Frame Relay encapsulated 
TDM interfaces for VPLS applications, per RFC 2427, Multiprotocol Interconnect over Frame Relay. 


NOTE: The SONET/SDH OC3/STM1 (Multi-Rate) MIC with SFP, the Channelized SONET/SDH 
OC3/STM1 (Multi-Rate) MIC with SFP, and the DS3/E3 MIC do not support Ethernet over Frame 
Relay encapsulation. 
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ether-vpls-over-ppp—For E1, T1, E3, T3, and SONET interfaces only, use the Ethernet virtual private LAN 
service (VPLS) over Point-to-Point Protocol (PPP) encapsulation to support Bridged Ethernet over 
PPP-encapsulated TDM interfaces for VPLS applications. 


ethernet—Use Ethernet II encapsulation (as described in RFC 894, A Standard for the Transmission of IP 
Datagrams over Ethernet Networks). 


ethernet-ccc—Use Ethernet CCC encapsulation on Ethernet interfaces. 


ethernet-vpls— Use Ethernet VPLS encapsulation on Ethernet interfaces that have VPLS enabled and that 
must accept packets carrying standard Tag Protocol ID (TPID) values. 


NOTE: The built-in Gigabit Ethernet PIC on an M7i router does not support extended VLAN 
VPLS encapsulation. 


ethernet-vpls-fr—Use in a VPLS setup when a CE device is connected to a PE router over a time-division 
multiplexing (TDM) link. This encapsulation type enables the PE router to terminate the outer layer 2 Frame 
Relay connection, use the 802.1p bits inside the inner Ethernet header to classify the packets, look at the 
MAC address from the Ethernet header, and use the MAC address to forward the packet into a given VPLS 
instance. 


frame-relay-ccc—Use Frame Relay encapsulation on CCC circuits. When you use this encapsulation type, 
you can configure the ccc family only. 


frame-relay-ether-type—Use Frame Relay ether type encapsulation for compatibility with Cisco Frame 
Relay. The physical interface must be configured with flexible-frame-relay encapsulation. 


frame-relay-ether-type-tcc—Use Frame Relay ether type TCC for Cisco-compatible Frame Relay on TCC 
circuits to connect different media. The physical interface must be configured with flexible-frame-relay 
encapsulation. 


frame-relay-ppp—Use PPP over Frame Relay circuits. When you use this encapsulation type, you can 
configure the ppp family only. 


frame-relay-tcc—Use Frame Relay encapsulation on TCC circuits for connecting different media. When 
you use this encapsulation type, you can configure the tcc family only. 


gre-fragmentation—For adaptive services interfaces only, use GRE fragmentation encapsulation to enable 
fragmentation of IPv4 packets in GRE tunnels. This encapsulation clears the do not fragment (DF) bit in 
the packet header. If the packet’ s size exceeds the tunnel’ s maximum transmission unit (MTU) value, the 
packet is fragmented before encapsulation. 


multilink-frame-relay-end-to-end—Use MLFR FRF.15 encapsulation. This encapsulation is used only on 
multilink, link services, and voice services interfaces and their constituent T1 or E1 interfaces, and is 
supported on LSQ and redundant LSQ interfaces. 
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multilink-ppp—Use MLPPP encapsulation. This encapsulation is used only on multilink, link services, and 
voice services interfaces and their constituent T1 or E1 interfaces. 


ppp-over-ether—Use PPP over Ethernet encapsulation to configure an underlying Ethernet interface for 
a dynamic PPPoE logical interface on M120 and M320 routers with Intelligent Queuing 2 (IQ2) PICs, and 
on MX Series routers with MPCs. 


ppp-over-ether-over-atm-lIlc—(MX Series routers with MPCs using the ATM MIC with SFP only) For 
underlying ATM interfaces, use PPP over Ethernet over ATM LLC encapsulation. When you use this 
encapsulation type, you cannot configure the interface address. Instead, configure the interface address 
on the PPP interface. 


vlan-bridge—Use Ethernet VLAN bridge encapsulation on Ethernet interfaces that have IEEE 802.1Q 
tagging, flexible-ethernet-services, and bridging enabled and that must accept packets carrying TPID 
Ox8100 or a user-defined TPID. 


vlan-ccc— Use Ethernet virtual LAN (VLAN) encapsulation on CCC circuits. When you use this encapsulation 
type, you can configure the ccc family only. 


vlan-vci-ccc—Use ATM-to-Ethernet interworking encapsulation on CCC circuits. When you use this 
encapsulation type, you can configure the ccc family only. 


vlan-tcc—Use Ethernet VLAN encapsulation on TCC circuits. When you use this encapsulation type, you 
can configure the tcc family only. 


vlan-vpls—Use Ethernet VLAN encapsulation on VPLS circuits. 


vxlan—Use VXLAN data plane encapsulation for EVPN. 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


Release History Table 


Release Description 


20,1R1 Starting in Junos OS Release 20.1R1, aggregated ethernet interfaces supports VLAN TCC 
(Translational cross-connect) encapsulation on MX series platforms. 
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RELATED DOCUMENTATION 


Configuring Layer 2 Switching Cross-Connects Using CCC | 1321 
Configuring the Encapsulation for Layer 2 Switching TCCs | 1336 
Configuring Interface Encapsulation on Logical Interfaces 

Configuring the CCC Encapsulation for LSP Tunnel Cross-Connects | 1332 
Circuit and Translational Cross-Connects Overview 

Identifying the Access Concentrator 

Configuring ATM Interface Encapsulation 

Configuring VLAN and Extended VLAN Encapsulation 

Configuring ATM-to-Ethernet Interworking 

Configuring Interface Encapsulation on PTX Series Packet Transport Routers 
Configuring CCC Encapsulation for Layer 2 VPNs 

Configuring TCC Encapsulation for Layer 2 VPNs and Layer 2 Circuits 
Configuring ATM for Subscriber Access 

Understanding CoS on ATM IMA Pseudowire Interfaces Overview 


Configuring Policing on an ATM IMA Pseudowire 
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| encapsulation 


List of Syntax 

Syntax for Physical Interfaces: M Series, MX Series, QFX Series, T Series, PTX Series on page 2170 
Syntax for Physical Interfaces: SRX Series on page 2170 

Syntax for Logical Interfaces: SRX Series on page 2170 


Syntax for Physical Interfaces: M Series, MX Series, QFX Series, T Series, PTX Series 


encapsulation (atm-ccc-cell-relay | atm-pvc | cisco-hdlc | cisco-hdlc-ccc | cisco-hdlc-tcc | ethernet-bridge | ethernet-ccc 
| ethernet-over-atm | ethernet-tcc | ethernet-vpls | ethernet-vpls-fr | ether-vpls-over-atm-llc | ethernet-vpls-ppp 
| extended-frame-relay-ccc | extended-frame-relay-ether-type-tcc | extended-frame-relay-tcc | 
extended-vlan-bridge | extended-vlan-ccc | extended-vlan-tcc | extended-vlian-vpls | flexible-ethernet-services | 
flexible-frame-relay | frame-relay | frame-relay-ccc | frame-relay-ether-type | frame-relay-ether-type-tcc | 
frame-relay-port-ccc | frame-relay-tcc | generic-services | multilink-frame-relay-uni-nni | ppp | ppp-ccc | ppp-tcc 


| vlan-ccc | vlan-vci-ccc | vlan-vpls); 


Syntax for Physical Interfaces: SRX Series 


encapsulation (ether-vpls-ppp | ethernet-bridge | ethernet-ccc | ethernet-tcc | ethernet-vpls | 
extended-frame-relay-ccc | extended-frame-relay-tcc | extended-vlan-bridge | extended-vlan-ccc | 
extended-vlan-tcc | extended-vlan-vpls | flexible-ethernet-services | frame-relay-port-ccc | vlan-ccc | vian-vpls); 


Syntax for Logical Interfaces: SRX Series 


encapsulation ( dix | ether-vpls-fr | frame-relay-ppp | ppp-over-ether | vlan-bridge | vlan-ccc | vlan-tcc | vlan-vpls ); 


Physical Interfaces: M Series, MX Series, QFX Series, T Series, PTX Series 


[edit interfaces interface-namel, 
[edit interfaces rlsq number:number] 


Logical Interfaces 


[edit interfaces interface-name unit logical-unit-number | 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.5. 

Statement introduced in Junos OS Release 11.1 for EX Series switches. 
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Statement introduced in Junos OS Release 12.1X48 for PTX Series Packet Transport Routers 
(flexible-ethernet-services, ethernet-ccc, and ethernet-tcc options only). 


Description 
For M Series, MX Series, QFX Series, T Series, PTX Series, specify the physical link-layer encapsulation 
type. 


For SRX Series, specify logical link layer encapsulation. 


NOTE: Not all encapsulation types are supported on the switches. See the switch CLI. 


Default 


ppp—Use serial PPP encapsulation. 


2172 


Physical Interface Options and Logical Interface Options 

[Warning: element unresolved in stylesheets: <title> (in <config-options>). This is probably a new element 
that is not yet supported in the stylesheets.] 

Physical Interface Options and Logical Interface Options 


For physical interfaces: 


NOTE: Frame Relay, ATM, PPP, SONET, and SATSOP options are not supported on EX Series 
switches. 


atm-ccc-cell-relay—Use ATM cell-relay encapsulation. 


e atm-pvc—Defined in RFC 2684, Multiprotocol Encapsulation over ATM Adaptation Layer 5. When you 
configure physical ATM interfaces with ATM PVC encapsulation, an RFC 2684-compliant ATM Adaptation 
Layer 5 (AALS) tunnel is set up to route the ATM cells over a Multiprotocol Label Switching (MPLS) path 
that is typically established between two MPLS-capable routers using the Label Distribution Protocol 
(LDP). 


cisco-hdlc—Use Cisco-compatible High-Level Data Link Control (HDLC) framing. E1, E3, SONET/SDH, 
T1, and T3 interfaces can use Cisco HDLC encapsulation. Two related versions are supported: 


e CCC version (cisco-hdlc-ccc)—The logical interface does not require an encapsulation statement. When 
you use this encapsulation type, you can configure the ccc family only. 


e TCC version (cisco-hdlc-tcc)—Similar to CCC and has the same configuration restrictions, but used for 
circuits with different media on either side of the connection. 


cisco-hdlc-ccc—Use Cisco-compatible HDLC framing on CCC circuits. 


cisco-hdlc-tcc—Use Cisco-compatible HDLC framing on TCC circuits for connecting different media. 


ethernet-bridge—Use Ethernet bridge encapsulation on Ethernet interfaces that have bridging enabled 
and that must accept all packets. 


ethernet-over-atm—For interfaces that carry IPv4 traffic, use Ethernet over ATM encapsulation. When 
you use this encapsulation type, you cannot configure multipoint interfaces. As defined in RFC 2684, 
Multiprotocol Encapsulation over ATM Adaptation Layer 5, this encapsulation type allows ATM interfaces 
to connect to devices that support only bridge protocol data units (BPDUs). Junos OS does not completely 
support bridging, but accepts BPDU packets as a default gateway. If you use the router as an edge device, 
then the router acts as a default gateway. It accepts Ethernet LLC/SNAP frames with IP or ARP in the 
payload, and drops the rest. For packets destined to the Ethernet LAN, a route lookup is done using the 
destination IP address. If the route lookup yields a full address match, the packet is encapsulated with 
an LLC/SNAP and MAC header, and the packet is forwarded to the ATM interface. 


ethernet-tcc—For interfaces that carry IPv4 traffic, use Ethernet TCC encapsulation on interfaces that 


must accept packets carrying standard TPID values. For 8-port, 12-port, and 48-port Fast Ethernet PICs, 
TCC is not supported. 


ethernet-vpls—Use Ethernet VPLS encapsulation on Ethernet interfaces that have VPLS enabled and 
that must accept packets carrying standard TPID values. On M Series routers, except the M320 router, 
the 4-port Fast Ethernet TX PIC and the 1-port, 2-port, and 4-port, 4-slot Gigabit Ethernet PICs can use 
the Ethernet VPLS encapsulation type. 


ethernet-vpls-fr—Use in a VPLS setup when a CE device is connected to a PE device over a time division 
multiplexing (TDM) link. This encapsulation type enables the PE device to terminate the outer Layer 2 
Frame Relay connection, use the 802.1p bits inside the inner Ethernet header to classify the packets, 
look at the MAC address from the Ethernet header, and use the MAC address to forward the packet 
into a given VPLS instance. 


ethernet-vpls-ppp—Use in a VPLS setup when a CE device is connected to a PE device over a time 
division multiplexing (TDM) link. This encapsulation type enables the PE device to terminate the outer 
Layer 2 PPP connection, use the 802.1p bits inside the inner Ethernet header to classify the packets, 
look at the MAC address from the Ethernet header, and use it to forward the packet into a given VPLS 
instance. 


ether-vpls-over-atm-llc—For ATM intelligent queuing (IQ) interfaces only, use the Ethernet virtual private 
LAN service (VPLS) over ATM LLC encapsulation to bridge Ethernet interfaces and ATM interfaces over 
a VPLS routing instance (as described in RFC 2684, Multiprotocol Encapsulation over ATM Adaptation 
Layer 5). Packets from the ATM interfaces are converted to standard ENET2/802.3 encapsulated Ethernet 
frames with the frame check sequence (FCS) field removed. 


extended-frame-relay-ccc—Use Frame Relay encapsulation on CCC circuits. This encapsulation type 
allows you to dedicate DLCls 1 through 1022 to CCC. When you use this encapsulation type, you can 
configure the ccc family only. 


extended-frame-relay-ether-type-tcc—Use extended Frame Relay ether type TCC for Cisco-compatible 
Frame Relay for DLCls 1 through 1022. This encapsulation type is used for circuits with different media 
on either side of the connection. 


extended-frame-relay-tcc—Use Frame Relay encapsulation on TCC circuits to connect different media. 
This encapsulation type allows you to dedicate DLCls 1 through 1022 to TCC. 


extended-vlan-bridge—Use extended VLAN bridge encapsulation on Ethernet interfaces that have IEEE 
802.1Q VLAN tagging and bridging enabled and that must accept packets carrying TPID Ox8100 or a 
user-defined TPID. 


extended-vlan-ccc—Use extended VLAN encapsulation on CCC circuits with Gigabit Ethernet and 4-port 
Fast Ethernet interfaces that must accept packets carrying 802.1Q values. Extended VLAN CCC 
encapsulation supports TPIDs 0x8100, 0x9100, and 0x9901. When you use this encapsulation type, 
you can configure the ccc family only. For 8-port, 12-port, and 48-port Fast Ethernet PICs, extended 
VLAN CCC is not supported. For 4-port Gigabit Ethernet PICs, extended VLAN CCC is not supported. 


extended-vlan-tcc—For interfaces that carry IPv4 traffic, use extended VLAN encapsulation on TCC 
circuits with Gigabit Ethernet interfaces on which you want to use 802.1Q tagging. For 4-port Gigabit 
Ethernet PICs, extended VLAN TCC is not supported. 
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e extended-vlan-vpls—Use extended VLAN VPLS encapsulation on Ethernet interfaces that have VLAN 
802.1Q tagging and VPLS enabled and that must accept packets carrying TPIDs 0x8100, 0x9100, and 
0x9901. On M Series routers, except the M320 router, the 4-port Fast Ethernet TX PIC and the 1-port, 
2-port, and 4-port, 4-slot Gigabit Ethernet PICs can use the Ethernet VPLS encapsulation type. 


NOTE: The built-in Gigabit Ethernet PIC on an M7i router does not support extended VLAN 
VPLS encapsulation. 


flexible-ethernet-services—For Gigabit Ethernet IQ interfaces and Gigabit Ethernet PICs with small 
form-factor pluggable transceivers (SFPs) (except the 10-port Gigabit Ethernet PIC and the built-in 
Gigabit Ethernet port on the M7i router), and for Gigabit Ethernet interfaces, use flexible Ethernet 


services encapsulation when you want to configure multiple per-unit Ethernet encapsulations. Aggregated 
Ethernet bundles can use this encapsulation type. This encapsulation type allows you to configure any 
combination of route, TCC, CCC, Layer 2 virtual private networks (VPNs), and VPLS encapsulations on 
a single physical port. If you configure flexible Ethernet services encapsulation on the physical interface, 
VLAN IDs from 1 through 511 are no longer reserved for normal VLANs. 


flexible-frame-relay—For IQ interfaces only, use flexible Frame Relay encapsulation when you want to 


configure multiple per-unit Frame Relay encapsulations. This encapsulation type allows you to configure 
any combination of TCC, CCC, and standard Frame Relay encapsulations on a single physical port. Also, 
each logical interface can have any DLCI value from 1 through 1022. 


frame-relay—Use Frame Relay encapsulation is defined in RFC 1490, Multiprotocol Interconnect over 
Frame Relay. E1, E3, link services, SONET/SDH, T1, T3, and voice services interfaces can use Frame 
Relay encapsulation. 


frame-relay-ccc—Use Frame Relay encapsulation on CCC circuits. This encapsulation is same as standard 
Frame Relay for DLCls O through 511. DLCls 512 through 1022 are dedicated to CCC. The logical 
interface must also have frame-relay-ccc encapsulation. When you use this encapsulation type, you can 


configure the ccc family only. 


frame-relay-ether-type—Use Frame Relay ether type encapsulation for compatibility with the Cisco 
Frame Relay. IETF frame relay encapsulation identifies the payload format using NLPID and SNAP 
formats. Cisco-compatible Frame Relay encapsulation uses the Ethernet type to identify the type of 
payload. 


NOTE: When the encapsulation type is set to Cisco-compatible Frame Relay encapsulation, 
ensure that the LMI type is set to ANSI or Q933-A. 


e frame-relay-ether-type-tcc—Use Frame Relay ether type TCC for Cisco-compatible Frame Relay on 
TCC circuits to connect different media. This encapsulation is Cisco-compatible Frame Relay for DLCls 
O through 511. DLCls 512 through 1022 are dedicated to TCC. 
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frame-relay-port-ccc—Use Frame Relay port CCC encapsulation to transparently carry all the DLCls 
between two customer edge (CE) routers without explicitly configuring each DLCI on the two provider 
edge (PE) routers with Frame Relay transport. The connection between the two CE routers can be either 
user-to-network interface (UNI) or network-to-network interface (NNI); this is completely transparent 
to the PE routers. When you use this encapsulation type, you can configure the ccc family only. 


frame-relay-tcc—This encapsulation is similar to Frame Relay CCC and has the same configuration 
restrictions, but used for circuits with different media on either side of the connection. 


generic-services—Use generic services encapsulation for services with a hierarchical scheduler. 


multilink-frame-relay-uni-nni—Use MLFR UNI NNI encapsulation. This encapsulation is used on link 
services, voice services interfaces functioning as FRF.16 bundles, and their constituent T1 or E1 interfaces, 
and is supported on LSQ and redundant LSQ interfaces. 


ppp—Use serial PPP encapsulation. This encapsulation is defined in RFC 1661, The Point-to-Point Protocol 
(PPP) for the Transmission of Multiprotocol Datagrams over Point-to-Point Links. PPP is the default 
encapsulation type for physical interfaces. E1, E3, SONET/SDH, T1, and T3 interfaces can use PPP 
encapsulation. 


ppp-ccc—Use serial PPP encapsulation on CCC circuits. When you use this encapsulation type, you can 
configure the ccc family only. 


ppp-tcc—Use serial PPP encapsulation on TCC circuits for connecting different media. When you use 
this encapsulation type, you can configure the tcc family only. 


vlan-ccc—Use Ethernet VLAN encapsulation on CCC circuits. VLAN CCC encapsulation supports TPID 
0x8100 only. When you use this encapsulation type, you can configure the ccc family only. 


vlan-vci-ccc—Use ATM-to-Ethernet interworking encapsulation on CCC circuits. When you use this 
encapsulation type, you can configure the ccc family only. All logical interfaces configured on the Ethernet 
interface must also have the encapsulation type set to vian-vci-ccc. 


vlan-vpls—Use VLAN VPLS encapsulation on Ethernet interfaces with VLAN tagging and VPLS enabled. 
Interfaces with VLAN VPLS encapsulation accept packets carrying standard TPID values only. On M 
Series routers, except the M320 router, the 4-port Fast Ethernet TX PIC and the 1-port, 2-port, and 
4-port, 4-slot Gigabit Ethernet PICs can use the Ethernet VPLS encapsulation type. 


NOTE: 

e Label-switched interfaces (LSIs) do not support VLAN VPLS encapsulation. Therefore, you 
can only use VLAN VPLS encapsulation on a PE-router-to-CE-router interface and nota 
core-facing interface. 


e Starting with Junos OS release 13.3, a commit error occurs when you configure vlan-vpls 
encapsulation on a physical interface and configure family inet on one of the logical units. 
Previously, it was possible to commit this invalid configuration. 
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For logical interfaces: 


e frame-relay—Configure a Frame Relay encapsulation when the physical interface has multiple logical 
units, and the units are either point to point or multipoint. 


e multilink-frame-relay-uni-nni—Link services interfaces functioning as FRF.16 bundles can use Multilink 
Frame Relay UNI NNI encapsulation. 


e ppp—For normal mode (when the device is using only one ISDN B-channel per call). Point-to-Point 
Protocol is for communication between two computers using a serial interface. 


e ppp-over-ether—This encapsulation is used for underlying interfaces of ppO interfaces. 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding Physical Encapsulation on an Interface 

Configuring Interface Encapsulation on Physical Interfaces 
Configuring CCC Encapsulation for Layer 2 VPNs 

Configuring Layer 2 Switching Cross-Connects Using CCC | 1321 
Configuring TCC Encapsulation for Layer 2 VPNs and Layer 2 Circuits 
Configuring ATM Interface Encapsulation 

Configuring ATM-to-Ethernet Interworking 

Configuring VLAN and Extended VLAN Encapsulation 

Configuring VLAN and Extended VLAN Encapsulation 

Configuring Encapsulation for Layer 2 Wholesale VLAN Interfaces 
Configuring Interfaces for Layer 2 Circuits 

Configuring Interface Encapsulation on PTX Series Packet Transport Routers 
Configuring MPLS LSP Tunnel Cross-Connects Using CCC | 1331 
Configuring TCC | 1336 

Configuring VPLS Interface Encapsulation 

Configuring Interfaces for VPLS Routing 

Defining the Encapsulation for Switching Cross-Connects 


Configuring an MPLS-Based Layer 2 VPN (CLI Procedure) 
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| interface-switch 


Syntax 


interface-switch connection-name { 
interface interface-name.unit-number,; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols connections], 
[edit protocols connections] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 

Configure Layer 2 switching cross-connects. The cross-connect is bidirectional, so packets received on 
the first interface are transmitted out the second interface, and those received on the second interface 
are transmitted out the first. 


For Layer 2 switching cross-connects to work, you must also configure MPLS. 


Options 
connection-name—Connection name (up to 128 characters in Junos 12.3 and later). 


interface interface-name.unit-number—Interface name. Include the logical portion of the name, which 
corresponds to the logical unit number. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration 


RELATED DOCUMENTATION 


Configuring the CCC Connection for Layer 2 Switching Cross-Connects | 1327 
Defining the Connection for Switching Cross-Connects 


MPLS Applications User Guide 
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| I2circuit-control-passthrough 


Syntax 


|2circuit-control-passthrough; 


Hierarchy Level 


[edit forwarding-options] 


Release Information 
Statement introduced in Junos OS Release 19.3R1 for PTX Series routers. 


Description 

Configure the device to allow LACP, LLDP, OAM LFM, and OAM CFM packets to cross the Layer 2 circuit. 
If the I2circuit-control-passthrough statement is not configured, LACP, LLDP, OAM LFM, and OAM CFM 
packets are classified as control packets and are not transmitted across the Layer 2 circuit. 


NOTE: For MX Series routers, the functionality that the I2circuit-control-passthrough command 
provides is performed automatically. 


Default 


By default, this statement is not configured. 


Required Privilege Level 
interface—To view this statement in the configuration. 
interface-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


forwarding-options 
Configuring Layer 2 Switching Cross-Connects Using CCC | 1321 
Configuring an MPLS-Based VLAN CCC with Pop, Push, and Swap and Control Passthrough 
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| Isp-switch 
Syntax 


Isp-switch connection-name { 
transmit-lsp label-switched-path; 
receive-lsp label-switched-path; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols connections], 
[edit protocols connections] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Configure Layer 2 switching cross-connects. 


Options 


connection-name—Connection name. 
receive-Isp label-switched-path—Name of the LSP from the connection’s source. 


transmit-Isp label-switched-path—Name of the LSP to the connection’s destination. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Connection for Layer 2 Switching TCCs | 1340 
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| output-interface (CCC) 


Syntax 


output-interface [interface-name 1 interface-name n); 


Hierarchy Level 


[edit protocols connections p2mp-transmit-switch p2mp-transmit-switch-name] 


Release Information 
Statement introduced in Junos OS Release 12.3. 


Description 
Specify one or more output interfaces to switch traffic on an incoming CCC interface to one or more 
outgoing CCC interfaces. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring CCC Switching for Point-to-Multipoint LSPs | 1345 
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| p2mp-receive-switch 
Syntax 


p2mp-receive-switch point-to-multipoint-switch-name { 
output-interface [ interface-name.unit-number ]; 
receive-p2mp-lsp receiving-point-to-multipoint-Isp; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols connections], 
[edit protocols connections] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Configure the CCC switch for a point-to-multipoint LSP on the egress PE router. 


Options 


point-to-multipoint-switch-name—Point-to-multipoint CCC receive switch name. 


output-interface interface-name.unit-number—Name of the egress interfaces for the point-to-multipoint 
LSP traffic. You can configure multiple output interfaces. 


receive-p2mp-Isp receiving-point-to-multipoint-Isp—Name of the point-to-multipoint LSP that is switched 
to the output interface. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Point-to-Multipoint LSP Switch on Egress PE Routers | 1346 
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| p2mp-transmit-switch 
Syntax 


p2mp-transmit-switch point-to-multipoint-transmit-switch-name { 
input-interface interface-name.unit-number; 
transmit-p2mp-lsp transmitting-point-to-multipoint-Isp; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols connections], 
[edit protocols connections] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Configure the CCC switch for the point-to-multipoint LSP on the ingress PE router. 


Options 


point-to-multipoint-transmit-switch-name—Point-to-multipoint CCC transmit switch name. 


input-interface input-interface-name.unit-number—Specify the name of the interface carrying incoming 
traffic to be switched to the point-to-multipoint LSP. 


transmit-p2mp-lsp transmitting-point-to-multipoint-Isp—Specify the name of the point-to-multipoint LSP 
carrying traffic to the CCC switch on the egress PE router. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Point-to-Multipoint LSP Switch on Ingress PE Routers | 1346 
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| remote-interface-switch 


Syntax 


remote-interface-switch connection-name { 
interface interface-name.unit-number,; 
transmit-lsp label-switched-path; 
receive-Isp label-switched-path; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols connections], 
[edit protocols connections] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Configure MPLS LSP tunnel cross-connects. 


Options 


connection-name—Connection name. 


interface interface-name.unit-number—Interface name. Include the logical portion of the name, which 
corresponds to the logical unit number. 


receive-Isp label-switched-path—Name of the LSP from the connection’s source. 


transmit-Isp label-switched-path—Name of the LSP to the connection’s destination. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring MPLS LSP Tunnel Cross-Connects Using CCC | 1331 


CHAPTER 24 


GMPLS Configuration Statements 


IN THIS CHAPTER 
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te-link | 2224 

traceoptions (Protocols Link Management) | 2226 
transit-delay (OSPF) | 2228 

upstream-label | 2230 


vrf-target | 2231 


| address (Peer) 


Syntax 


address ip-address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management peer peer-name], 
[edit protocols link-management peer peer-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Specify the ID of the peer. 


Default 


The loopback address is advertised. 


Options 
ip-address—|P address of the peer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the ID for LMP Peers 
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| control-channel (Protocols Link Management Peer) 


Syntax 


control-channel control-channel-interface; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management peer peer-name], 
[edit protocols link-management peer peer-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Specify the control channel interface for the peer. 


Options 


control-channel-interface—Name of the control channel interface. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LMP Peers 
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| dead-interval 


Syntax 


dead-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-namel], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-namel], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
virtual-link], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols ospf area area-id peer-interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id virtual-link], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 


area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 
Specify how long OSPF waits before declaring that a neighboring routing device is unavailable. This is an 
interval during which the routing device receives no hello packets from the neighbor. 


Options 
seconds—Interval to wait. 
Range: 1 through 65,535 seconds 


Default: Four times the hello interval—40 seconds (broadcast and point-to-point networks); 120 seconds 
(nonbroadcast multiple access (NBMA) networks) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPF Timers 
Configuring RSVP and OSPF for LMP Peer Interfaces 
hello-interval | 2194 


disable (GMPLS) 


Syntax 


disable; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management te-link te-link-name], 
[edit protocols link-management te-link te-link-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Disable a traffic engineering link. 


Default 


The configured object is enabled (operational) unless explicitly disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Disabling the Traffic Engineering Link for LMP Peers 


2188 


2189 


| disable (OSPF) 


Syntax 


disable; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-namel], 

[edit logical-systems logical-system-name protocols ospf area area-id peer-interfaceinterface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) virtual-link], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) virtual-link], 

[edit logical-systems logical-system-name routing-instances routing-instances protocols ospf3 realm (ipv4-unicast | 
ipv4-multicast | ipv6-multicast)], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols (ospf | ospf3)], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) virtual-link], 

[edit protocols ospf area area-id peer-interface interface-name], 

[edit protocols ospf area area-id virtual-link neighbor-id router-id transit-area area-id], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3)], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) virtual-link], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 


area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 
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Description 
Disable OSPF, an OSPF interface, or an OSPF virtual link. 


By default, control packets sent to the remote end of a virtual link must be forwarded using the default 
topology. In addition, the transit area path consists only of links that are in the default topology. You can 
disable a virtual link for a configured topology, but not for a default topology. Include the disable statement 
at the [edit protocols ospf area area-id virtual-link neighbor-id router-id transit-area area-id topology 
name] hierarchy level. 


NOTE: If you disable the virtual link by including the disable statement at the [edit protocols 
ospf area area-id virtual-link neighbor-id router-id transit-area area-id] hierarchy level, you disable 
the virtual link for all topologies, including the default topology. You cannot disable the virtual 
link only in the default topology. 


Default 


The configured object is enabled (operational) unless explicitly disabled. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Understanding OSPF Configurations 
Configuring RSVP and OSPF for LMP Peer Interfaces 


| export (Protocols BGP) 


Syntax 


export [ policy-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols bgp], 

[edit logical-systems logical-system-name protocols bgp group group-name], 

[edit logical-systems logical-system-name protocols bgp group group-name neighbor address], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name 
neighbor address], 

[edit protocols bgp], 

[edit protocols bgp group group-name], 

[edit protocols bgp group group-name neighbor address], 

[edit routing-instances routing-instance-name protocols bgp], 

[edit routing-instances routing-instance-name protocols bgp group group-name], 

[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Apply one or more policies to routes being exported from the routing table into BGP. 


If you specify more than one policy, they are evaluated in the order specified, from left to right, and the 
first matching filter is applied to the route. If no routes match the filters, the routing table exports into 
BGP only the routes that it learned from BGP. If an action specified in one of the policies manipulates a 
route characteristic, the policy framework software carries the new route characteristic forward during 
the evaluation of the remaining policies. For example, if the action specified in the first policy of a chain 
sets a route’s metric to 500, this route matches the criterion of metric 500 defined in the next policy. 


Options 


policy-names—Name of one or more policies. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Configuring Routing Policies to Control BGP Route Advertisements 
Routing Policies, Firewall Filters, and Traffic Policers User Guide 


import | 2196 


| hello-dead-interval 


Syntax 


hello-dead-interval milliseconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management peer peer-name Imp-protocoll], 
[edit protocols link-management peer peer-name |Imp-protocol] 


Release Information 
Statement introduced in Junos OS Release 8.0. 


Description 

Specify how long the Link Management Protocol (LMP) waits before declaring the control channel to be 
dead. This is an interval during which the router receives no LMP hello packets from the neighbor ona 
control that is active or up. 


Options 
milliseconds—Interval to wait before declaring the control channel to be dead. 
Range: 500 through 300,000 


Default: 500 milliseconds (three times the hello interval) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Hello Message Intervals for LMP Control Channels 
hello-interval (LMP) | 2193 
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| hello-interval (LMP) 


Syntax 


hello-interval milliseconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management peer peer-name Imp-protocoll], 
[edit protocols link-management peer peer-name Imp-protocol] 


Release Information 
Statement introduced in Junos OS Release 8.1. 


Description 


Specify how often the router sends Link Management Protocol (LMP) hello packets. 


Options 

milliseconds—Length of time between hello packets. 
Range: 150 through 300,000 
Default: 150 milliseconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Hello Message Intervals for LMP Control Channels 
hello-dead-interval | 2192 
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| hello-interval (Protocols OSPF) 


Syntax 


hello-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-namel], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-namel], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
virtual-link], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols ospf area area-id peer-interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id virtual-link], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-namel], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 


area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 
Specify how often the routing device sends hello packets out the interface. The hello interval must be the 
same for all routing devices on a shared logical IP network. 


Options 
seconds—Time between hello packets, in seconds. 
Range: 1 through 255 seconds 


Default: 10 seconds (broadcast and point-to-point networks); 30 seconds (nonbroadcast multiple access 
[NBMA] networks) 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPF Timers 
Configuring RSVP and OSPF for LMP Peer Interfaces 
dead-interval | 2187 
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| import 
Syntax 


import [ policy-names ]; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols bgp], 

[edit logical-systems logical-system-name protocols bgp group group-name], 

[edit logical-systems logical-system-name protocols bgp group group-name neighbor address], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols bgp group group-name 
neighbor address], 

[edit protocols bgp], 

[edit protocols bgp group group-name], 

[edit protocols bgp group group-name neighbor address], 

[edit routing-instances routing-instance-name protocols bgp], 

[edit routing-instances routing-instance-name protocols bgp group group-name], 

[edit routing-instances routing-instance-name protocols bgp group group-name neighbor address] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 
Statement introduced in Junos OS Release 11.3 for the QFX Series. 
Statement introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 


Apply one or more routing policies to routes being imported into the Junos OS routing table from BGP. 


If you specify more than one policy, they are evaluated in the order specified, from left to right, and the 
first matching filter is applied to the route. If no match is found, BGP places into the routing table only 
those routes that were learned from BGP routing devices. The policy framework software evaluates the 
routing policies in a chain sequentially. If an action specified in one of the policies manipulates a route 
characteristic, the policy framework software carries the new route characteristic forward during the 
evaluation of the remaining policies. For example, if the action specified in the first policy of a chain sets 
a route’s metric to 500, this route matches the criterion of metric 500 defined in the next policy. 


It is also important to understand that in Junos OS, although an import policy (inbound route filter) might 
reject a route, not use it for traffic forwarding, and not include it in an advertisement to other peers, the 
router retains these routes as hidden routes. These hidden routes are not available for policy or routing 
purposes. However, they do occupy memory space on the router. A service provider filtering routes to 
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control the amount of information being kept in memory and processed by a router might want the router 
to entirely drop the routes being rejected by the import policy. 


Hidden routes can be viewed by using the show route receive-protocol bgp neighbor-address hidden 
command. The hidden routes can then be retained or dropped from the routing table by configuring the 
keep all | none statement at the [edit protocols bgp] or [edit protocols bgp group group-name] hierarchy 
level. 


The rules of BGP route retention are as follows: 
e By default, all routes learned from BGP are retained, except those where the AS path is looped. (The AS 
path includes the local AS.) 


e By configuring the keep all statement, all routes learned from BGP are retained, even those with the 
local AS in the AS path. 


e By configuring the keep none statement, all routes received are discarded. When this statement is 
configured and the inbound policy changes, Junos OS re-advertises all the routes advertised by the peer. 


Options 


policy-names—Name of one or more policies. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring BGP Interactions with IGPs 
Configuring Routing Policies to Control BGP Route Advertisements 


Understanding Routing Policies 


export | 2191 
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| instance-type 


Syntax 


instance-type type; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name], 
[edit routing-instances routing-instance-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

virtual-switch and layer2-control options introduced in Junos OS Release 8.4. 
Statement introduced in Junos OS Release 9.2 for EX Series switches. 

Statement introduced in Junos OS Release 11.3 for the QFX Series. 

Statement introduced in Junos OS Release 12.3 for ACX Series routers. 
mpls-internet-multicast option introduced in Junos OS Release 11.1 for the EX Series, M Series, MX Series, 
and T Series. 

evpn option introduced in Junos OS Release 13.2 for MX 3D Series routers. 

evpn option introduced in Junos OS Release 17.3 for the QFX Series. 

forwarding option introduced in Junos OS Release 14.2 for the PTX Series. 
mpls-forwarding option introduced in Junos OS Release 16.1 for the MX Series. 
evpn-vpws option introduced in Junos OS Release 17.1 for MX Series routers. 
Support for logical systems on MX Series routers added in Junos OS Release 17.4R1. 


Description 


Define the type of routing instance. 


Options 


NOTE: On ACX Series routers, you can configure only the forwarding, virtual router, and VRF 
routing instances. 


type—Can be one of the following: 


e evpn—(MX 3D Series routers, QFX switches and EX9200 switches)—Enable an Ethernet VPN (EVPN) 
on the routing instance. 
hierarchy level. 


e evpn-vpws—Enable an Ethernet VPN (EVPN) Virtual Private Wire Service (VPWS) on the routing instance. 


forwarding—Provide support for filter-based forwarding, where interfaces are not associated with 
instances. All interfaces belong to the default instance. Other instances are used for populating RPD 
learned routes. For this instance type, there is no one-to-one mapping between an interface and a routing 
instance. All interfaces belong to the default instance inet.0. 


I2backhaul-vpn—Provide support for Layer 2 wholesale VLAN packets with no existing corresponding 
logical interface. When using this instance, the router learns both the outer tag and inner tag of the 
incoming packets, when the instance-role statement is defined as access, or the outer VLAN tag only, 
when the instance-role statement is defined as nni. 


I2vpn—Enable a Layer 2 VPN on the routing instance. You must configure the interface, 
route-distinguisher, vrf-import, and vrf-export statements for this type of routing instance. 


layer2-control—(MX Series routers only) Provide support for RSTP or MSTP in customer edge interfaces 
of a VPLS routing instance. This instance type cannot be used if the customer edge interface is multihomed 
to two provider edge interfaces. If the customer edge interface is multihomed to two provider edge 
interfaces, use the default BPDU tunneling. 


mpls-forwarding—(MX Series routers only) Allow filtering and translation of route distinguisher (RD) 
values in IPv4 and IPv6 VPN address families on both routes received and routes sent for selected BGP 
sessions. In particular, for Inter-AS VPN Option-B networks, this option can prevent the malicious 
injection of VPN labels from one peer AS boundary router to another. 


mpls-internet-multicast—(EX Series, M Series, MX Series, and T Series routers only) Provide support for 
ingress replication provider tunnels to carry IP multicast data between routers through an MPLS cloud, 
using MBGP or next-generation MVPN. 


no-forwarding—This is the default routing instance. Do not create a corresponding forwarding instance. 
Use this routing instance type when a separation of routing table information is required. There is no 
corresponding forwarding table. All routes are installed into the default forwarding table. IS-IS instances 
are strictly nonforwarding instance types. 


virtual-router—Enable a virtual router routing instance. This instance type is similar to a VPN routing 
and forwarding instance type, but used for non-VPN-related applications. You must configure the 
interface statement for this type of routing instance. You do not need to configure the route-distinguisher, 
vrf-import, and vrf-export statements. 


virtual-switch—(MX Series routers, EX9200 switches, and QFX switches only) Provide support for Layer 2 
bridging. Use this routing instance type to isolate a LAN segment with its Spanning Tree Protocol (STP) 
instance and to separate its VLAN identifier space. 
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e vpls—Enable VPLS on the routing instance. Use this routing instance type for point-to-multipoint LAN 
implementations between a set of sites ina VPN. You must configure the interface, route-distinguisher, 
vrf-import, and vrf-export statements for this type of routing instance. 


vrf—VPN routing and forwarding (VRF) instance. Provides support for Layer 3 VPNs, where interface 
routes for each instance go into the corresponding forwarding table only. Required to create a Layer 3 
VPN. Create a VRF table (instance-name.inet.0) that contains the routes originating from and destined 
for a particular Layer 3 VPN. For this instance type, there is a one-to-one mapping between an interface 
and a routing instance. Each VRF instance corresponds with a forwarding table. Routes on an interface 
go into the corresponding forwarding table. You must configure the interface, route-distinguisher, 
vrf-import, and vrf-export statements for this type of routing instance. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Instance Type 

Configuring EVPN Routing Instances 

Configuring EVPN Routing Instances on EX9200 Switches 
Configuring Virtual Router Routing Instances 


Example: Configuring Filter-Based Forwarding on the Source Address 





Example: Configuring Filter-Based Forwarding on Logical Systems 
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| interface (Protocols Link Management) 


Syntax 


interface interface-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management te-link te-link-name], 
[edit protocols link-management te-link te-link-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Specify the egress router interface. 


Options 


interface-name—Name of the interface to the egress router. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


LMP Configuration Overview 
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| label-switched-path (Protocols Link Management) 


Syntax 


label-switched-path Isp-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management te-link te-link-name], 
[edit protocols link-management te-link te-link-name] 


Release Information 
Statement introduced in Junos OS Release 7.4. 


Description 


Specify the label-switched path (LSP) to be used by the forwarding adjacency. 


Options 
Isp-name—Name of the LSP. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Forwarding Adjacencies 
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| link-management 


Syntax 


link-management { 
peer peer-name { 
address ip-address; 
control-channel control-channel-interface; 
lmp-control-channel control-channel-interface { 
remote-address ip-address; 
} 
Imp-protocol { 
hello-dead-interval milliseconds; 
hello-interval milliseconds; 
passive; 
retransmission-interval milliseconds; 
retry-limit number; 
} 
te-link te-link-name; 
} 
te-link te-link-name { 
disable; 
interface interface-name { 
disable; 
local-address ip-address; 
remote-address ip-address; 
remote-id id-number; 
} 
local-address ip-address; 
remote-address ip-address; 
remote-id id-number; 
} 
traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag <flag-modifier> <disable>; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols], 
[edit protocols] 


Release Information 


Statement introduced before Junos OS Release 7.4. 


Description 


Enable Link Management Protocol (LMP) on the router. 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


LMP Configuration Overview 
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| Imp-control-channel 


Syntax 


Imp-control-channel control-channel-interface { 
remote-address ip-address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management peer peer-name], 
[edit protocols link-management peer peer-name] 


Release Information 
Statement introduced in Junos OS Release 8.1. 


Description 


Specify the Link Management Protocol (LMP) control channel interface for the peer. 


Options 


control-channel-interface—Name of the control channel interface. 


The remaining statement is described separately in this chapter. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the LMP Control Channel Interface for the Peer 
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| Imp-protocol 


Syntax 


Imp-protocol { 
hello-dead-interval milliseconds; 
hello-interval milliseconds; 
passive; 
retransmission-interval milliseconds; 
retry-limit number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management peer peer-name], 
[edit protocols link-management peer peer-name] 


Release Information 
Statement introduced in Junos OS Release 8.1. 


Description 
Configure attributes of Link Management Protocol (LMP) to establish and maintain the LMP control channel 
for the peer. 


Options 


The statements are described separately in this chapter. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LMP Peers 
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| local-address (Protocols Link Management) 


Syntax 


local-address ip-address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management te-link te-link-name], 

[edit logical-systems logical-system-name protocols link-management te-link te-link-name interface interface-name], 
[edit protocols link-management te-link te-link-name], 

[edit protocols link-management te-link te-link-name interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 
Specify the local IP address associated with the traffic engineering link. If you configure the local IP address, 
you must also configure the remote-address statement. 


Options 


local-address—Local IP address of the traffic engineering link. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Local IP Address for Traffic Engineering Links 
Configuring the Local IP Address for Forwarding Adjacencies 
remote-address (for LMP Traffic Engineering) | 2214 
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| I2circuit 


Syntax 


|2circuit { 
auto-sensingf{ 
password password; 
} 
local-switching { 
interface interface-name { 
description text; 
end-interface { 
interface interface-name; 
protect-interface interface-name; 
} 
ignore-mtu-mismatch; 
protect-interface interface-name; 


} 
neighbor address { 
interface interface-name { 

backup-neighbor address; 
bandwidth (bandwidth | ctnumber bandwidth), 
community community-name; 
connection-protection; 
(control-word | no-control-word); 
description text; 
egress-protection; 
encapsulation-type type; 
ignore-encapsulation-mismatch; 
ignore-mtu-mismatch; 
mtu mtu-number; 
protect-interface interface-name; 
pseudowire-status-tlv hot-standby-vc-on; 
psn-tunnel-endpoint address; 
virtual-circuit-id identifier; 


} 

resolution { 
preserve-nexthop-heirarchy; 

} 

traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag <flag-modifier> <disable>; 
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Hierarchy Level 


[edit logical-systems logical-system-name protocols], 
[edit protocols] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 11.1 for EX Series switches. 

Statement introduced in Junos OS Release 14.1X53-D10 for the QFX Series and for EX4600 switches. 


Description 


Enables a Layer 2 circuit. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring ATM Trunking on Layer 2 Circuits 

Configuring Bandwidth Allocation and Call Admission Control in Layer 2 Circuits 
Configuring Interfaces for Layer 2 Circuits 

Configuring LDP for Layer 2 Circuits 

Configuring Policies for Layer 2 Circuits 

Configuring Static Layer 2 Circuits 


Tracing Layer 2 Circuit Operations 
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| passive (Protocols Link Management) 


Syntax 


passive; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management peer peer-name Imp-protocoll], 
[edit protocols link-management peer peer-name |Imp-protocol] 


Release Information 
Statement introduced in Junos OS Release 8.1. 


Description 
Specify that the router not configure the Link Management Protocol (LMP) control channels but wait for 
the remote peer to configure the LMP control channels. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Preventing the Local Peer from Initiating LMP Negotiation 
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| peer (Protocols LMP) 


Syntax 


peer peer-name { 
address ip-address; 
control-channel control-channel-interface; 
Imp-control-channel control-channel-interface; 
Imp-protocol { 
hello-dead-interval milliseconds; 
hello-interval milliseconds; 
passive; 
retransmission-interval milliseconds; 
retry-limit number; 


} 


te-link te-link-name; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management], 
[edit protocols link-management] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Imp-protocol statement and substatements added in Junos OS Release 8.1. 


Description 


Configure a network peer. 


Options 


peer-name—Name of the network peer. 


The remaining statements are described separately in this chapter. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring LMP Peers 
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| peer-interface (Protocols OSPF) 


Syntax 


peer-interface interface-name { 
disable; 
dead-interval seconds; 
hello-interval seconds; 
retransmit-interval seconds; 
transit-delay seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id], 
[edit protocols ospf area area-id] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Configure a peer interface. 


Options 


interface-name—Name of the peer interface. To configure all interfaces, you can specify all. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPFv2 Peer interfaces 
Configuring RSVP and OSPF for LMP Peer Interfaces 
Configuring a Hierarchy of RSVP LSPs to Tunnel Multiple RSVP LSPs Over a Single RSVP LSP 
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| remote-address (for LMP Control Channel) 


Syntax 


remote-address ip-address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management peer peer-name Imp-control-channel 
control-channel-interface], 
[edit protocols link-management peer peer-name Imp-control-channel control-channel-interface] 


Release Information 
Statement introduced in Junos OS Release 8.1. 


Description 


Specify the remote IP address for the Link Management Protocol (LMP) control channel interface. 


Options 


ip-address—Remote IP address mapped to the LMP control channel interface. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Remote IP Address for LMP Control Channels 
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| remote-address (for LMP Traffic Engineering) 


Syntax 


remote-address ip-address; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management te-link te-link-name], 

[edit logical-systems logical-system-name protocols link-management te-link te-link-name interface interface-name], 
[edit protocols link-management te-link te-link-name], 

[edit protocols link-management te-link te-link-name interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 
Specify the remote IP address for the traffic engineering link. If you configure the remote IP address, you 
must also configure the local-address statement. 


Options 


ip-address—Remote IP address mapped to the traffic engineering link. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Remote IP Address for Traffic Engineering Links 
Configuring the Remote IP Address for Forwarding Adjacencies 


local-address (Protocols Link Management) | 2207 
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remote-id 


Syntax 


remote-id id-number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management te-link te-link-name], 

[edit logical-systems logical-system-name protocols link-management te-link te-link-name interface interface-name], 
[edit protocols link-management te-link te-link-name], 

[edit protocols link-management te-link te-link-name interface interface-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 


Description 


Specify the ID assigned to a traffic engineering link or an interface (resource) on the peer node. 


Options 


id-number—|D number for the remote device. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring the Remote ID for Traffic Engineering Links 
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| retransmission-interval 


Syntax 


retransmission-interval milliseconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management peer peer-name Imp-protocoll], 
[edit protocols link-management peer peer-name |Imp-protocol] 


Release Information 
Statement introduced in Junos OS Release 8.1. 


Description 
Specify how often Link Management Protocol (LMP) sends Config and LinkSummary messages on the 
LMP control channel. 


Options 

milliseconds—Length of time between Config messages. 
Range: 500 through 300,000 
Default: 500 milliseconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


retry-limit (Protocols Link Management) | 2219 
Controlling Message Exchange for LMP Control Channels 
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| retransmit-interval (OSPF) 


Syntax 


retransmit-interval seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-namel], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-namel], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
interface interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3) area area-id 
virtual-link], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols ospf area area-id peer-interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id virtual-link], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id interface interface-namel], 

[edit routing-instances routing-instance-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 


area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 
Specify how long the routing device waits to receive a link-state acknowledgment packet before 
retransmitting link-state advertisements (LSAs) to an interface’s neighbors. 


Options 
seconds—Interval to wait. 
Range: 1 through 65,535 seconds 


Default: 5 seconds 


NOTE: You must configure LSA retransmit intervals to be equal to or greater than 3 seconds to 
avoid triggering a retransmit trap, because Junos OS delays LSA acknowledgments by up to 
2 seconds. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPF Timers 
Configuring RSVP and OSPF for LMP Peer Interfaces 
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| retry-limit (Protocols Link Management) 


Syntax 


retry-limit number; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management peer peer-name Imp-protocoll], 
[edit protocols link-management peer peer-name Imp-protocol] 


Release Information 
Statement introduced in Junos OS Release 8.1. 


Description 

Specify how many times the Link Management Protocol (LMP) sends Config and LinkSummary messages 
on the LMP control channel without receiving an appropriate acknowledgment before it logs a message 
and restarts the LMP control channel configuration process. 


Options 

number—Maximum number of times messages are sent without receiving an acknowledgment. 
Range: 3 through 1000 
Default: 3 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


retransmission-interval | 2216 


Controlling Message Exchange for LMP Control Channels 
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| route-distinguisher 
Syntax 


route-distinguisher (as-number:id | ip-address:id); 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols I2vpn mesh-group 
mesh-group-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls mesh-group 
mesh-group-name], 

[edit routing-instances routing-instance-name], 

[edit routing-instances routing-instance-name protocols |2vpn mesh-group mesh-group-name], 

[edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 11.1 for EX Series switches. 

Support at [edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name] 
hierarchy level introduced in Junos OS Release 11.2. 

Statement introduced in Junos OS Release 12.3 for ACX Series routers. 

Support at [edit routing-instances routing-instance-name protocols I2vpn mesh-group mesh-group-name] 
hierarchy level introduced in Junos OS Release 13.2. 

Statement introduced in Junos OS Release 14.1X53-D30 for QFX Series switches. 

Statement introduced in cRPD Release 19.4R1. 


Description 

Specify an identifier attached to a route, enabling you to distinguish to which VPN or virtual private LAN 
service (VPLS) the route belongs. Each routing instance must have a unique route distinguisher (RD) 
associated with it. The RD is used to place bounds around a VPN so that the same IP address prefixes can 
be used in different VPNs without having them overlap. If the instance type is vrf, the route-distinguisher 
statement is required. 


For Layer 2 VPNs and VPLS, if you configure the I2vpn-use-bgp-rules statement, you must configure a 
unique RD for each PE router participating in the routing instance. 


For other types of VPNs, we recommend that you use a unique RD for each provider edge (PE) router 
participating in specific routing instance. Although you can use the same RD onall PE routers for the same 
VPN routing instance, if you use a unique RD, you can determine the customer edge (CE) router from 
which a route originated within the VPN. 


For Layer 2 VPNs and VPLSs, if you configure mesh groups, the RD in each mesh group must be unique. 


Be 
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CAUTION: We strongly recommend that if you change an RD that has already been 
configured, or change the routing-instance type from virtual-router to vrf, make the 
change during a maintenance window, as follows: 


1. Deactivate the routing instance. 
2. Change the RD. 


3. Activate the routing instance. 


This is not required if you are configuring the RD for the first time. 
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Options 

as-number:number—as-number is an assigned AS number, and number is any 2-byte or 4-byte value. The 
AS number can be from 1 through 4,294,967,295. If the AS number is a 2-byte value, the administrative 
number is a 4-byte value. If the AS number is 4-byte value, the administrative number is a 2-byte value. 
An RD consisting of a 4-byte AS number and a 2-byte administrative number is defined as a type 2 RD in 
RFC 4364 BGP/MPLS IP VPNs. 


NOTE: In Junos OS Release 9.1 and later, the numeric range for AS numbers is extended to 
provide BGP support for 4-byte AS numbers, as defined in RFC 4893, BGP Support for Four-octet 
AS Number Space. All releases of Junos OS support 2-byte AS numbers. To configure an RD that 
includes a 4-byte AS number, append the letter “L” to the end of the AS number. For example, 
an RD with the 4-byte AS number 7,765,000 and an administrative number of 1,000 is represented 
as 77765000L:1000. 


In Junos OS Release 9.2 and later, you can also configure a 4-byte AS number using the AS dot 
notation format of two integer values joined by a period: <16-bit high-order value in 

decimal>.< 16-bit low-order value in decimal>. For example, the 4-byte AS number of 65,546 in 
the plain-number format is represented as 1.10 in AS dot notation format. 


ip-address:id—|P address (ip-address is a 4-byte value) within your assigned prefix range and a 2-byte value 
for the id. The IP address can be any globally unique unicast address. 

Range: O through 4,294,967,295 (a - 1). If the router you are configuring is a BGP peer of a router that does 
not support 4-byte AS numbers, you need to configure a local AS number. For more information, see Using 
4-Byte Autonomous System Numbers in BGP Networks Technology Overview. 


NOTE: For Ethernet VPN (EVPN), an RD that includes zero as the id value is reserved for the 
default EVPN routing instance by default. Because the same RD cannot be assigned for two 
routing instances, using a ip-address:id RD for another routing instance (default-switch), where 
the id value is zero, throws a commit error. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Example: Configuring BGP Route Target Filtering for VPNs 
Example: Configuring FEC 129 BGP Autodiscovery for VPWS 
Configuring EVPN Routing Instances 

Configuring Routing Instances on PE Routers in VPNs 
Configuring an MPLS-Based Layer 2 VPN (CLI Procedure) 
Configuring an MPLS-Based Layer 3 VPN (CLI Procedure) 





path-selection 
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| te-link 
Syntax 


te-link te-link-name { 

disable; 

ethernet-vlan; 

interface interface-name { 
disable; 
local-address ip-address; 
remote-address ip-address; 
remote-id id-number; 


} 

local-address ip-address; 
remote-address ip-address; 
remote-id id-number; 


Hierarchy Level 


[edit protocols link-management], 
[edit protocols link-management peer peer-name] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
ethernet-vlan option introduced in Junos OS Release 14.2. 


Description 
Represent a collection of physical ports or time slots. Assign a traffic engineering link to the specified 
network peer. 


Options 


te-link-name—Name of the collection of physical ports or the name of the time slots. 
disable—Disable the traffic engineering link or an interface to a traffic engineering link. 


The remaining statements are explained separately.. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Configuring LMP Traffic Engineering Links 


2226 


| traceoptions (Protocols Link Management) 


Syntax 


traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag <flag-modifier> <disable>; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols link-management], 
[edit protocols link-management] 


Release Information 
Statement introduced before Junos OS Release 7.4. 
Support for hello-packets, packets, and state flags added in Junos OS Release 8.1. 


Description 


Trace options for the LMP protocol. 


Options 
disable—(Optional) Disable the tracing operation. You can use this option to disable a single operation 
when you have defined a broad group of tracing operations, such as all. 


filename—Name of the file to receive the output of the tracing operation. Enclose the name within quotation 
marks. All files are placed in the directory /var/log. 


files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its 
maximum size, it is renamed trace-file.0, then trace-file.1, and so on, until the maximum number of trace 
files is reached. Then the oldest trace file is overwritten. 


Range: 2 through 1000 
Default: 2 files 


If you specify a maximum number of files, you must also include the size statement to specify the maximum 
file size. 


flag—Tracing operation to perform. To specify more than one tracing operation, include multiple flag 
statements. 


e all—Trace all available operations 
e hello-packets—Trace hello packets on any LMP control channel 


e init—Output from the initialization messages 
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packets—Trace all packets other than hello packets on any LMP control channel 


parse—Operation of the parser 


process—Operation of the general configuration 


route-socket—Operation of route socket events 


routing—Operation of the routing protocols 


server—Server processing operations 
e show—show command servicing operations 


e state—Trace state transitions of the LMP control channels and traffic engineering links 
flag-modifier—(Optional) Modifier for the tracing flag. You can specify one or more of these modifiers: 


e detail—Provide detailed trace information 
e receive—Packets being received 


e send—Packets being transmitted 
no-world-readable—(Optional) Prevent all users from reading the log file. 


size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB), or gigabytes (GB). 
When a trace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file again 
reaches this size, trace-file.0 is renamed trace-file.1 and trace-file is renamed trace-file.0. This renaming 
scheme continues until the maximum number of trace files is reached. Then the oldest trace file is 
overwritten. 


Syntax: xk to specify KB, xm to specify MB, or xg to specify GB 
Range: 10 KB through the maximum file size supported on your system 
Default: 1 MB 


If you specify a maximum file size, you must also include the files statement to specify the maximum 
number of files. 


world-readable—(Optional) Enable log file access for all users. 


Required Privilege Level 
routing and trace—To view this statement in the configuration. 
routing-control and trace-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Tracing LMP Traffic | 1263 


Network Management and Monitoring Guide 
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| transit-delay (OSPF) 


Syntax 


transit-delay seconds; 


Hierarchy Level 


[edit logical-systems logical-system-name protocols ospf area area-id peer-interface interface-name], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id interface interface-namel], 

[edit logical-systems logical-system-name protocols (ospf | ospf3) area area-id virtual-link], 

[edit logical-systems logical-system-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) area 
area-id interface interface-namel], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id interface 
interface-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id 
virtual-link], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast 
| ipv4-multicast | ipv6-multicast) area area-id interface interface-name], 

[edit protocols ospf area area-id peer-interface interface-name], 

[edit protocols (ospf | ospf3) area area-id interface interface-name], 

[edit protocols (ospf | ospf3) area area-id virtual-link], 

[edit protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast)] area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf area area-id interface interface-name], 

[edit routing-instances routing-instance-name protocols ospf area area-id virtual-link], 

[edit routing-instances routing-instance-name protocols ospf3 realm (ipv4-unicast | ipv4-multicast | ipv6-multicast) 


area area-id interface interface-name] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.0 for EX Series switches. 

Support for the realm statement introduced in Junos OS Release 9.2. 

Support for the realm statement introduced in Junos OS Release 9.2 for EX Series switches. 


Description 
Set the estimated time required to transmit a link-state update on the interface. When calculating this 
time, make sure to account for transmission and propagation delays. 


You should never have to modify the transit delay time. 


Options 
seconds—Estimated time, in seconds. 
Range: 1 through 65,535 seconds 
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Default: 1 second 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Example: Configuring OSPF Timers 
Configuring RSVP and OSPF for LMP Peer Interfaces 
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| upstream-label 


Syntax 


upstream-label { 
vlan-id vlan-id; 


Hierarchy Level 


[edit protocols mpls label-switched-path Isp-name |sp-attributes] 


Release Information 
Statement introduced in Junos OS Release 14.2. 


Description 


Specify the upstream label for the bidirectional label-switched path (LSP). 


Options 
vian-id vian-id—VLAN ID to be used for the Generalized MPLS (GMPLS) VLAN LSP at the ingress provider 
edge (PE) to customer edge (CE) link. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring MPLS LSPs for GMPLS | 1264 
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| vrf-target 
Syntax 


vrf-target { 
community; 
auto 
import community-name; 
export community-name; 


Hierarchy Level 


[edit logical-systems logical-system-name routing-instances routing-instance-name], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols |2vpn mesh-group 
mesh-group-namel], 

[edit logical-systems logical-system-name routing-instances routing-instance-name protocols vpls mesh-group 
mesh-group-name], 

[edit routing-instances routing-instance-name protocols evpn vni-options], 

[edit routing-instances routing-instance-name protocols |2vpn mesh-group mesh-group-name], 

[edit routing-instances routing-instance-name protocols vpls mesh-group mesh-group-name], 

[edit switch-options] 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 11.1 for EX Series switches. 

Statement introduced in Junos OS Release 12.3 for ACX Series routers. 

Statement introduced in Junos OS Release 14.1X53-D30 for QFX Series switches. auto option was also 
added at this time. 

auto option added in Junos OS Release 19.1R1 for MX series. 

Statement introduced in cRPD Release 19.4R1. 


Description 

Specify a virtual routing and forwarding (VRF) target community. If you configure the community option 
only, default VRF import and export policies are generated that accept and tag routes with the specified 
target community. The purpose of the vrf-target statement is to simplify the configuration by allowing 
you to configure most statements at the [edit routing-instances] hierarchy level. In effect, this statement 
configures a single policy for import and a single policy for export to replace the per-VRF policies for every 
community. 


You can still create more complex policies by explicitly configuring VRF import and export policies using 
the import and export options. 
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Options 


community—Community name. 


auto—Automatically derives the route target (RT). The auto-derived route targets have higher precedence 
over manually configured RT in vrf-target, vrf-export policies, and vrf-import policies. 


NOTE: Auto-derived route targets are supported only in virtual switch and EVPN routing 
instances. 


import community-name—Allowed communities accepted from neighbors. 


export community-name—Allowed communities sent to neighbors. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Configuring Policies for the VRF Table on PE Routers in VPNs 
Example: Configuring FEC 129 BGP Autodiscovery for VPWS 


CHAPTER 25 


PCEP Configuration Statements 


IN THIS CHAPTER 


pcep | 2234 
delegation-cleanup-timeout | 2235 
delegation-priority | 2237 
destination-ipv4-address | 2238 
destination-port | 2239 
label-switched-path-template | 2240 
Isp-cleanup-timer | 2241 
Isp-external-controller | 2243 
max-unknown-messages | 2244 
max-unknown-requests | 2245 
message-rate-limit | 2246 

pce | 2247 

pce-group (PCE) | 2250 

pce-group (Protocols PCEP) | 2251 
pce-type | 2252 

querier (performance-monitoring) | 2253 
traceoptions (PCE) | 2255 
traceoptions (Protocols PCEP) | 2257 
update-rate-limit | 2259 
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| pcep 


Syntax 


pcep { 
message-rate-limit messages-per-minute; 
pce pce-id; 
pce-group pce-group-id; 
traceoptions; 
update-rate-limit updates-per-minute; 


Hierarchy Level 


[edit protocols] 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Statement introduced in Junos OS Release 16.3R for QFX Series switches. 
Support for ACX Series added in Junos OS Release 17.1R1. 


Description 


Configure the Path Computation Client (PCC) parameters. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


Support of the Path Computation Element Protocol for RSVP-TE Overview | 1356 
Example: Configuring the Path Computation Element Protocol for MPLS RSVP-TE | 1374 


Example: Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support of 
PCE-Initiated Point-to-Point LSPs | 1391 


Example: Configuring Path Computation Element Protocol for MPLS RSVP-TE with Support for 
PCE-Controlled Point-to-Multipoint LSPs | 1406 
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| delegation-cleanup-timeout 


Syntax 


delegation-cleanup-timeout seconds; 


Hierarchy Level 


[edit protocols pcep pce pce-id] 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Support for PTX Series added in Junos OS Release 14.2. 

Support for QFX Series switches added in Junos OS Release 16.1R3. 
Support for ACX Series added in Junos OS Release 17.1R1. 


Description 

Specify the amount of time (in seconds) that a Path Computation Client (PCC) must wait before returning 
control of all LSPs to the routing protocol process after a PCEP session with the main active stateful Path 
Computation Element (PCE) is disconnected. 


NOTE: In compliance with draft-ietf-pce-stateful-pce-09, revoking of PCE-initiated LSP delegations 
by a PCC happens in a make-before-break fashion before the LSPs are redelegated to an alternate 
PCE. Starting in Junos OS Release 18.1R1, the Isp-cleanup-timer must be greater than or equal 
to the delegation-cleanup-timeout for the PCC to revoke the LSP delegations. If not, the 
redelegation timeout interval for the PCC can be set to infinity, where the LSP delegations to 
that PCE remain intact until specific action is taken by the PCC to change the parameters set by 
the PCE. 


Options 
seconds—Time (in seconds) that a PCC must wait before returning control of all LSPs to the routing protocol 
process after a PCEP session with the main active stateful PCE is disconnected. 


A value of 0 indicates immediate delegation cleanup. 

Range: 0 through 2,147,483,647 secondsPrior to Junos OS Release 18.4R1, the maximum range value 
is 600 seconds. 

Default: 30 seconds 


Required Privilege Level 
routing—To view this statement in the configuration. 
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routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pce | 2247 
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| delegation-priority 
Syntax 


delegation-priority priority-number; 


Hierarchy Level 


[edit protocols pcep pce pce-id] 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Support for PTX Series added in Junos OS Release 14.2. 

Support for QFX Series switches added in Junos OS Release 16.1R3. 
Support for ACX Series added in Junos OS Release 17.1R1. 


Description 

Specify the priority number of the active stateful Path Computation Element (PCE). This value is used by 
the Path Computation Client (PCC) to elect a PCE to delegate LSPs. No two PCEs can have the same 
delegation-priority value. The PCC elects the PCE with a lower priority as the main active stateful PCE to 
delegate LSPs. 


Options 

priority-number—Priority number of the active stateful PCE. 
Range: 1 through 65535 
Default: O (no priority is set) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pce | 2247 
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| destination-ipv4-address 


Syntax 


destination-ipv4-address ipv4-address; 


Hierarchy Level 


[edit protocols pcep pce pce-id] 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Support for PTX Series added in Junos OS Release 14.2. 

Support for QFX Series switches added in Junos OS Release 16.1R3. 
Support for ACX Series added in Junos OS Release 17.1R1. 


Description 
Specify the IPv4 address of the Path Computation Element (PCE) to which the Path Computation Client 
(PCC) should connect. 


Options 
ipv4-address—|Pv4 address of the PCE. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pce | 2247 
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| destination-port 


Syntax 


destination-port port-number; 


Hierarchy Level 


[edit protocols pcep pce pce-id] 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Support for PTX Series added in Junos OS Release 14.2. 
Support for QFXswitches added in Junos OS Release 16.1R3. 


Description 
Specify the TCP port number of the Path Computation Element (PCE) to which the Path Computation 
Client (PCC) should connect. 


Options 

port-number—Destination TCP port number. 
Range: 1 through 65535 
Default: 4189 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pce | 2247 
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| label-switched-path-template 


Syntax 


label-switched-path-template { 
(default-template | Isp-template-name); 


} 


Hierarchy Level 


[edit protocols mpls Isp-external-controller Isp-external-controller] 


Release Information 
Statement introduced in Junos OS Release 13.3. 


Description 
Specify the LSP template with parameters for setting up the PCE-initiated LSPs when the PCE initiating 


the LSP does not provide the PCE-initiated parameters. When label-switched-path-template is not 
configured, the default LSP parameters are used. 


Options 
default-template—Specify that the default LSP template be used for the dynamically generated PCE-initiated 
LSPs. 


Isp-template-name—Specify the name of the LSP template to be used for setting up PCE-initated LSPs. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pcep | 2234 
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| Isp-cleanup-timer 
Syntax 


Isp-cleanup-timer seconds; 


Hierarchy Level 


[edit protocols pcep pce pce-id] 
[edit protocols pcep pce-group group-id] 


Release Information 
Statement introduced in Junos OS Release 13.3. 


Description 
Specify the amount of time (in seconds) that the Path Computation Client (PCC) must wait before deleting 
any non-delegated Path Computation Element (PCE)-initiated LSPs from the failed PCE after a PCEP 


session terminates. 


NOTE: In compliance with draft-ietf-pce-stateful-pce-09, revoking of PCE-initiated LSP delegations 
by a PCC happens in a make-before-break fashion before the LSPs are redelegated to an alternate 
PCE. Starting in Junos OS Release 18.1R1, the Isp-cleanup-timer must be greater than or equal 
to the delegation-cleanup-timeout for the PCC to revoke the LSP delegations. If not, the 
redelegation timeout interval for the PCC can be set to infinity, where the LSP delegations to 
that PCE remain intact until specific action is taken by the PCC to change the parameters set by 
the PCE. 


Options 
seconds—Time (in seconds) that the PCC must wait before deleting any non-delegated PCE- initiated LSPs 
from the failed PCE after a PCEP session terminates. Non-delegated PCE-initiated LSPs are deleted 


immediately. 
Range: O through 2147483647 seconds 
Default: 60 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


| pcep | 2234 
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| Isp-external-controller 


Syntax 


Isp-external-controller controller-name; 


Hierarchy Level 


[edit protocols mpls], 
[edit protocols mpls label-switched-path Isp-name] 
[edit protocols spring-traffic-engineering] 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Statement introduced in Junos OS Release 16.1R3 for QFX Series switches. 

Support for ACX Series added in Junos OS Release 17.1. 

Support at the [edit protocols spring-traffic-engineering] hierarchy level introduced in Junos OS Release 
17.2. 

Support at the following hierarchy levels introduced in Junos OS Release 20.1R1: [edit protocols 
source-packet-routing source-routing-path name , [edit protocols source-packet-routing 
source-routing-path name primary name, and [edit protocols source-packet-routing 
source-routing-path-template name. 


Description 


Enable external path computing capability for the device. 


Options 
controller-name—Name of the external path computing entity. By default, pccd is the only allowed LSP 
external controller. 


Values: pccd 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


pcep | 2234 
PCEP Configuration | 1354 
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max-u nknown-messages 


Syntax 


max-unknown-messages messages-per-minute; 


Hierarchy Level 


[edit protocols pcep pce pce-id] 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Support for PTX Series added in Junos OS Release 14.2. 

Support for QFX Series switches added in Junos OS Release 16.1R3. 
Support for ACX Series added in Junos OS Release 17.1R1. 


Description 


Specify the number of unknown messages per minute that the Path Computation Client (PCC) can receive 
at maximum after which the PCEP session is closed. 


Options 

messages-per-minute—Number of unknown messages per minute that the PCC can receive at maximum 
after which the PCEP session is closed. Recommended value is 5. If the number of unknown messages 
received by the PCC is greater than or equal to the maximum number, the PCEP session is closed. 


Range: 1 through 16384 
Default: O (disabled or no limit) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pce | 2247 
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| max-unknown-requests 


Syntax 


max-unknown-requests requests-per-minute; 


Hierarchy Level 


[edit protocols pcep pce pce-id] 
[edit protocols pcep pce-group group-id] 


Release Information 
Statement introduced in Junos OS Release 13.3. 


Description 


Specifies the number of unknown requests per minute that the Path Computation Client (PCC) can receive 
at maximum after which the PCEP session is terminated. 


Options 

requests-per-minute—Number of unknown requests per minute that the PCC can receive at maximum after 
which the PCEP session is terminated. 
Range: O through 16384 (0 disables this statement) 
Default: 5 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pce | 2247 
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| message-rate-limit 
Syntax 


message-rate-limit messages-per-minute; 


Hierarchy Level 


[edit protocols pcep] 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Support for PTX Series added in Junos OS Release 14.2. 
Support for QFX Series added in Junos OS Release 16.1R3. 
Support for ACX Series added in Junos OS Release 17.1R1. 


Description 


Specify the number of messages per minute that the Path Computation Client (PCC) can receive at maximum. 


Options 

messages-per-minute—Number of messages per minute that the PCC can receive at maximum. 
Range: 1 through 16384 
Default: O (disabled or no limit) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pcep | 2234 
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| pce 


Syntax 


pce pce-id { 
authentication-key key; 
authentication-key-chain key-chain; 
delegation-cleanup-timeout seconds; 
delegation-priority priority-number; 
destination-ipv4-address ipv4-address; 
destination-port port-number; 
local-address ip-address; 
Isp-cleanup-timer seconds; 
Isp-provisioning; 
Isp-retry-delegation; 
Isp-retry-delegation-timer seconds; 
max-sid-depth max-sid-depth; 
max-unknown-messages messages-per-minute; 
max-unknown-requests requests-per-minute; 
p2mp-lsp-init-capability; 
p2mp-lsp-report-capability; 
p2mp-lsp-update-capability; 
pce-group pce-group-name; 
pce_traffic_steering; 
pce-type ; 
request-timer seconds; 
request-priority priority; 
spring-capability; 

traceoptions ; 


Hierarchy Level 


[edit protocols pcep] 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Support for PTX Series added in Junos OS Release 14.2. 

Support for QFX Series switches added in Junos OS Release 16.1R3. 

Support for ACX Series added in Junos OS Release 17.1R1. 

Isp-cleanup-timer, Isp-provisioning, max-unknown-requests, request-timer, and request-priority options 
introduced in Junos OS Release 13.3. 

authentication-key key, authentication-key-chain key-chain, and p2mp-Isp-report-capability options 
introduced in Junos OS Release 16.1. 
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max-sid-depth and spring-capability options introduced in Junos OS Release 17.2. 
p2mp-lsp-init-capability and p2mp-Isp-update-capability options introduced in Junos OS Release 18.3R1 
on all platforms. 

pce_traffic_steering option introduced in Junos OS Release 19.4R1 on all platforms. 


Description 


Configure per-Path Computation Element (PCE) parameters. 
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Options 
pce-id—IP address of the PCE. 


authentication-key key—(Optional) Authentication password. It can be up to 126 characters. Characters 
can include any ASCII strings. If you include spaces, enclose all characters in quotation marks (“”). 


It is recommended to define and bind an authentication key for securing a PCEP session, as opposed 
to binding an authentication keychain. 


authentication-key-chain key-chain—(Optional) Authentication keychain password. It can be up to 126 
characters. Characters can include any ASCII strings. If you include spaces, enclose all characters in 
quotation marks (“”). 


local-address ip-address—(Optional) IP address of the local end of the PCEP session, the PCC. 
Isp-retry-delegation—(Optional) Enable retry LSP delegation process. 


Isp-retry-delegation-timer—(Optional) Specify the amount of time (in seconds) that the Path Computation 
Client (PCC) must wait before retrying delegation of Path Computation Element (PCE)-initiated LSPs 
in case of delegation failure or re-delegation. 

Default: 3600 seconds 


Range: O through 4294967294 seconds 


max-sid-depth—(Optional) Specify the maximum value for service identifier (SID) depth. 
Default: 5 
Range: 1 through 5 


p2mp-lsp-init-capability—(Optional) Capability to provision point-to-multipoint RSVP-TE LSPs by a PCE. 
By default, this capability is not supported on a PCC, and should be explicitly configured to enable 
PCE-initated point-to-multipoint LSPs. 


p2mp-lsp-report-capability—(Optional) Capability to report point-to-multipoint RSVP-TE LSPs to a PCE. 
By default, this capability is not supported on a PCC, and should be explicitly configured to enable 
reporting of point-to-multipoint LSPs to a PCE. 


p2mp-lsp-update-capability—(Optional) Capability to update point-to-multipoint RSVP-TE LSP parameters 
by a PCE. By default, this capability is not supported on a PCC, and should be explicitly configured to 
enable updating of PCE-initated point-to-multipoint LSPs. 


pce_traffic_steering—(Optional) Configure the flow specification capability (also called traffic steering 
functionality) for enabling the mapping of PCE-initiated point-to-multipoint LSPs to an MVPN 
routing-instance. 


spring-capability—(Optional) Enable SPRING-based provisioning for the PCE. 


Required Privilege Level 
routing—To view this statement in the configuration. 


routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


pcep | 2234 
PCEP Configuration | 1354 


pce-group (PCE) 
Syntax 

pce-group pce-group-name; 
Hierarchy Level 

[edit protocols pcep pce pce-id] 


Release Information 
Statement introduced in Junos OS Release 12.3. 
Support for PTX Series added in Junos OS Release 14.2. 


Support for QFX Series switches added in Junos OS Release 16.1R3. 


Support for ACX Series added in Junos OS Release 17.1R1. 


Description 


Specify the Path Computation Element (PCE) group to which the configured PCE belongs. 


Options 


pce-group-name—Name of the PCE group. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pce | 2247 


2250 
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| pce-group (Protocols PCEP) 


Syntax 


pce-group pce-group-id { 
delegation-cleanup-timeout seconds; 
max-unknown-messages messages-per-minute; 
pce-type { 
active stateful; 


traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 


flag (all | pcep); 
no-remote-trace; 


Hierarchy Level 


[edit protocols pcep] 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Support for PTX Series added in Junos OS Release 14.2. 

Support for QFX Series switches added in Junos OS Release 16.1R3. 
Support for ACX Series added in Junos OS Release 17.1R1. 


Description 

Configure the Path Computation Element (PCE) group parameters. A maximum of 10 PCE groups can be 
configured at any given point in time. 

The remaining statements are explained separately. 


NOTE: A PCE group can include PCEs that are either only stateful or only active stateful. A 
combination of stateful PCEs and active stateful PCEs in one PCE group is not supported. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pcep | 2234 


pce-type 
Syntax 


pce-type { 
active stateful; 


Hierarchy Level 


[edit protocols pcep pce pce-id] 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Support for PTX Series added in Junos OS Release 14.2. 

Support for QFX Series switches added in Junos OS Release 16.1R3. 
Support for ACX Series added in Junos OS Release 17.1R1. 


Description 


Configure the path computation element (PCE) type: 


e active—Uses LSP state information learned from PCCs to optimize path computations, and actively 
updates LSP parameters in those PCCs that delegated control over their LSPs to the PCE. 


e stateful—Uses LSP state information learned from PCCs to optimize path computations, but does not 
actively update the LSP state. A PCC maintains synchronization with the PCE. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pce | 2247 


2252 


| querier (performance-monitoring) 


Syntax 


querier { 
delay { 
traffic-class tc-value { 

average-sample-size sample size; 
padding-size size; 
query-interval milliseconds; 
rtt-delay-threshold rtt threshold value; 
twcd-delay-threshold twcd threshold value; 


} 
loss { 
traffic-class tc-value { 

average-sample-size sample size; 
loss-threshold loss threshold value; 
loss-threshold-window number of samples for loss threshold; 
measurement-quantity bytes|packets; 
query-interval milliseconds; 


} 
loss-delay { 
traffic-class tc-value { 

average-sample-size sample size; 
loss-threshold loss threshold value; 
loss-threshold-window number of samples for loss threshold; 
measurement-quantity bytes|packets; 
padding-size size; 
query-interval milliseconds; 
rtt-delay-threshold rtt threshold value; 
twcd-delay-threshold twcd threshold value; 


Hierarchy Level 


[edit protocols mpls oam performance-monitoring], 

[edit protocols mpls label-switched-path Isp-name oam performance-monitoring], 

[edit protocols mpls label-switched-path Isp-name primary path-name oam performance-monitoring], 
[edit protocols mpls label-switched-path Isp-name secondary path-name oam performance-monitoring] 
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Release Information 
Statement introduced in Junos OS Release 15.1. 


Command introduced in Junos OS Release 16.1R3 for QFX Series switches. 


Description 


Configure querier options. 


The remaining statements are explained separately. See CLI Explorer. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 
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| traceoptions (PCE) 


Syntax 


traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag (all | pcep); 
no-remote-trace; 


Hierarchy Level 


[edit protocols pcep pce pce-id] 


Description 


Configure the Path Computation Element Protocol (PCEP) tracing options. 


Options 
filename—Name of the file to receive the output of the tracing operation. All files are placed in the directory 
/var/log. 


files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its 
maximum size, it is renamed trace-file.0, then trace-file.1, and so on, until the maximum number of 
trace files is reached. Then the oldest trace file is overwritten. 


Range: 2 through 1000 files 


Default: 2 files. If you specify a maximum number of files, you must also include the size statement 
to specify the maximum file size. 


flag—Area of path computation client process (pccd) to enable debugging output. 


e all—Trace all areas of PCD code. 


e pcep—Trace Path Computation Element Protocol (PCEP) operations. 


no-remote-trace—(Optional) Disable remote tracing options. 
no-world-readable—(Optional) Allow only certain users to read the log file. 


size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB), or gigabytes (GB). 
When atrace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file 
again reaches this size, trace-file.O is renamed trace-file.1 and trace-file is renamed trace-file.O. This 
renaming scheme continues until the maximum number of trace files is reached. Then the oldest trace 
file is overwritten. 


Syntax: xk to specify KB, xm to specify MB, or xg to specify GB. 


Range: 10 KB through the maximum file size supported on your system. 


Default: 1 MB. If you specify a maximum file size, you must also include the files statement to specify 
the maximum number of files. 


world-readable—(Optional) Allow any user to read the log file. 


Required Privilege Level 
routing and trace—To view this statement in the configuration. 
routing-control and trace-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pce | 2247 


2256 
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| traceoptions (Protocols PCEP) 


Syntax 


traceoptions { 
file filename <files number> <size size> <world-readable | no-world-readable>; 
flag flag; 
no-remote-trace; 


Hierarchy Level 


[edit protocols pcep] 


Description 


Configure the Path Computation Element Protocol (PCEP) tracing options. 


Options 
filename—Name of the file to receive the output of the tracing operation. All files are placed in the directory 
/var/log. 


files number—(Optional) Maximum number of trace files. When a trace file named trace-file reaches its 
maximum size, it is renamed trace-file.0, then trace-file.1, and so on, until the maximum number of 
trace files is reached. Then the oldest trace file is overwritten. 


Range: 2 through 1000 files 


Default: 2 files. If you specify a maximum number of files, you must also include the size statement 
to specify the maximum file size. 


flag—Area of path computation client process (pccd) to enable debugging output. 


PCEP Tracing Flags 


e all—Trace all areas of PCCD code 

e pccd-config—All configuration parsing operations 
e pccd-core—PCCD core operations 

e pccd-functions—PCCD function entries and outs 
e pccd-main—PCCD main module 

e pccd-rpd—PCCD communication with RPD 


e pccd-ui—PCCD user interface handling 


no-remote-trace—(Optional) Disable remote tracing options. 
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no-world-readable—(Optional) Allow only certain users to read the log file. 


size size—(Optional) Maximum size of each trace file, in kilobytes (KB), megabytes (MB), or gigabytes (GB). 
When atrace file named trace-file reaches this size, it is renamed trace-file.0. When the trace-file 
again reaches this size, trace-file.O is renamed trace-file.1 and trace-file is renamed trace-file.O. This 


renaming scheme continues until the maximum number of trace files is reached. Then the oldest trace 
file is overwritten. 


Syntax: xk to specify KB, xm to specify MB, or xg to specify GB. 
Range: 10 KB through the maximum file size supported on your system. 


Default: 1 MB. If you specify a maximum file size, you must also include the files statement to specify 
the maximum number of files. 


world-readable—(Optional) Allow any user to read the log file. 


Required Privilege Level 
routing and trace—To view this statement in the configuration. 
routing-control and trace-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pcep | 2234 


2259 


| update-rate-limit 
Syntax 


update-rate-limit updates-per-minute; 


Hierarchy Level 


[edit protocols pcep] 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Support for PTX Series added in Junos OS Release 14.2. 

Support for QFX Series switches added in Junos OS Release 16.1R3. 
Support for ACX Series added in Junos OS Release 17.1R1. 


Description 
Specify the number of updates per minute that the Path Computation Client (PCC) can receive at maximum. 
Updates above this limit are ignored by the PCC. 


Options 

updates-per-minute—Number of updates per minute that the PCC can receive at maximum. 
Range: 1 through 16384 
Default: O (disabled or no limit) 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 


RELATED DOCUMENTATION 


| pcep | 2234 


Operational Commands 


MPLS Operational Commands | 2261 

RSVP Operational Commands | 2478 

LDP Operational Commands | 2551 

CCC and TCC Operational Commands | 2655 


PCEP Operational Commands | 2674 





CHAPTER 26 


MPLS Operational Commands 


IN THIS CHAPTER 


clear mpls Isp | 2263 

clear mpls container-Isp | 2265 

clear performance-monitoring mpls Isp | 2267 
monitor mpls delay rsvp | 2268 

monitor mpls loss rsvp | 2274 

monitor mpls loss-delay rsvp | 2280 

ping mpls bgp | 2285 

ping mpls Isp-end-point | 2288 

ping mpls I2circuit | 2291 

ping mpls I2vpn | 2294 

ping mpls I3vpn | 2297 

request mpls container-Isp | 2300 

request mpls Isp adjust-autobandwidth | 2302 
show connections | 2304 

show dynamic-tunnels database | 2308 
show link-management | 2313 

show link-management peer | 2317 

show link-management routing | 2320 
show link-management statistics | 2324 
show link-management te-link | 2327 

show mpls abstract-hop-membership | 2330 
show mpls admin-groups | 2332 

show mpls association | 2334 

show mpls call-admission-control | 2336 
show mpls container-Isp | 2339 

show mpls context-identifer | 2348 

show mpls correlation label | 2351 


show mpls correlation nexthop-id | 2352 
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show mpls cspf | 2354 

show mpls diffserv-te | 2357 

show mpls interface | 2359 

show mpls egress-protection | 2361 

show mpls interface | 2364 

show mpls label usage | 2367 

show mpls label usage label-range | 2371 
show mpls Isp | 2374 

show mpls Isp abstract-computation | 2400 
show mpls Isp autobandwidth | 2403 

show mpls path | 2406 

show mpls srlg | 2408 

show mpls static-Isp | 2410 

show performance-monitoring mpls Isp | 2414 
show route forwarding-table | 2422 

show route table | 2433 

show ted database | 2452 

show ted link | 2464 

show ted protocol | 2469 

traceroute mpls bgp | 2471 

transit (Chained Composite Next Hops) | 2475 
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| clear mpls Isp 


List of Syntax 
Syntax on page 2263 
Syntax (EX and QFX Series Switches) on page 2263 


Syntax 


clear mpls Isp 

<all> 

<autobandwidth> 

<counters> 

<logical-system (all | logical-system-name)> 
<name name> 

<optimize | optimize-aggressive> 

<path regular-expression> 

<statistics> 


Syntax (EX and QFX Series Switches) 


clear mpls Isp 

<all> 

<autobandwidth> 

<name name> 

<optimize | optimize-aggressive> 
<path regular-expression> 
<statistics> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
Command introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 


Release the routes and states associated with MPLS label-switched paths (LSPs), and start new LSPs. 


= CAUTION: This command disconnects existing Resource Reservation Protocol (RSVP) 
A sessions on the ingress routing device. If there is a time lag between the old path being 
torn down and the new path being set up, this command might impact traffic traveling 


along the LSPs. 
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Options 

all—Reset and restart all LSPs that originated from this routing device; that is, all LSPs for which this routing 
device is the ingress routing device. Depending on the number of LSPs involved, it might take a while 
to restart all the LSPs. 


autobandwidth—(Optional) Clear LSP autobandwidth counters. 
counters—(Optional) Reset the flap and the MBB counters to zero. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


name name—(Optional) Reset and restart the specified LSP or group of LSPs. You can include wildcard 
characters in the interface name, as described in the Junos Network Interfaces Configuration Guide. 


optimize | optimize-aggressive—(Optional) Run nonpreemptive optimization or aggressive optimization 
computation now. 


path regular-expression—(Optional) Clear the specific LSP path matching the specified regular expression. 


statistics—(Optional) Clear LSP statistics. You cannot clear the MPLS LSP statistics using a regular expression 
(name and path options) on transit routers. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 


show mpls Isp | 2374 


show rsvp session | 2513 


List of Sample Output 
clear mpls Isp all on page 2264 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 


Sample Output 


clear mpls Isp all 


user@host> clear mpls Isp all 
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| clear mpls container-Isp 


Syntax 


clear mpls container-lsp 

<autobandwidth> 

<history> 

<logical-system (all | logical-system-name)> 
<member> 

<name name> 

<optimize | optimize-aggressive> 
<statistics> 


Release Information 
Statement introduced in Junos OS Release 14.2. 
Statement introduced for QFX Switches in Junos OS Release 15.1X53-D30. 


Description 
Release the routes and states associated with MPLS container label-switched paths (LSPs), and start new 
LSPs. 


Options 

none—Reset and restart all LSPs that originated from this routing device; that is, all LSPs for which this 
routing device is the ingress routing device. Depending on the number of LSPs involved, it might take 
a while to restart all the LSPs. 


autobandwidth—(Optional) Clear LSP autobandwidth counters. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


name name—(Optional) Reset and restart the specified LSP or group of LSPs. You can include wildcard 
characters in the interface name, as described in the Junos Network Interfaces Configuration Guide. 


optimize | optimize-aggressive—(Optional) Run nonpreemptive optimization or aggressive optimization 
computation now. 


statistics—(Optional) Clear LSP statistics. You cannot clear the MPLS LSP statistics using a regular expression 
(name and path options) on transit routers. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 


show mpls container-Isp | 2339 


request mpls container-Isp | 2300 


List of Sample Output 

clear mpls container-Isp on page 2266 

clear mpls container-Isp name on page 2266 
clear mpls container-Isp statistics on page 2266 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 


Sample Output 
clear mpls container-Isp 


user@host> clear mpls container-Isp 


clear mpls container-Isp name 


user@host> clear mpls container-lsp name name 


clear mpls container-Isp statistics 


user@host> Clear mpls container-lsp statistics 
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| clear performance-monitoring mpls Isp 


Syntax 


clear performance-monitoring mpls Isp 
<name Isp-name> 


Release Information 
Command introduced in Junos OS Release 15.1. 


Description 


Restart the performance monitoring statistics. 


Options 


none—Reset and restart all performance monitoring for all LSPs. 


name Isp-name—(Optional) Reset and restart performance monitoring for the specified LSP. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 


performance-monitoring (Protocols MPLS) | 1893 


show performance-monitoring mpls Isp | 2414 


List of Sample Output 
clear performance-monitoring mpls Isp on page 2267 


Output Fields 


When you enter this command, performance monitoring is restarted. 


| Sample Output 


clear performance-monitoring mpls Isp 


user@host> clear performance-monitoring mpls Isp 
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| monitor mpls delay rsvp 


Syntax 


monitor mpls delay rsvp Isp-name 
<detail> 

<count count> 

<interval seconds> 

<padding-size padding-size> 
<traffic-class traffic-class> 


Release Information 
Command introduced in Junos OS Release 14.2. 


Description 
Perform an on-demand delay measurement and display the measured values for associated bidirectional 
MPLS ultimate hop popping (UHP) point-to-point label-switched paths (LSPs). 


Options 
Isp-name—Name of the associated bidirectional MPLS UHP LSP for which the delay measurement is 
performed. 


detail—(Optional) Display detailed output of the LSP delay measurement. 


count count—(Optional) Specify the number of delay measurements to be carried out for the MPLS UHP 
LSP. For LSP delay measurement, the number of queries sent is the specified count number plus one 
additional query, because the LSP delay is measured using successive messages. 


Default: 10 
Range: 1 through 1000000 


interval seconds—(Optional) Specify in seconds the interval between two successive query messages. 


Range: 1 through 255 seconds 


padding-size padding-size— (Optional) Specify the length of padding TLV to be included in the query 
message. 
Range: O through 1500 


traffic-class traffic-class—(Optional) Specify the traffic class for the LSP delay measurement. When the 
traffic-class value is not specified, the default traffic-class code-point of 111 is used. 


Range: O though 7 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


monitor mpls loss rsvp | 2274 
monitor mpls loss-delay rsvp | 2280 


Example: Configuring On-Demand Loss and Delay Measurement | 395 


List of Sample Output 
monitor mpls Isp delay rsvp count on page 2270 
monitor mpls Isp delay rsvp count detail on page 2271 


Output Fields 
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Table 37 on page 2269 describes the output fields for the monitor mpls delay rsvp command. Output fields 


are listed in the approximate order in which they appear. 


Table 37: monitor mpls delay rsvp Output Fields 


Field Name 


Current two-way 
channel delay 


Current round-trip-time 


Best two-way channel 
delay 


Worst two-way channel 
delay 


Average two-way 
channel delay 


Best round-trip-time 


Worst round-trip-time 


Average round-trip-time 


Average forward delay 
variation 


Average reverse delay 
variation 


Field Description 


Sum of packet delays, excluding the processing time of the remote provider edge 
(PE) router. 


Total time taken for completing round-trip of packet. 


Best available two-way channel delay count. 


Worst available two-way channel delay count. 


Average of the available two-way channel delay counts. 


Best available round-trip-time count. 


Worst available round-trip-time count. 


Average of the available round-trip-time counts. 


Average of the variation in forward delay. 


Average of the variation in reverse delay. 


Level of 
Output 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


Table 37: monitor mpls delay rsvp Output Fields (continued) 


Field Name 

DM queries sent 

DM responses received 
DM queries timedout 


DM responses dropped 
due to errors 


Response code 


Querier transmit 
timestamp 


Responder receive 
timestamp 


Responder transmit 
timestamp 


Querier receive 
timestamp 


| Sample Output 


Field Description 


Number of queries sent for delay measurement. 


Number of responses received for delay measurement queries. 


Number of timed out queries sent for delay measurement. 


Number of loss measurement responses dropped due to errors. 


Status of the messages used for delay measurement. Response code can be one 
of the following: 


e Success—Successful response code. 


e Failed—Failed response code. 


Timestamp on the query message when the message is sent out the ingress PE 
router (querier). This is done in the hardware before packet is sent out of an 
interface. 


Timestamp on the response message when the message is received by the egress 
PE router (responder). This is done in the hardware before packet is received by 


an interface. 


Timestamp on the query message when the message is sent out the egress PE 
router (responder). This is done in the hardware before packet is sent out of an 
interface. 


Timestamp on the response message when the message is received by the ingress 
PE router (querier). This is done in the hardware before packet is received by an 
interface. 


monitor mpls Isp delay rsvp count 


user@host> monitor mpls Isp delay rsvp LSP-A count 2 
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Level of 
Output 


All Levels 


All Levels 


All Levels 


All Levels 


detail 


detail 


detail 


detail 


detail 


(1) 

Current two-way channel delay 
Current round-trip-time 

(2) 

Current two-way channel delay 


Current round-trip-time 


Best two-way channel delay 
Worst two-way channel delay 
Average two-way channel delay 
Best round-trip-time 


Worst round-trip-time 





Average round-trip-tim 








44 usecs 


3243 usecs 


45 usecs 


1752 usecs 


44 usecs 
45 usecs 
ASeuSsec's 
1752 usecs 
S24 Seusecs 


2498 usecs 
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Average forward delay variation 1 usecs 
Average reverse delay variation 1 usecs 
DM queries sent 2 
DM responses received 2 
DM queries timedout 0 
DM responses dropped due to errors 0 


monitor mpls Isp delay rsvp count detail 


user@host> monitor mpls Isp delay rsvp LSP-A count 2 detail 














(1) 

Response code Success 

Querier transmit timestamp 1404129122 secs, 479955401 nsecs 
Responder receive timestamp 1404129122 secs, 468519022 nsecs 
Responder transmit timestamp 1404129122 secs, 470255123 nsecs 
Querier receive timestamp 1404129122 secs, 481736403 nsecs 
Current two-way channel delay 44 usecs 

Current round-trip-time 1781 usecs 

(2) 

Response code Success 

Querier transmit timestamp 1404129123 secs, 480926210 nsecs 
Responder receive timestamp 1404129123 secs, 469488696 nsecs 
Responder transmit timestamp 1404129123 secs, 471130706 nsecs 
Querier receive timestamp 1404129123 secs, 482613911 nsecs 
Current two-way channel delay 45 usecs 


Current round-trip-time 


1687 usecs 
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Best two-way channel delay : 44 usecs 
Worst two-way channel delay : 45 usecs 
Average two-way channel delay : 45 usecs 
Best round-trip-time : 1687 usecs 
Worst round-trip-time 8 Isl wsxses 
Average round-trip-tim : 1734 usecs 
Average forward delay variation : 1 usecs 
Average reverse delay variation : 1 usecs 


DM queries sent 





2 
DM responses received ee 
DM queries timedout 0 

0 


DM responses dropped due to errors 





user@host> monitor mpls loss-delay-measurement lsp LSP1_A_to_B count 2 
(i) 











Current forward loss 0 packets 
Current forward loss ratio 0.000000 
Current forward throughput 8 O.957 Imes 
Current reverse loss 0 packets 
Current reverse loss ratio 0.000000 
Current reverse throughput 7 02962 kpps 
Current two-way channel delay : 48 usecs 
Current round-trip-time : 3476 usecs 
(2) 

Current forward loss 0 packets 
Current forward loss ratio 0.000000 
Current forward throughput 02599" kpps 
Current reverse loss 0 packets 
Current reverse loss ratio 0.000000 
Current reverse throughput 8 OW. S99) ies 
Current two-way channel delay : 50 usecs 
Current round-trip-time : 1856 usecs 
Cumulative forward transmit count g SS) 7 
Cumulative forward loss : O packets 
Average forward loss ratio : 0.000000 
Average forward throughput 8 OW. 78 lems 
Cumulative reverse transmit count g 1562 
Cumulative reverse loss : O packets 
Average reverse loss ratio : 0.000000 
Average reverse throughput : 0.780 kpps 
Best two-way channel delay : 48 usecs 


Worst two-way channel delay : 50 usecs 


Average two-way channel delay 
Best round-trip-time 


Worst round-trip-time 





Average round-trip-tim 


Average forward delay variation 





Average reverse delay variation 


LDM queries sent 
LDM responses received 


LDM queries timedout 





LDM responses dropped due to errors 


49 usecs 
1856 usecs 
3476 usecs 
2445 usecs 
(usc s 


1 usecs 


(ey ey [ou 163} 
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| monitor mpls loss rsvp 


Syntax 


monitor mpls loss rsvp Isp-name 
<detail> 

<bytes> 

<count count> 

<interval seconds> 
<traffic-class traffic-class> 


Release Information 
Command introduced in Junos OS Release 14.2. 


Description 
Perform an on-demand loss measurement and display the measured values for associated bidirectional 
MPLS ultimate hop popping (UHP) point-to-point label-switched paths (LSPs). 


Options 
Isp-name—Name of the associated bidirectional MPLS UHP LSP for which the loss measurement is 
performed. 


detail—(Optional) Display detailed output of the LSP loss measurement. 


bytes—(Optional) Specify the measurement quantity for the LSP loss measurement as bytes. By default, 
LSP loss is measured in packets. 


NOTE: The byte count of a packet sent or received over a channel counts only the payload, 
including the total length of that packet and excluding the headers, labels, and framing of the 
channel itself. 


count count—(Optional) Specify the number of loss measurements to be carried out for the MPLS UHP 
LSP. For LSP loss measurement, the number of queries sent is the specified count number plus one 
additional query, because the LSP loss is measured using successive messages. 


Default: 10 
Range: 1 through 1000000 


interval seconds—(Optional) Specify in seconds the interval between two successive query messages. 


Range: 1 through 255 seconds 
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traffic-class traffic-class—(Optional) Specify the traffic class and enable traffic-class-statistics for the LSP 
loss measurement. 


Range: O though 7 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


monitor mpls delay rsvp | 2268 
monitor mpls loss-delay rsvp | 2280 


Example: Configuring On-Demand Loss and Delay Measurement | 395 


List of Sample Output 
monitor mpls Isp loss rsvp count on page 2277 
monitor mpls Isp loss rsvp detail on page 2278 


Output Fields 


Table 37 on page 2269 describes the output fields for the monitor mpls loss rsvp command. Output fields 
are listed in the approximate order in which they appear. 


Table 38: monitor mpls loss rsvp Output Fields 


Level of 
Field Name Field Description Output 
Current forward loss Difference between the current forward transmit count and the current forward | All Levels 

receive count. 

Current forward loss Total packet loss (current forward loss divided by current forward transmit count). | All Levels 
ratio 
Current forward Current forward transmit count divided by 1000. All Levels 
throughput 
Current reverse loss Difference between the current reverse transmit count and the current reverse All Levels 


receive count. 


Current reverse loss ratio | Total packet loss (current reverse loss divided by current reverse transmit count). All Levels 


Current reverse Current reverse transmit count divided by 1000. All Levels 
throughput 


Table 38: monitor mpls loss rsvp Output Fields (continued) 


Field Name 


Cumulative forward 
transmit count 


Cumulative forward loss 


Average forward loss 


ratio 


Average forward 
throughput 


Cumulative reverse 
transmit count 


Cumulative reverse loss 


Average reverse loss 


ratio 


Average reverse 
throughput 


LM queries sent 


LM responses received 


LM queries timedout 


LM responses dropped 
due to errors 


Response code 


Origin timestamp 


Field Description 


Cumulative forward transmit counter value at the time the loss measurement 


message was originated. 


Cumulative forward loss counter value at the time the loss measurement message 
was originated. 


Average packet loss (current forward loss divided by current forward transmit 
count). 


Average forward transmit count divided by 1000. 


Cumulative reverse transmit counter value at the time the loss measurement 


message was originated. 


Difference between the cumulative reverse transmit count and the cumulative 
reverse receive count. 


Average packet loss (average reverse loss divided by average reverse transmit 
count). 


Average reverse transmit count divided by 1000. 


Number of queries sent for loss measurement. 


Number of responses received for loss measurement queries. 


Number of timed out queries sent for loss measurement. 


Number of loss measurement responses dropped due to errors. 


Status of the messages used for loss measurement. Response code can be one of 
the following: 


e Success—Successful response code. 


e Failed—Failed response code. 


Time and date the loss measurement message is originated without any specific 
format (NTP and PTP). 
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Level of 


Output 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


detail 


detail 


Table 38: monitor mpls loss rsvp Output Fields (continued) 


Field Name 


Forward transmit count 
Forward receive count 
Reverse transmit count 
Reverse receive count 
Current forward transmit 


count 


Current forward receive 
count 


Current reverse transmit 
count 


Current reverse receive 
count 


| Sample Output 


Field Description 


Forward transmit counter value at the time the loss measurement message was 


originated. 


Forward receive counter value at the time the loss measurement message was 
originated. 


Reverse transmit counter value at the time the loss measurement message was 
originated. 


Reverse receive counter value at the time the loss measurement message was 
originated. 


Difference between the current forward transit count and the previous forward 
transit count. 


Difference between the current forward receive count and the previous forward 
receive count. 


Difference between the current reverse transit count and the previous reverse 
transit count. 


Difference between the current reverse receive count and the previous reverse 
receive count. 


monitor mpls Isp loss rsvp count 


user@host> monitor mpls Isp loss rsvp count 2 





(1) 

Current forward loss 0 packets 
Current forward loss ratio 0.000000 
Current forward throughput 1.006 kpps 
Current reverse loss 0 packets 
Current reverse loss ratio 0.000000 
Current reverse throughput 1.007 kpps 


Level of 


Output 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 
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(2) 

Current forward loss 
Current forward loss ratio 
Current forward throughput 
Current reverse loss 
Current reverse loss ratio 


Current reverse throughput 


Cumulative forward transmit count 





Cumulative forward loss 

Average forward loss ratio 
Average forward throughput 
Cumulative reverse transmit count 
Cumulative reverse loss 

Average reverse loss ratio 


Average reverse throughput 


LM queries sent 


LM responses received 





LM queries timedout 





LM responses dropped due to errors 


monitor mpls Isp loss rsvp detail 


user@host> monitor mpls Isp loss rsvp detail 


(0) 

Response code 

Origin timestamp 
Forward transmit count 
Forward receive count 


Reverse transmit count 





Reverse receive count 
(els) 

Response code 

Origin timestamp 
Forward transmit count 
Forward receive count 


Reverse transmit count 





Reverse receive count 
Current forward transmit count 
Current forward receive count 


Current forward loss 





Current forward loss ratio 


packets 
000000 
eS! lejos) 
packets 
000000 
-562 kpps 


ese oS oe we S&S S&S 


155% 

0 packets 
0.000000 
0.782 kpps 
ESI, 

0 packets 
0.000000 
0.784 kpps 


er (er (sy (65) 


Success 

1404129082 secs, 905571890 nsecs 
83040 

83040 

83100 

83100 


Success 

1404129083 secs, 905048410 nsecs 
83841 

83841 

83904 

83904 

801 

801 

0 packets 

0.000000 
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Current forward throughput 
Current reverse transmit count 


Current reverse receive count 





Current reverse loss 


Current reverse loss ratio 





Current reverse throughput 
(2) 

Response code 

Origin timestamp 

Forward transmit count 
Forward receive count 
Reverse transmit count 


Reverse receive count 








Current forward transmit count 
Current forward receive count 
Current forward loss 

Current forward loss ratio 
Current forward throughput 


Current reverse transmit count 


Current reverse receive count 





Current reverse loss 
Current reverse loss ratio 


Current reverse throughput 


Cumulative forward transmit count 





Cumulative forward loss 

Average forward loss ratio 
Average forward throughput 
Cumulative reverse transmit count 
Cumulative reverse loss 

Average reverse loss ratio 


Average reverse throughput 


LM queries sent 


LM responses received 





LM queries timedout 





LM responses dropped due to errors 


0.801 kpps 
804 

804 

0 packets 
0.000000 
0.804 kpps 


Success 
1404129084 secs, 904828715 nsecs 
84423 
84423 
84487 
84487 

582 

582 

0 packets 
0.000000 
0.582 kpps 
583 

583 

0 packets 
0.000000 
W.58S lems 


1383 

0 packets 
0.000000 
0.692 kpps 
ASI) 

0 packets 
0.000000 
0.694 kpps 


(ey tS) (3) (68 
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| monitor mpls loss-delay rsvp 


Syntax 


monitor mpls loss-delay rsvp Isp-name 
<detail> 

<bytes> 

<count count> 

<interval seconds> 

<padding-size padding-size> 
<traffic-class traffic-class> 


Release Information 
Command introduced in Junos OS Release 14.2. 


Description 

Perform a simultaneous on-demand loss and delay measurement using combined loss and delay messages, 
and display the measured values for associated bidirectional MPLS ultimate hop popping (UHP) 
point-to-point label-switched paths (LSPs). 


Options 
Isp-name—Name of the associated bidirectional MPLS UHP LSP for which the delay measurement is 
performed. 


detail—(Optional) Display detailed output of the LSP delay measurement. 


bytes—(Optional) Specify the measurement quantity for the LSP loss measurement as bytes. By default, 
LSP loss is measured in packets. 


NOTE: The byte count of a packet sent or received over a channel counts only the payload, 
including the total length of that packet and excluding the headers, labels, and framing of the 
channel itself. 


count count—(Optional) Specify the number of delay measurements to be carried out for the MPLS UHP 
LSP. For LSP delay measurement, the number of queries sent is the specified count number plus one 
additional query, because the LSP delay is measured using successive messages. 


Default: 10 
Range: 1 through 1000000 


interval seconds—(Optional) Specify in seconds the interval between two successive query messages. 


Range: 1 through 255 seconds 
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padding-size padding-size—(Optional) Specify the length of padding TLV to be included in the query 
message. 
Range: O through 1500 


traffic-class traffic-class—(Optional) Specify the traffic class for the LSP delay measurement. When the 
traffic-class value is not specified, the default traffic-class code-point of 111 is used. 


Range: O though 7 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


monitor mpls loss rsvp | 2274 
monitor mpls delay rsvp | 2268 


Example: Configuring On-Demand Loss and Delay Measurement | 395 


List of Sample Output 
monitor mpls loss-delay rsvp count on page 2281 
monitor mpls loss-delay rsvp count detail on page 2282 


Output Fields 


For output field descriptions, see the monitor mpls loss rsvp and monitor mpls delay rsvp commands. 


Sample Output 


monitor mpls loss-delay rsvp count 


user@host> monitor mpls loss-delay rsvp LSP-A count 2 


(1) 








Current forward loss 0 packets 
Current forward loss ratio 0.000000 
Current forward throughput 0.957 Imes 
Current reverse loss : O packets 
Current reverse loss ratio 0.000000 
Current reverse throughput 0.962 kpps 
Current two-way channel delay 48 usecs 
Current round-trip-time : 3476 usecs 


(2) 


Current forward loss 

Current forward loss ratio 
Current forward throughput 
Current reverse loss 

Current reverse loss ratio 
Current reverse throughput 
Current two-way channel delay 


Current round-trip-time 


Cumulative forward transmit count 





Cumulative forward loss 

Average forward loss ratio 
Average forward throughput 
Cumulative reverse transmit count 
Cumulative reverse loss 

Average reverse loss ratio 


Average reverse throughput 


Best two-way channel delay 
Worst two-way channel delay 
Average two-way channel delay 
Best round-trip-time 


Worst round-trip-time 





Average round-trip-tim 








packets 
.000000 
DIS! Ijeisiss 
packets 
000000 
WO. S99) lees 
DUMUSeC's 
IGSG wsecs 


ee es we ©& 


1557) 

0 packets 
0.000000 
0.778 kpps 
1562 

0 packets 
0.000000 
0.780 kpps 





48 usecs 
DOMUS CSS 
49 usecs 
IGSG wsSees 
S4yV/iomusecs 


2445 usecs 
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Average forward delay variation 1 usecs 
Average reverse delay variation 1 usecs 
LDM queries sent S 
LDM responses received 3 
LDM queries timedout 0 
LDM responses dropped due to errors 0 





monitor mpls loss-delay rsvp count detail 


user@host> monitor mpls loss-delay rsvp LSP-A count 2 detail 





(0) 

Response code SECUCCOSIS 
Forward transmit count : 142049 
Forward receive count : 142049 
Reverse transmit count B Lae 7 
Reverse receive count 8 MAZINS 7 


Querier transmit timestamp 1404129161 secs, 554422723 nsecs 





Responder receive timestamp 


Responder transmit timestamp 





Querier receive timestamp 
els) 

Response code 

Forward transmit count 
Forward receive count 
Reverse transmit count 


Reverse receive count 





Current forward transmit count 
Current forward receive count 
Current forward loss 

Current forward loss ratio 
Current forward throughput 


Current reverse transmit count 


Current reverse receive count 





Current reverse loss 


Current reverse loss ratio 





Current reverse throughput 
Querier transmit timestamp 


Responder receive timestamp 





Responder transmit timestamp 


Querier receive timestamp 





Current two-way channel delay 
Current round-trip-time 

(2) 

Response code 

Forward transmit count 
Forward receive count 

Reverse transmit count 


Reverse receive count 








Current forward transmit count 
Current forward receive count 
Current forward loss 

Current forward loss ratio 
Current forward throughput 


Current reverse transmit count 


Current reverse receive count 





Current reverse loss 


Current reverse loss ratio 





Current reverse throughput 
Querier transmit timestamp 


Responder receive timestamp 





Responder transmit timestamp 


1404129161 
1404129161 
1404129161 


Success 
143049 
143049 
143168 
143168 
1000 

1000 

0 packets 
0.000000 
1.000 kpps 
1001 

1001 

0 packets 
0.000000 
1.001 kpps 
1404129162 
1404129162 
1404129162 
1404129162 
ASMusces 


2943 usecs 


Success 
143677 
143677 
143799 
143799 

628 

628 

0 packets 
0.000000 
0.627 kpps 
@sd 

Sil 

0 packets 
0.000000 
0.630 kpps 
1404129163 
1404129163 
1404129163 


secs, 
secs, 


secs, 


secs, 
secs, 
secs, 


secs, 


secs, 
secs, 


secs, 


542877570 
546004545 
SSIDIDSZ Y 


554465742 
542919166 
545812736 
Sono Hao) 


DDOOGES 1D 
545150128 
546918408 


NSecs 


nsecs 


SSeS: 


nsecs 


nsecs 


Nnsecs 


Nnsecs 


Nnsecs 


NnsSecs 


Seer 
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Querier receive timestamp 





Current two-way channel delay 


Current round-trip-time 


Cumulative forward transmit count 
Cumulative forward loss 

Average forward loss ratio 
Average forward throughput 
Cumulative reverse transmit count 
Cumulative reverse loss 

Average reverse loss ratio 


Average reverse throughput 


Best two-way channel delay 
Worst two-way channel delay 
Average two-way channel delay 
Best round-trip-time 


Worst round-trip-time 





Average round-trip-tim 
Average forward delay variation 


Average reverse delay variation 


LDM queries sent 


LDM responses received 





LDM queries timedout 





LDM responses dropped due to errors 


1404129163 secs, 


48 usecs 


1816 usecs 


1628 

0 packets 
0.000000 
O2Sl3s" kpps 
1632 

0 packets 
0.000000 
0.815 kpps 


48 usecs 
AS) US@CS 
49 usecs 
Tete wusecs 
Slviomusees 
2645 usecs 
i wsees 


0 usecs 


ei Ss) te) 


558515047 nsecs 
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| ping mpls bgp 


Syntax 


ping mpls bgp fec 

<bottom-label-ttl> 

<count count> 

<destination address> 

<detail> 

<exp forwarding-class> 

<instance routing-instance-name> 
<logical-system (all | logical-system-name)> 
<size bytes> 

<source source-address> 


<sweep> 


Release Information 
Command introduced in Junos OS Release 11.1. 


Description 
Check the operability of MPLS BGP-signaled label-switched path (LSP) connections. Press Ctrl+c to interrupt 
a ping mpls bgp command. 


NOTE: The ping mpls bgp fec command only supports single paths. 


Options 
bottom-label-ttl—(Optional) Time-to-live (TTL) value for the bottom label in the label stack. The range of 
values is 1 through 255. The default value is 255. 


count count—(Optional) Number of ping requests to send. If count is not specified, five ping requests are 
sent. The range of values is 1 through 1,000,000. The default value is 5. 


destination address—(Optional) Specify an address other than the default (127.0.0.1/32) for the ping echo 
requests. The address can be anything within the 127/8 subnet. 


detail—(Optional) Display detailed information about the echo requests sent and received. 
exp forwarding-class—(Optional) Value of the forwarding class for the MPLS ping packets. 
fec—Ping a BGP-signaled LSP using the forwarding equivalence class (FEC) prefix and length. 


instance routing-instance-name—(Optional) Allows you to ping a combination of the routing instance and 
forwarding equivalence class (FEC) associated with an LSP. 
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logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on 
the specified logical system. 


size bytes—(Optional) Size of the LSP ping request packet (88 through 65468 bytes). Packets are 4-byte 
aligned. For example, If you enter a size of 89, 90, 91, or 92, the router or switch uses a size value of 
92 bytes. If you enter a packet size that is smaller than the minimum size, an error message is displayed 
reminding you of the 88-byte minimum. 


source source-address—(Optional) IP address of the outgoing interface. This address is sent in the IP source 
address field of the ping request. If this option is not specified, the default address is usually the 
loopback interface (lo.0). 


sweep—(Optional) Automatically determine the size of the maximum transmission unit (MTU). 


Additional Information 

If the LSP changes, the label and interface information displayed when you issued the ping command 
continues to be used. You must configure MPLS at the [edit protocols mpls] hierarchy level on the remote 
router or switch to ping an LSP terminating there. You must configure MPLS even if you intend to ping 
only BGP forwarding equivalence classes (FECs). 


In asymmetric MTU scenarios, the echo response might be dropped. For example, if the MTU from System 
A to System B is 1000 bytes, the MTU from System B to System A is 500 bytes, and the ping request 
packet size is 1000 bytes, the echo response is dropped because the PAD TLV is included in the echo 
response, making it too large. 


NOTE: In a Juniper-Cisco interoperation network scenario, a point-to-multipoint LSP ping echo 
reply message from a Cisco device in a different IGP area is dropped on the Juniper device when 
the source address of the reply message is an interface address other than the loopback address 
or router ID. Starting in Junos OS Release 13.3X8, 14.2R6, 15.1R4, 15.1F6, 15.1F5-S8, 16.1R1, 
and later releases, such point-to-multipoint LSP ping echo reply messages are accepted by the 
Juniper device and the messages get logged as uncorrelated responses. 


Required Privilege Level 
network 


List of Sample Output 
ping mpls bgp fec count on page 2287 


Output Fields 

When you enter this command, you are provided feedback on the status of your request. An exclamation 
point (!) indicates that an echo reply was received. A period (.) indicates that an echo reply was not received 
within the timeout period. An x indicates that an echo reply was received with an error code. Packets with 
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error codes are not counted in the received packets count. They are accounted for separately. To display 
the error codes, use the detail option (for example, ping mpls bgp 10.255.245.222 detail). 


| Sample Output 
ping mpls bgp fec count 


user@host> ping mpls bgp 10.255.245.222 count 10 


!!lxxx...x--- lsping statistics ---10 packets transmitted, 3 packets received, 70% 


packet loss 4 packets received with error status, not counted as received. 
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ping mpls Isp-end-point 
Syntax 


ping mpls Isp-end-point prefix-name 
<count count> 

<destination address> 

<detail> 

<exp forwarding-class> 

<instance routing-instance-name> 
<logical-system (all | logical-system-name)> 
<size bytes> 

<source source-address> 


<sweep> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 
The size and sweep options were introduced in Junos OS Release 9.6. 
The instance option was introduced in Junos OS Release 10.0. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Check the operability of MPLS label-switched path (LSP) endpoint connections. Type Ctrl+c to interrupt 
a ping mpls command. 


Options 
count count—(Optional) Number of ping requests to send. If count is not specified, five ping requests are 
sent. The range of values is 1 through 1,000,000. The default value is 5. 


destination address—(Optional) Specify an address other than the default (127.0.0.1/32) for the ping echo 
requests. The address can be anything within the 127/8 subnet. 


detail—(Optional) Display detailed information about the echo requests sent and received. 
exp forwarding-class—(Optional) Value of the forwarding class for the MPLS ping packets. 


instance routing-instance-name—(Optional) Ping a combination of the routing instance and forwarding 
equivalence class (FEC) associated with an LSP connection. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on 
the specified logical system. 


prefix-name—LDP forwarding equivalence class (FEC) prefix or RSVP LSP endpoint address. 
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size bytes—(Optional) Size of the LSP ping request packet. If the endpoint is LDP-based, the minimum size 
of the packet is 88 bytes. If the endpoint is RSVP-based, the minimum size of the packet is 100 bytes. 
The maximum size in either case is 65468 bytes. 


source source-address—(Optional) IP address of the outgoing interface. This address is sent in the IP source 
address field of the ping request. If this option is not specified, the default address is usually the 
loopback interface (lo.0). 


sweep—(Optional) Automatically determine the size of the maximum transmission unit (MTU). 


Additional Information 

If the LSP changes, the label and interface information displayed when you issued the ping command 
continues to be used. You must configure MPLS at the [edit protocols mpls] hierarchy level on the remote 
router or switch to ping an LSP terminating there. You must configure MPLS even if you intend to ping 
only LDP forwarding equivalence classes (FECs). 


In asymmetric MTU scenarios, the echo response might be dropped. For example, if the MTU from System 
A to System B is 1000 bytes, the MTU from System B to System A is 500 bytes, and the ping request 
packet size is 1000 bytes, the echo response is dropped because the PAD TLV is included in the echo 
response, making it too large. 


NOTE: Ina Juniper-Cisco interoperation network scenario, a point-to-multipoint LSP ping echo 
reply message from a Cisco device in a different IGP area is dropped on the Juniper device when 
the source address of the reply message is an interface address other than the loopback address 
or router ID. Starting in Junos OS Release 13.3X8, 14.2R6, 15.1R4, 15.1F6, 15.1F5-S8, 16.1R1, 
and later releases, such point-to-multipoint LSP ping echo reply messages are accepted by the 
Juniper device and the messages get logged as uncorrelated responses. 


Required Privilege Level 
network 


List of Sample Output 
ping mpls Isp-end-point detail on page 2290 


Output Fields 

When you enter this command, you are provided feedback on the status of your request. An exclamation 
point (!) indicates that an echo reply was received. A period (.) indicates that an echo reply was not received 
within the timeout period. An x indicates that an echo reply was received with an error code. Packets with 
an error code are not counted in the received packets count. They are accounted for separately. 


| Sample Output 


ping mpls Isp-end-point detail 


user@host> ping mpls Isp-end-point 10.255.245.119 detail 








Request for seq 1, to in 
Reply for seq 1, return 
Request for seq 2, to in 
Reply for seq 2, return 
Request for seq 3, to in 
Reply for seq 3, return 
Request for seq 4, to in 
Reply for seq 4, return 
Request for seq 5, to in 











Reply for seq 5, return 


=== Ising Siairisties: == 


5 packets transmitted, 5 packe 


code: 


code: 


code: 


code: 





code: 





Route to end point address is via LDP FEC 
terface 67, label 100032 
Egress-—ok 

terface 67, label 100032 
Egress-—ok 

terface 67, label 100032 
Egress-—ok 

terface 67, label 100032 
Egress—ok 

terface 67, label 100032 





Egress—ok 





ts received, 0% packet loss 
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| ping mpls I2circuit 
Syntax 


ping mpls |2circuit (interface interface-name | virtual-circuit virtual-circuit-id neighbor address) 
<count count> 

<destination address> 

<detail> 

<exp forwarding-class> 

<logical-system (all | logical-system-name)> 

reply-mode (application-level-control-channel | ip-udp | no-reply) 

<size bytes> 

<source source-address> 

<sweep> 


<v1i> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 

The size and sweep options were introduced in Junos OS Release 9.6. 

The reply-mode option and its suboptions are introduced in Junos OS Release 10.4R1. 


Description 
Check the operability of the MPLS Layer 2 circuit connections. Type Ctrl+c to interrupt a ping mpls I2circuit 
command. 


NOTE: This command is not supported on EX4500 and EX4550 switches. 


Options 
count count—(Optional) Number of ping requests to send. If count is not specified, five ping requests are 
sent. The range of values is 1 through 1,000,000. The default value is 5. 


destination address—(Optional) Specify an address other than the default (127.0.0.1/32) for the ping echo 
requests. The address can be anything within the 127/8 subnet. 


detail—(Optional) Display detailed information about the echo requests sent and received. 
exp forwarding-class—(Optional) Value of the forwarding class for the MPLS ping packets. 


interface interface-name—Ping an interface configured for the Layer 2 circuit on the egress provider edge 
(PE) router. 
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logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on 
the specified logical system. 


reply-mode—(Optional) Reply mode for the ping request. This option has the following suboptions: 


application-level-control-channel—Reply using an application level control channel. 
ip-udp—Reply using an IPv4 or IPv6 UDP packet. 


no-reply—Do not reply to the ping request. 


NOTE: The reply-mode option and its suboptions application-level-control-channel, ip-udp, 
and no-reply are also available in Junos OS Release 10.2R4 and 10.3R2. 


size bytes—(Optional) Size of the label-switched path (LSP) ping request packet (96 through 65468 bytes). 
Packets are 4-byte aligned. For example, If you enter a size of 97, 98, 99, or 100, the router or switch 
uses a size value of 100 bytes. If you enter a packet size that is smaller than the minimum size, an error 
message is displayed reminding you of the 96-byte minimum. 


source source-address—(Optional) IP address of the outgoing interface. This address is sent in the IP source 
address field of the ping request. If this option is not specified, the default address is usually the 
loopback interface (lo.0). 


sweep—(Optional) Automatically determine the size of the maximum transmission unit (MTU). 
v1—(Optional) Use the type 9 Layer 2 circuit type, length, and value (TLV). 


virtual-circuit virtual-circuit-id neighbor address—Ping the virtual circuit identifier on the egress PE router 
or switch and the specified neighbor, testing the integrity of the Layer 2 circuit between the ingress 
and egress PE routers or switches. 


Additional Information 


You must configure MPLS at the [edit protocols mpls] hierarchy level on the egress PE router or switch 
(the router or switch receiving the MPLS echo packets) to ping a Layer 2 circuit. 


In asymmetric MTU scenarios, the echo response might be dropped. For example, if the MTU from System 
A to System B is 1000 bytes, the MTU from System B to System A is 500 bytes, and the ping request 
packet size is 1000 bytes, the echo response is dropped because the PAD TLV is included in the echo 
response, making it too large. 


Required Privilege Level 
network 


List of Sample Output 
ping mpls I2circuit interface on page 2293 
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ping mpls I2circuit virtual-circuit detail on page 2293 
ping mpls I2circuit interface <interface-name> reply-mode on page 2293 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. An exclamation 
point (!) indicates that an echo reply was received. A period (.) indicates that an echo reply was not received 
within the timeout period. An x indicates that an echo reply was received with an error code. Packets with 
an error code are not counted in the received packets count. They are accounted for separately. 


Sample Output 


ping mpls I2circuit interface 


user@host> ping mpls I2circuit interface so-1/0/0.1 


Request for seq 1, to interface 69, labels <100000, 100208>, packet size 100 





Reply for seq 1, return code: Egress-ok, time: 0.439 ms 


ping mpls I2circuit virtual-circuit detail 


user@host> ping mpls I2circuit virtual-circuit 200 neighbor 10.255.245.122/32 detail 


Request for seq 1, to interface 68, labels <100048, 100128>, packet size 100 








Reply for seq 1, return code: Egress-ok time: 0.539 ms 


ping mpls I2circuit interface <interface-name> reply-mode 


user@host> ping mpls I2circuit interface It-1/2/0.21 reply-mode application-level-control-channel 


=== Isjoiline) Sitaic sites; === 


5 packets transmitted, 5 packets received, 0% packet loss 
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| ping mpls I2vpn 
Syntax 


ping mpls I2vpn (instance instance-name local-site-id local-site-id-number remote-site-id remote-site-id-number | 
interface interface-name) 

<bottom-label-ttl> 

<count count> 

<destination address> 

<detail> 

<exp forwarding-class> 

<logical-system (all | logical-system-name)> 

reply-mode (application-level-control-channel | ip-udp | no-reply) 

<size bytes> 

<source source-address> 


<sweep> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

The size and sweep options were introduced in Junos OS Release 9.6. 

The reply-mode option and its suboptions are introduced in Junos OS Release 10.4R1. 


Description 
Check the operability of MPLS Layer 2 virtual private network (VPN) connections. Type Ctrl+c to interrupt 
a ping mpls I2vpn command. 


Options 
bottom-label-ttl—(Optional) Display the time-to-live value for the bottom label in the label stack. 


count count—(Optional) Number of ping requests to send. If count is not specified, five ping requests are 
sent. The range of values is 1 through 1,000,000. The default value is 5. 


destination address—(Optional) Specify an address other than the default (127.0.0.1/32) for the ping echo 
requests. The address can be anything within the 127/8 subnet. 


detail—(Optional) Display detailed information about the echo requests sent and received. 
exp forwarding-class—(Optional) Value of the forwarding class for the MPLS ping packets. 


instance instance-name local-site-id local-site-id-number remote-site-id remote-site-id-number—Ping a 
combination of the Layer 2 VPN routing instance name, the local site identifier, and the remote site 
identifier, testing the integrity of the Layer 2 VPN circuit (specified by the identifiers) between the 
ingress and egress provider edge (PE) routers or switches. 
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interface interface-name—Ping an interface configured for the Layer 2 VPN on the egress PE router or 
switch. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on 
the specified logical system. 


reply-mode—(Optional) Reply mode for the ping request. This option has the following suboptions: 


application-level-control-channel—Reply using an application level control channel. 
ip-udp—Reply using an IPv4 or IPv6 UDP packet. 
no-reply—Do not reply to the ping request. 


The reply-mode option and its suboptions application-level-control-channel, ip-udp, and no-reply 
are also available in Junos OS Release 10.2R4 and 10.3R2. 


size bytes—(Optional) Size of the label-switched path (LSP) ping request packet (96 through 65468 bytes). 
Packets are 4-byte aligned. For example, If you enter a size of 97, 98, 99, or 100, the router or switch 
uses a size value of 100 bytes. If you enter a packet size that is smaller than the minimum size, an error 
message is displayed reminding you of the 96-byte minimum. 


source source-address—(Optional) IP address of the outgoing interface. This address is sent in the IP source 
address field of the ping request. If this option is not specified, the default address is usually the 
loopback interface (lo.0). 


sweep—(Optional) Automatically determine the size of the maximum transmission unit (MTU). 


Additional Information 


You must configure MPLS at the [edit protocols mpls] hierarchy level on the egress PE router or switch 
(the router or switch receiving the MPLS echo packets) to ping a Layer 2 circuit. 


In asymmetric MTU scenarios, the echo response might be dropped. For example, if the MTU from System 
A to System B is 1000 bytes, the MTU from System B to System A is 500 bytes, and the ping request 
packet size is 1000 bytes, the echo response is dropped because the PAD TLV is included in the echo 
response, making it too large. 


Required Privilege Level 
network 


List of Sample Output 

ping mpls I2vpn instance on page 2296 

ping mpls I2vpn instance detail on page 2296 

ping mpls I2vpn interface <interface-name> reply-mode on page 2296 


Output Fields 
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When you enter this command, you are provided feedback on the status of your request. An exclamation 
point (!) indicates that an echo reply was received. A period (.) indicates that an echo reply was not received 
within the timeout period. An x indicates that an echo reply was received with an error code these packets 
are not counted in the received packets count. They are accounted for separately. 


Sample Output 


ping mpls I2vpn instance 


user@host> ping mpls I2vpn instance vpn1 remote-site-id 1 local-site-id 2 


=== Isjolng Sitairisties === 


5 packets transmitted, 5 packets received, 0% packet loss 


ping mpls I2vpn instance detail 


user@host> ping mpls I2vpn instance vpn1 remote-site-id 1 local-site-id 2 detail 


fe 


Request for seq 1, to interface 68, labels <800001, OOLT6> 


Reply for seq 1, return code: Egress-ok 


fps 


Request for seq 2, to interface 68, labels <800001, VOLT Ss 


Reply for seq 2, return code: Egress-—ok 


fs 


Request for seq 3, to interface 68, labels <800001, 00176> 


Reply for seq 3, return code: Egress—-ok 


fs 


Request for seq 4, to interface 68, labels <800001, 00176> 


Reply for seq 4, return code: Egress—-ok 























fs 


Request for seq 5, to interface 68, labels <800001, 00176> 

















Reply for seq 5, return code: Egress-—ok 


=== Igjoimg staistiles === 


5 packets transmitted, 5 packets received, 0% packet loss 


ping mpls I2vpn interface <interface-name> reply-mode 


user@host> ping mpls I2vpn interface It-1/2/0.21 reply-mode ip-udp 


=== Isjoiline] Sie LSiees; === 


5 packets transmitted, 5 packets received, 0% packet loss 
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| ping mpls I3vpn 
Syntax 


ping mpls I3vpn prefix prefix-name 
<I3vpn-name> 

<bottom-label-ttl> 

<count count> 

<destination address> 

<detail> 

<exp forwarding-class> 

<logical-system (all | logical-system-name)> 
<size bytes> 

<source source-address> 


<sweep> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

The size and sweep options were introduced in Junos OS Release 9.6. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for QFX Virtual Chassis and Virtual Chassis 
Fabric. 


Description 
Check the operability of a MPLS Layer 3 virtual private network (VPN) connection. Type Ctrl+c to interrupt 
a ping mpls ISvpn command. 


Options 
bottom-label-ttl—(Optional) Display the time-to-live value for the bottom label in the label stack. 


count count—(Optional) Number of ping requests to send. If count is not specified, five ping requests are 
sent. The range of values is 1 through 1,000,000. The default value is 5. 


destination address—(Optional) Specify an address other than the default (127.0.0.1/32) for the ping echo 
requests. The address can be anything within the 127/8 subnet. 


detail—(Optional) Display detailed information about the echo requests sent and received. 
exp forwarding-class—(Optional) Value of the forwarding class for the MPLS ping packets. 
I3vpn-name—(Optional) Layer 3 VPN name. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on 
the specified logical system. 


2298 


prefix prefix-name—Ping to test whether a prefix is present in a provider edge (PE) router’s or switch's 
VPN routing and forwarding (VRF) table, by means of a Layer 3 VPN destination prefix. This option 
does not test the connection between a PE router or switch and a customer edge (CE) router or switch. 


size bytes—(Optional) Size of the label-switched path (LSP) ping request packet (96 through 65468 bytes). 
Packets are 4-byte aligned. For example, If you enter a size of 97, 98, 99, or 100, the router or switch 
uses a size value of 100 bytes. If you enter a packet size that is smaller than the minimum size, an error 
message is displayed reminding you of the 96-byte minimum. 


source source-address—(Optional) IP address of the outgoing interface. This address is sent in the IP source 
address field of the ping request. If this option is not specified, the default address is usually the 
loopback interface (lo.0). 


sweep—(Optional) Automatically determine the size of the maximum transmission unit (MTU). 


Additional Information 


You must configure MPLS at the [edit protocols mpls] hierarchy level on the egress PE router or switch 
(the router or switch receiving the MPLS echo packets) to ping a Layer 2 circuit. 


In asymmetric MTU scenarios, the echo response might be dropped. For example, if the MTU from System 
A to System B is 1000 bytes, the MTU from System B to System A is 500 bytes, and the ping request 
packet size is 1000 bytes, the echo response is dropped because the PAD TLV is included in the echo 
response, making it too large. 


If the Layer 3 VPN traffic transits a route reflector within the network, the ping mpls ISvpn command does 
not work. 


Required Privilege Level 
network 


List of Sample Output 
ping mpls I3vpn on page 2298 
ping mpls I3vpn detail on page 2299 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. An exclamation 
point (!) indicates that an echo reply was received. A period (.) indicates that an echo reply was not received 
within the timeout period. An x indicates that an echo reply was received with an error code these packets 
are not counted in the received packets count. They are accounted for separately. 


Sample Output 


ping mpls I3vpn 
user@host> ping mpls I3vpn vpn1 prefix 10.255.245.122/32 


=== Isjoiling) SEBEL Sees: === 


5 packets transmitted, 


ping mpls I3vpn detail 


5 packets received, 


0% packet loss 


user@host> ping mpls I3vpn vpn1 prefix 10.255.245.122/32 detail 


Rep] 


Rep] 


Rep] 


Rep] 





LY 


Request for seq 1, 


for seq 1, re 


Request for seq 2, 


ly for seq 2, re 


LY 


LY 





Rep] 


=== Ilsjoiline) SieeieLSites; === 


Ly 


Request for seq 3, 


for seq 3, re 


Request for seq 4, 


for seq 4, re 





Request for seq 5, 





for seq 5, re 


EO) aljal 
turn 
EO) alia 
turn 
CO aljal 
turn 
CO Alia 
turn 


to in 





turn 


5 packets transmitted, 5 


terface 68, 


terface 68, 


terface 68, 


terface 68, 





terface 68, 





labels 


code: Egress-—ok 


labels 


code: Egress-—ok 


labels 


code: Egress-—ok 


labels 


code: Egress-—ok 


labels 


code: Egress-ok 





packets received, 


<UOOLAS, WO Las 


<100128, 100112> 


<INO LAs, AOL las 


<100128, 100112> 


<100128, 100112> 


0% packet loss 
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| request mpls container-lIsp 


Syntax 


request mpls container-Isp 
<logical-system (all | logical-system-name)> 
<name Isp-name> 
<adjust-autobandwidth> 


<normalization> 


Release Information 
Command introduced in Junos OS Release 14.2. 
Statement introduced for QFX Switches in Junos OS Release 15.1X53-D30. 


Description 


Manually trigger a bandwidth allocation adjustment for the container label-switched path (LSP). 


Options 


none—Manually trigger a bandwidth allocation adjustment for all active member LSP paths. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


name Isp-name—(Optional) Manually trigger a bandwidth allocation adjustment on the specified member 
LSP only. 


adjust-autobandwidth—(Optional) Request LSP autobandwidth adjustment. 


normalization—(Optional) Request container LSP normalization. 


Required Privilege Level 
clear, maintenance 


RELATED DOCUMENTATION 


show mpls container-Isp | 2339 


clear mpls container-Isp | 2265 


List of Sample Output 
request mpls container-Isp on page 2301 
request mpls container-Isp on page 2301 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 
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Sample Output 
request mpls container-Isp 


user@host> request mpls container-Isp Isp-name normalize 


request mpls container-Isp 


user@host> request mpls container-Isp normalize bandwidth bps 


| request mpls Isp adjust-autobandwidth 


List of Syntax 
Syntax on page 2302 
Syntax (EX and QFX Series Switches) on page 2302 


Syntax 


request mpls Isp adjust-autobandwidth 
<logical-system (all | logical-system-name)> 
<name Isp-name> 


Syntax (EX and QFX Series Switches) 


request mpls Isp adjust-autobandwidth 
<name Isp-name> 


Release Information 

Statement introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 9.5 for EX Series switches. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 
Statement introduced in Junos OS Release 17.2R1 for QFX10000 Series switches. 


Description 


Manually trigger a bandwidth allocation adjustment for active label-switched paths (LSPs). 


Without running this command, the bandwidth adjustment is recomputed at a configurable interval. The 
default interval is 5 minutes. If you do not want to wait for the periodic adjustment (for example, during 
a software demonstration), this command is useful. 


During bandwidth allocation adjustment, the LSP stays up to enable the bandwidth to be changed without 
dropping any traffic. This functionality is often referred to as make-before-break. 


Options 


none—Manually trigger a bandwidth allocation adjustment for all active LSP paths. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


name Isp-name—(Optional) Manually trigger a bandwidth allocation adjustment on the specified LSP only. 


Additional Information 


For this command to work properly, the following conditions must exist: 
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e Automatic bandwidth allocation must be enabled on the LSP. The parameters for adjustment interval 
and maximum average bandwidth are not reset after you issue the request mpls Isp adjust-autobandwidth 
command. 


e The difference between the adjusted bandwidth and the current LSP path bandwidth must be greater 
than the threshold limit. 


Required Privilege Level 
clear, maintenance 


RELATED DOCUMENTATION 


auto-bandwidth | 1721 
Configuring Automatic Bandwidth Allocation for LSPs | 517 


List of Sample Output 
request mpls Isp adjust-auto-bandwidth on page 2303 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 


Sample Output 


request mpls Isp adjust-auto-bandwidth 


user@host> request mpls Isp adjust-auto-bandwidth 
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| show connections 


List of Syntax 
Syntax on page 2304 
Syntax (EX Series Switches) on page 2304 


Syntax 


show connections 

<brief | extensive> 

<all | interface-switch | Isp-switch | p2mp-receive-switch | p2mp-transmit-switch | remote-interface-switch> 
<down | up | up-down> 

<history> 

<labels> 

<logical-system (all | logical-system-name)> 

<name> 


<status> 


Syntax (EX Series Switches) 


show connections 

<brief | extensive> 

<all | interface-switch | Isp-switch | p2mp-receive-switch | p2mp-transmit-switch | remote-interface-switch> 
<down | up | up-down> 

<history> 

<labels> 

<name> 


<status> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Command introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Display information about the configured circuit cross-connect (CCC) connections. 


Options 


none—Display the standard level of output for all configured CCC connections. 
all—(Optional) Display all connections. 


brief | extensive—(Optional) Display the specified level of output. Use history to display information about 
connection history. Use labels to display labels used for transmit and receive LSPs. Use status to display 
information about the connection and interface status. 
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interface-switch—(Optional) Display interface switch connections only. 
Isp-switch—(Optional) Display LSP switch connections only. 


p2mp-receive-switch—(Optional) Display point-to-multipoint LSP to local interfaces switch connections 
only. 


p2mp-transmit-switch—(Optional) Display local interface to point-to-multipoint LSP switch connections 
only. 


remote-interface-switch—(Optional) Display remote interface switch connections only. 

down | up | up-down—(Optional) Display nonoperational, operational, or both kinds of connections. 
history—(Optional) Display information about connection history. 

labels—(Optional) Display labels used for transmit and receive. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on a 
particular logical system. 


name—(Optional) Display information about the specified connection only. 


status—(Optional) Display information about the connection and interface status. 


Required Privilege Level 
view 


Output Fields 


Table 39 on page 2305 describes the output fields for the show connections command. Output fields are 
listed in the approximate order in which they appear. 


Table 39: show connections Output Fields 


Field Name Field Description 


CCC and TCC Whether link monitoring is enabled: On or Off. 
connections [Link 

Monitoring On | 

Off] 


Legend for Status Connection or circuit status. See the output's legend for an explanation 
(St) of the status field values. 


Table 39: show connections Output Fields (continued) 


Field Name 


Legend for 
connection types 


Legend for circuit 
types 


Connection/Circuit 


Type 


St 


Time last up 


# Up trans 


Field Description 


Type of connection: 


e if-sw—Layer 2 switching cross-connect. 


e rmt-if—Remote interface switch. While graceful restart is in progress, 
rmt-if will display a state (St) of Restart. 


e Isp-sw—LSP stitching cross-connect. While graceful restart is in progress, 
Isp-sw will display a state (St) of Restart. 


Type of circuits: 


e intf—Interface circuit. 
e tlsp—Transmit LSP circuit. 


e rlsp—Receive LSP circuit. 


Name of the configured CCC connection. 


Type of connection. 


State of the connection. 


Time that the connection or circuit last transitioned to the Up (operational) 


state. 


Number of times that the connection or circuit has transitioned to the Up 


(operational) state. 


| Sample Output 


show connections 


user@switch> show connections 


CCC and TCC connections [Link Monitoring On] 








—- Only Joule bound conn si up 


Legend for status (St) 


DS —- disabled 


Dn —- down 


Legend for connection types 





UN -- uninitialized if-sw: interface switching 
NP -- not present rmt-if: remote interface switching 
WE -- wrong encapsulation lsp-sw: LSP switching 





Legend for circuit types 


jer ——= ALigheeuere Elie 
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| show dynamic-tunnels database 


Syntax 


show dynamic-tunnels database 
<destination> 

<logical-system (all | logical-system-name) > 
<table routing-table-name> 


Release Information 
Command introduced before Junos OS Release 7.4. 


Description 


Display dynamic tunnel database information. 


Options 


none—Display dynamic tunnel database information for all destinations and routing tables. 


destination—(Optional) Display database entries for the specified IP address (with optional destination 
prefix length) only. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


table routing-table-name—(Optional) Display database entries for the specified table only. 


Required Privilege Level 
view 


List of Sample Output 

show dynamic-tunnels database (Tunnel Is Up) on page 2310 

show dynamic-tunnels database (No Tunnel PIC) on page 2310 

show dynamic-tunnels database (Tunnel Is Expiring) on page 2310 

show dynamic-tunnels database (Destination Specified) on page 2311 

show dynamic-tunnels database (Localization) on page 2311 

show dynamic-tunnels database (MPLS-over-UDP Dynamic Tunnels on PTX Series Routers and QFX 
Series Switches) on page 2311 

show dynamic-tunnels database (Segment Routing LSPs) on page 2312 


Output Fields 


Table 40 on page 2309 lists the output fields for the show dynamic-tunnels database command. Output 
fields are listed in the approximate order in which they appear. 
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Table 40: show dynamic-tunnels database Output Fields 


Field Name 


Table 


Destination-network 


Tunnel to 


State 


Reference count 


Next-hop type 


Source address 


Next-hop 


VPN Label 


Ingress Route 


Localized PFE 


LSP template name 


State 


Status 


Field Description 


Name of the routing table (for example, inet.0). 


Destination IP address and subnet. 


Destination IP address and prefix of the tunnel. 


State of the tunnel: Up, Up (expires in nn:nn:nnseconds), or Dn 
(down). 


Number of routes across the dynamic tunnel that are currently 
being resolved. 


Type of tunnel: GRE or UDP (BGP-Signal). 


e GRE or UDP (BGP signal) 
e SRTE—Segment routing traffic-engineered LSP. 


Source IP address of the tunnel. 


IP address of the destination interface. 


The label provided by the peer device to identify the VPN through 
which the packet needs to go. This label is used to identify the VRF 
for route lookup. 


The IGP route along with the corresponding metric that has been 
selected for forwarding the tunnel-encapsulated packet. 


Packet Forwarding Engine interface which is the anchor Packet 
Forwarding Engine for the localized next-hop-based dynamic 
tunnels. 


When the anchor Packet Forwarding Engine of the tunnel goes 
down, it is represented by a # near the Packet Forwarding Engine 


name. 


Name of the segment routing traffic-engineered template 
configured for dynamic creation of segment routing LSPs. 


State of the destination interface: Up, Dn, or Dn (no tunnel pic). 


Status of the dynamic segment routing LSP. 


| Sample Output 


show dynamic-tunnels database (Tunnel Is Up) 


user@host> show dynamic-tunnels database 


Table: inet.3 


Destination-network: 10.255.120.94/32 
Toimael tos 10,255,120 .94/32 
Reference count: 4 
Next-hop type: UDP 
Source ackhleesss 10.255.120.92 
Next hop: tunnel-composite, 0x31132f64, nhid 3406 
VPN Label: Push 120 Reference count: 3 
Inleiceass inowieSy 0) ,255), 120, 94/ 92, wale imsiciese 2 
Ueeurrile Sitaeisciess Packers Z24H1S67/95i1, wyres S567/4ilssila7s 
State: Up 


show dynamic-tunnels database (No Tunnel PIC) 


user@host> show dynamic-tunnels database 


Table: inet.3 


Destination-network: 10.255.120.94/32 
sMCb evel Min oo) msl NO IMWo ol DAO PC L- © ACh ot Wet Dba} 
Reference count: 2 
Next-hop type: gre 
Soucee achleesss 10.255. 120.92 


State: Dn (no tunnel pic) 


show dynamic-tunnels database (Tunnel Is Expiring) 


user@host> show dynamic-tunnels database 


Table: inet.3 


Destination-network: 10.255.120.94/32 


Tunnel tos 1022555120 94/32 States Up) (expires an) 00214756 ‘sSecends) 


Reference count: 0 
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Next-hop type: gre 
Sources achleesss 10.255.120.92 
Next hop: gr-4/3/0.32769 
State: Up 


show dynamic-tunnels database (Destination Specified) 


user@host> show dynamic-tunnels database 10.255.120.94 


Table: inet.3 


Destination-network: 10.255.120.94/32 
Tunnel Go: LO 255120947 325 Sittate:= Ul 
Reference count: 2 
Next-hop type: gre 
Soumee ecbleesse 10.255. 120.92 
Next hop or 4/73) 0RS2 7169 
State: Up 


show dynamic-tunnels database (Localization) 


user@host> show dynamic-tunnels database 


Destination-network: 1.0.0.0/8 
Meonel eos t,l_l,6/S2 
Reference count: 5 
Next-hop type: UDP 
Soumes ecleleesss oil ,il.% 
Next hop: tunnel-composite, 0xc807930, nhid 1016 
Localized PFE: pfe-1/0/0 
VPN Label: Push 299808 Reference count: 4 





Imoicess Rowices lol, .6/S2, wie merric 2 
Traffic Statistics: Packets 0, Bytes 0 
State: Up 


show dynamic-tunnels database (MPLS-over-UDP Dynamic Tunnels on PTX Series Routers and QFX 


Series Switches) 


user@host> show dynamic-tunnels database 





*— Signal Tunnels #- PFE-down 


Table: inet.3 
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Destination-network: 22.33.0.0/16 


Destination-network: 22.33.44.0/24 


show dynamic-tunnels database (Segment Routing LSPs) 


user@host> show dynamic-tunnels database 


Table: inetcolor.0 


Destination-network: 22.33.44.0:0/24 

Tunnel to: 22.33.44.55:124/64 
Reference count: 2 
Next—-hop type: SRIE 
LSP template name: 22.33.44.55:7c:dt-srte-tunnell 
Status: Initiated/Established 
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| show link-management 


Syntax 


show link-management 


Release Information 
Command introduced before Junos OS Release 7.4. 
Command introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Display Multiprotocol Label Switching (MPLS) peer and traffic engineering link information. 


Options 


This command has no options. 


Required Privilege Level 


view 


RELATED DOCUMENTATION 


show link-management peer | 2317 
show link-management routing | 2320 
show link-management statistics | 2324 


show link-management te-link | 2327 





List of Sample Output 
show link-management on page 2315 


Output Fields 
Table 41 on page 2313 describes the output fields for the show link-management command. Output fields 
are listed in the approximate order in which they appear. 


Table 41: show link-management Output Fields 


Field Name Field Description 
Peer Name Name of the peer. 
System identifier Internal identifier for the peer. The range of values is 0 through 64,000. 


State State of the peer: Up or Down. 
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Table 41: show link-management Output Fields (continued) 


Field Name 


Control address 


CC local ID 


CC remote ID 


State 


TxSeqNum 


RcvSeqNum 


Flags 


TE links 


TE link name 


State 


Local identifier 


Remote identifier 


Local address 


Remote address 


Encoding 


Switching 


Field Description 


Address to which a control channel is established. 


Identifier assigned to the control channel by the local peer. The range of values is 1 
through 4,294,967,296. 


Identifier assigned to the control channel by the remote peer. The range of values is 
1 through 4,294,967,296. 


State of the control channel: Up or Down. 


Sequence number of the hello message being sent to the peer. The range of values is 
1 through 4,294,967,295. 


Sequence number of the last hello message received from the peer. The range of values 
is O through 4,294,967,295. 


Code that provides information about the control channel. Currently supports only 
code value R, which indicates that the control channel is restarting after a failure in 
the control plane, as when the Link Management Protocol (LMP) process starts or 
restarts. 

Traffic-engineered links that are managed by their peer. 

Name of the traffic-engineered link. 

State of the traffic-engineered link: Up, Down, or Init. 

Identifier of the local side of the link. 

Identifier of the remote side of the link. 

Address of the local side of the link. 

Address of the remote side of the link. 

Physical layer media type determined by the interfaces contained in the 
traffic-engineered link. Typical values include SDH/SONET, Ethernet, Packet, and 


PDH. 


Type of switching that can be performed on the traffic-engineered link. Supported 
values are PSC-1 and Packet. 
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Table 41: show link-management Output Fields (continued) 


Field Name 


Minimum bandwidth 


Maximum bandwidth 


Total bandwidth 


Available bandwidth 


Name 


State 


Local ID 


Remote ID 


Bandwidth 


Used 


LSP-name 


Field Description 
Smallest single allocation of bandwidth possible on the traffic-engineered link. This 
number is equal to the smallest bandwidth interface that is a member of the 


traffic-engineered link (in bps). 


Largest single allocation of bandwidth possible on the traffic-engineered link. This 
number is equal to the largest bandwidth interface that is a member of the link (in bps). 


Sum of the bandwidth, in bits per second (bps) and megabits per second (Mbps), of all 
interfaces that are members of the link. 


Sum of the bandwidths of all interfaces that are members of the link and that are not 
yet allocated (in bps). 


Name of the interface. 


State of the interface: Up or Down. 


Identifier of the local side of the interface. 


Identifier of the remote side of the interface. 


Bandwidth, in bps or Mbps, of the member interface. 


Whether the resource is allocated to an LSP: Yes or No. 


LSP name. 


| Sample Output 


show link-management 


user@host> show link-management 


2 

















r name: PEER-A, System identifier: 11973 
Seabees Up, Controlvadduesis 0m 255e245..4 
CC local ID CC remote ID State TxSeqNum 
24547 24547 Up 1027 
TE links: 





pro4-ba 


RevSegqNum Flags 
1026 
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E link name: pro4-ba, State: Init 
2662, Remote identifier: 0, Encoding: SDH/SONET, Switching: 














Local identifier: 
PSC—1 , 

Minimum bandwidth: 
155). S2Moysiss, 
Available bandwidth: 155.52Mbps 

Name State Local ID Remote ID Bandwidth Used LSP-name 
so-1/0/2 Up 2DAQW AL 0 155.52Mbps No 


155.52Mbps, Maximum bandwidth: 155.52Mbps, Total bandwidth: 
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| show link-management peer 


Syntax 


show link-management peer 
<name peer-name> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Command introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Display Multiprotocol Label Switching (MPLS) peer link information. 


Options 


none—Display all peer link information. 


name peer-name—(Optional) Display information for the specified peer only. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


show link-management | 2313 
show link-management routing | 2320 


show link-management statistics | 2324 





show link-management te-link | 2327 


List of Sample Output 
show link-management peer on page 2318 


Output Fields 


Table 42 on page 2317 describes the output fields for the show link-management peer command. Output 
fields are listed in the approximate order in which they appear. 


Table 42: show link-management peer Output Fields 


Field Name Field Description 
Peer Name Name of the peer. 


System identifier Internal identifier for the peer. The range of values is O through 64,000. 


Table 42: show link-management peer Output Fields (continued) 


Field Name 


State 


Control address 


Hello interval 


Hello dead interval 


CC local ID 


CC remote ID 


State 


TxSeqNum 


RcvSeqNum 


Flags 


TE links 


| Sample Output 


Field Description 

State of the peer: Up or Down. 

Address to which a control channel is established. 

How often the routing device sends Link Management Protocol (LMP) hello packets. 

How long LMP waits before declaring the control channel to be dead. This is an interval during 
which the routing device receives no LMP hello packets from the neighbor on a control that 


is active or up. 


Identifier assigned to the control channel by the local peer. The range of values is 1 through 
4,294,967,296. 


Identifier assigned to the control channel by the remote peer. The range of values is 1 through 
4,294,967,296. 


State of the control channel: Up or Down. 


Sequence number of the hello message being sent to the peer. The range of values is 1 through 
4,294,967,295. 


Sequence number of the last hello message received from the peer. The range of values is O 
through 4,294,967,295. 


Code that provides information about the control channel. Currently supports only code value 
R, which indicates that the control channel is restarting after a failure in the control plane, as 


when the Link Management Protocol (LMP) process starts or restarts. 


Traffic-engineered links that are managed by their peer. 


show link-management peer 


user@host> show link-management peer 





Peer name: 


State: Up, 


Hello interval: 


sonet, 


Control address: 


System identifier: 41448 
TO. 10.70. 10 
Hello dead interval: 


10000, 30000 
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| show link-management routing 


Syntax 


show link-management routing 
<peer <name name> | te-link <name name>> 


<resource <name name>> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Command introduced in Junos OS Release 9.5 for EX Series switches. 


Description 
Display Multiprotocol Label Switching (MPLS) peer or traffic engineering link information from the routing 
process. 


Options 


none—Display all peer and traffic-engineered link information. 
peer <name name>—(Optional) Display information for all peers or for the specified peer only. 
resource <name name>—(Optional) Display information for all resources or for the specified resource only. 


te-link <name name>—(Optional) Display information for all traffic-engineered forwarding paths or for the 
specified path only. 


Required Privilege Level 


view 


RELATED DOCUMENTATION 


show link-management | 2313 
show link-management peer | 2317 
show link-management statistics | 2324 


show link-management te-link | 2327 





List of Sample Output 
show link-management routing on page 2322 


Output Fields 


Table 43 on page 2321 describes the output fields for the show link-management routing command. Output 
fields are listed in the approximate order in which they appear. 


Table 43: show link-management routing Output Fields 


Field Name 


Peer Name 


System identifier 


State 


Control address 


Control channel 


State 


TE link name 


State 


Local identifier 


Remote identifier 


Local address 


Remote address 


Encoding 


Minimum bandwidth 


Maximum bandwidth 


Total bandwidth 


Available bandwidth 


Resource 


Field Description 


Name of the peer. 


Internal identifier for the peer. The range of values is O through 64,000. 


State of the peer: Up or Down. 


Address to which a control channel is established. 


Interface over which control packets are sent. 


State of the control channel. 


Traffic-engineered link name. 


State of the traffic-engineered link: Up or Down. 


Identifier of the local side of the link. 


Identifier of the remote side of the link. 


Address of the local side of the link. 


Address of the remote side of the link. 


Physical layer media type determined by the interfaces contained in the traffic-engineered 
link. Typical values include SDH/SONET, Ethernet, and Packet. 


Smallest single allocation of bandwidth, in bits per second (bps) or megabits per second (Mbps), 
possible on the traffic-engineered link. This number is equal to the smallest bandwidth interface 


that is a member of the traffic-engineered link. 


Largest single allocation of bandwidth, in bps or Mbps, possible on the traffic-engineered link. 
This number is equal to the largest bandwidth interface that is a member of the link (in bps). 


Sum of the bandwidth, in bps or Mbps, of all interfaces that are members of the link. 


Sum of the bandwidth, in bps or Mbps, of all interfaces that are members of the link and that 
are not yet allocated. 


Forwarding adjacency LSP information. 
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Table 43: show link-management routing Output Fields (continued) 


Field Name Field Description 

Type Type of resource. The type is always a forwarding adjacency LSP. 

State State of the LSP: Up or Down. 

System Identifier Internal identifier for the peer. The range of values is O through 64,000. 

Total bandwidth Bandwidth resource, in bps or Mbps, on the TE-link learned from the routing process. 
Traffic parameters e Encoding—Physical layer media type determined by the interfaces contained in the 


traffic-engineered link. Typical values include SDH/SONET, Ethernet, and Packet. 


e Switching—Type of switching that can be performed on the traffic-engineered link: PSC-1 
and Packet. 


e Granularity—Layer 2 data for switching Layer 2 LSPs for this resource. Not supported. This 


value is always unknown. 


| Sample Output 


show link-management routing 


user@host> show link-management routing 


Peer name: __rpd:fe-0/1/0.0, System identifier: 2147483649 
State: Up, Control address: (null) 
Control-channel Sic aes 
fe-0/1/0.0 Active 
Peer name: __rpd:fe-0/1/2.0, System identifier: 2147483650 
State: Up, Control address: (null) 
Control-channel State 
fe-0/1/2.0 Active 
Peer name: __rpd:so-0/2/0.0, System identifier: 2147483651 
State: Down, Control address: (null) 
Control-channel State 
SO= 077/00) 
Peer name: __rpd:so-0/2/1.0, System identifier: 2147483652 
State: Down, Control address: (null) 


Control-channel State 
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SO= 0/2 a0 


TE link name: __rpd:fe-0/1/0.0, State: Up 
Local identifier: 2147483649, Remote identifier: 0, 





Local address: 192.168.37.66, Remote address: 192.168.37.66, 








Encoding: Ethernet, Minimum bandwidth: Obps, Maximum bandwidth: 100Mbps, 
Total bandwidth: 100Mbps, Available bandwidth: 100Mbps 





TE link name: __rpd:fe-0/1/2.0, State: Up 





Local identifier: 2147483650, Remote identifier: 0, 
oeell excleleacs; Se los. 37, 7S, REemence evclelsesiss 192,168.37 5.75, 








Encoding: Ethernet, Minimum bandwidth: Obps, Maximum bandwidth: 100Mbps, 
Total bandwidth: 100Mbps, Available bandwidth: 100Mbps 





LH link names merpdsso—0)/ 2/020), States Down 





Hocalpadentatver. 24 7438365 Remote wWdenittist rer 0), 
ioxeeul exclolnacsy, I7 Sc. S782, REuiveme excllaassye i192, ib6S 37.95, 








Encoding: Ethernet, Minimum bandwidth: Obps, Maximum bandwidth: 155.52Mbps, 
Total bandwidth: 155.52Mbps, Available bandwidth: 155.52Mbps 





Resource: falsp-bd, Type: LSP, State: Dn System identifier: 2147483652, 


Total bandwidth: Obps, Traffic parameters: Encoding: Packet, Switching: Packet, 
Granularity: Unknown 





Resource: falsp-be, Type: LSP, State: Up System identifier: 2147483654, 
Total bandwidth: bw[1]=10Mbps, Traffic parameters: Encoding: Packet, 





Switching: Packet, Granularity: Unknown 
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| show link-management statistics 


Syntax 


show link-management statistics 


<peer <name name>> 


Release Information 
Command introduced in Junos OS Release 8.0. 
Command introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Display statistical information for Link Management Protocol (LMP) packets. 


Options 


none—Display information for all peers. 


peer <name name>—(Optional) Display information for all peers or for the specified peer only. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


show link-management | 2313 
show link-management peer | 2317 


show link-management routing | 2320 





show link-management te-link | 2327 


List of Sample Output 
show link-management statistics on page 2325 


Output Fields 


Table 44 on page 2324 describes the output fields for the show link-management statistics command. Output 
fields are listed in the approximate order in which they appear. 


Table 44: show link-management statistics Output Fields 


Field Name Field Description 


Received packets Number of received packets by message type. If the count for a message type is zero, that 
message type is not displayed. If the count for all message types is zero, this field is not 
displayed. 
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Table 44: show link-management statistics Output Fields (continued) 


Field Name 


Received bad 


packets 


Small packets 


Wrong protocol 
version 


Messages for 
unknown peer 


Messages for bad 
state 


Stale 
acknowledgments 


Stale negative 
acknowledgments 


Sent packets 


Retransmitted 
packets 


Dropped packets 


| Sample Output 


Field Description 

Number of received bad packets by message type. If the count for a message type is zero, 
that message type is not displayed. If the count for all message types is zero, this field is not 
displayed. 


Number of packets that are too small. 


Number of packets specifying the wrong LMP version. 


Number of packets destined for an unknown peer. 


Number of packets indicating a state that does not match the recipient. 


Number of configAck and LinkSummaryAck packets received that have a stale message ID. 


Number of configNack and LinkSummaryNack packets received that have a stale message 


ID. 


Number of sent packets by message type. If the count for a message type is zero, that message 
type is not displayed. If the count for all message types is zero, this field is not displayed. 


Number of retransmitted packets by message type. If the count for a message type is zero, 
that message type is not displayed. If the count for all message types is zero, this field is not 
displayed. 


Number of packets sent, by message type, that have been dropped by the receiver after the 
LMP retransmission interval has been exceeded. If the count for a message type is zero, that 
message type is not displayed. If the count for all message types is zero, this field is not 
displayed. 


show link-management statistics 


user@host> show link-management statistics peer pro4-a 
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| show link-management te-link 


Syntax 


show link-management te-link 
<brief | detail> 


<name name> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Command introduced in Junos OS Release 9.5 for EX Series switches. 


Description 
Display the resources used to set up Multiprotocol Label Switching (MPLS) traffic-engineered forwarding 
paths. 


Options 


none—Display information for all traffic-engineered links. 
brief | detail—(Optional) Display the specified level of output. 


name name—(Optional) Display information for the specified traffic-engineered link only. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


show link-management | 2313 
show link-management peer | 2317 


show link-management routing | 2320 





show link-management statistics | 2324 


List of Sample Output 
show link-management te-link on page 2329 


Output Fields 
Table 45 on page 2328 describes the output fields for the show link-management te-link command. Output 
fields are listed in the approximate order in which they appear. 


Table 45: show link-management te-link Output Fields 


Field Name 


TE link name 


State 


Local identifier 


Remote identifier 


Local address 


Remote address 


Encoding 


Switching 


Minimum bandwidth 


Maximum bandwidth 


Total bandwidth 


Available Bandwidth 


Name 


State 


Local ID 


Remote ID 


Bandwidth 


Used 


Field Description 


Traffic-engineered link name. 


State of the traffic-engineered link: Up or Down. 


Identifier of the local side of the link. 


Identifier of the remote side of the link. 


Address of the local side of the link. 


Address of the remote side of the link. 


Physical layer media type determined by the interfaces contained in the traffic-engineered 
link. Typical values include SDH/SONET, Ethernet, Packet, and PDH. 


Type of switching that can be performed on the traffic-engineered link. Supported values are 
PSC-1 and Packet. 


Smallest single allocation of bandwidth, in bits per second (bps) or megabits per second (Mbps), 
possible on the traffic-engineered link. This number is equal to the smallest bandwidth interface 


that is a member of the traffic-engineered link. 


Largest single allocation of bandwidth, in bps or Mbps, possible on the traffic-engineered link. 
This number is equal to the largest bandwidth interface that is a member of the link. 


Sum of the bandwidth, in bps or Mbps, of all interfaces that are members of the link (in bps). 


Sum of the bandwidth, in bps or Mbps, of all interfaces that are members of the link and that 
are not yet allocated. 


Name of the interface. 


State of the interface: Up or Down. 


Identifier of the local side of the interface. 


Identifier of the remote side of the interface. 


Bandwidth, in bps or Mbps, of the member interface. 


Whether the resource is allocated to an LSP: Yes or No. 
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Table 45: show link-management te-link Output Fields (continued) 


Field Name Field Description 


LSP-name LSP name. 


| Sample Output 


show link-management te-link 


user@host> show link-management te-link 





TE link name: FA-bd, State: Up 





Localeaidentistveir.) 414A Remote identsrucr i) hocaleaddresisis 2) .2mds 





Remote address: 2.2.2.2, Encoding: Ethernet, Switching: Packet, 





Minimum bandwidth: Obps, Maximum bandwidth: Obps, Total bandwidth: Obps, 
Available bandwidth: Obps 
Name State Local ID Remote ID Bandwidth Used LSP-name 
ireLlcjo—iorcl Dn 43077 0 Obps No 





TE link name: FA-be, State: Up 








Local identifier: 4145, Remote identifier: 0, Local address: 1.1.1.1, 








Remote address: 1.1.1.2, Encoding: Ethernet, Switching: Packet, 
Minimum bandwidth: Obps, Maximum bandwidth: 10Mbps, Total bandwidth: 10Mbps, 
Available bandwidth: 8Mbps 
Name State Local ID Remote ID Bandwidth Used LSP-name 
falsp-be Up 43076 0 10Mbps Yes e2Zelsp-bf 


| show mpls abstract-hop-membership 


Syntax 


show mpls abstract-hop-membership 
<abstract-hop-name> 
<instance instance-name> 


<logical-system (all | logical-system-name)> 


Release Information 
Command introduced in Junos OS Release 17.1 for all platforms. 


Description 


Display MPLS abstract hop membership tables for each abstract hop configured on the device. 


Options 
none—(Optional) Display the MPLS abstract hop membership table for all the configured abstract hops on 


the router. 


abstract-hop-name—(Optional) Display the MPLS abstract hop membership table for the specified abstract 
hop. 


instance instance-name—(Optional) Display the MPLS abstract hop membership table for the specified 
instance. If instance-name is omitted, information is displayed for the master instance. 


logical-system (all | logical-system-name)—(Optional) Display the MPLS abstract hop membership table for 
all logical systems or on a particular logical system. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


Example: Configuring Abstract Hops for MPLS LSPs | 442 
abstract-hop | 1696 
constituent-list | 1742 


show mpls Isp abstract-computation | 2400 





List of Sample Output 
show mpls abstract-hop-membership on page 2331 


Output Fields 
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Table 46 on page 2331 describes the output fields for the show mpls abstract-hop-membership command. 


Output fields are listed in the approximate order in which they appear. 


Table 46: show mpls abstract-hop-membership Output Fields 


Field Name 


Abstract hop 


Credibility 


Address 


| Sample Output 


show mpls abstract-hop-membership 


Field Description 


Name of the abstract hop. 


Credibility value associated with the interior gateway protocol in use. 


IP address of the abstract hop member nodes. 


user@host> show mpls abstract-hop-membership 


Abstract hop: ah1 


Credibility: 
Address: 127.0.0.6 
Nelcheasiss 127 50551 
Nelhessss 127 50.0.2 
Address: 127.0.0.3 
Abstract hop: ah2 

Credibility: 
7X Ko bral 4-1) WAN ae Oa OS) 
Address: 127.0.0.3 
Nelcheasse 127 50.0.4 
Abstract hop: ah3 

Credibility: 
Address: 127.0.0.6 
Address: 127.0.0.3 
Aclelkeesey 127 .0.60.5 
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| show mpls admin-groups 


List of Syntax 
Syntax on page 2332 
Syntax (EX Series Switches) on page 2332 


Syntax 


show mpls admin-groups 
<instance instance-name> 
<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


show mpls admin-groups 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
instance instance-name option added in Junos OS Release 15.1. 


Description 


Display information about configured Multiprotocol Label Switching (MPLS) administrative groups. 


Options 


none—Display information about the configured MPLS administrative groups. 


instance instance-name—(Optional) Display MPLS administrative group information for the specified 
instance. If instance-name is omitted, MPLS administrative group information for the master instance 
is displayed. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 


particular logical system. 


Required Privilege Level 
view 


List of Sample Output 
show mpls admin-groups on page 2333 


Output Fields 


Table 47 on page 2333 describes the output fields for the show mpls admin-groups command. Output fields 
are listed in the approximate order in which they appear. 
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Table 47: show mpls admin-groups Output Fields 


Field Name Field Description 
Group Name of the administrative group. 
Bit index Value assigned to the administrative group. 


| Sample Output 


show mpls admin-groups 


user@host> show mpls admin-groups 


Group Bit index 
black 3 
blue 2, 
gold i 
green 0 
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| show mpls association 


Syntax 


show mpls association (iif incoming-interface | oif outgoing-interface) 
<logical-system (all | logical-system-name)> 


Release Information 
Command introduced in Junos OS Release 16.1 for the M Series, MX Series, and T Series. 


Description 

Display the Multiprotocol Label Switching (MPLS) label-switched paths (LSPs) based on the association 
with an incoming or outgoing LSP interface. The command output displays the list of RSVP-TE LSPs carrying 
traffic in and out of the same interface. 


Options 

iif incoming-interface-name—Display list of RSVP-TE LSPs that share the specified incoming interface to 
bring in traffic. This option works on transit label-switching routers (LSRs) and egress label edge routers 
(LERs). 


oif outgoing-interface-name—Display list of RSVP-TE LSPs that share the specified outgoing interface to 
carry out traffic. This option works on ingress LERs and transit LSRs. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


show mpls correlation nexthop-id | 2352 


List of Sample Output 
show mpls association iif on page 2335 
show mpls association oif on page 2335 


Output Fields 
Table 48 on page 2335 describes the output fields for the show mpls association command. Output fields 
are listed in the approximate order in which they appear. 


Table 48: show mpls association Output Fields 


Field Name 


To 


From 


State 


LSPname 


| Sample Output 


Field Description 


Destination IP address of the corresponding LSP. 


Source IP address of the corresponding LSP. 


State of the corresponding LSP handled by this RSVP session: Up, Dn 
(down), or Restart. 


Name of the LSP. 


show mpls association iif 


user@host> show mpls association iif ge-0/0/0.0 





WANS 
WAS) 
LAS) 5 
1287 
Total 4 


IOZ 
LOZ « 
02. 
102. 


174. 
174. 
174. 
174. 


i 2yAL 
2a 
Aa 
2A 


From 
LASs 
WAS) 
I2ASs 
W285 


show mpls association oif 


user@host> show mpls association oif ge-0/0/0.0 


WAS) 6 
128. 
128. 
ALANS) 


OZ. 
102% 
102. 
LOZ 


174. 
174. 
174. 
174. 


Ua 
i 2yAL 
2a 
2A 


From 
TAST 
LAS 6 
WANS) 6 
ASS 


OZ. 
OZ. 
OZ 
OZ « 
displayed, Up 4, 


102. 
kOe 
102. 
LOZ 


180 5 Ail 
WSO o Ail 
10, Ail 
ALO) AL 


Down 0 


U0), 2A 
10 5. Ail 
AS) 5 Ail 
ALf}0) 5 AL 


State 
Up 
Up 
Up 
Up 


State 
Up 
Up 
Up 
Up 


LSPname 
ILS) INC 
SP SAB GAL 
liSPaABEZ 





LSP-ABC3 


LSPname 
LSP-ABC 
IL(S PNY AL 
LSP-ABC2 





LSP-ABC3 
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| show mpls call-admission-control 


List of Syntax 
Syntax on page 2336 
Syntax (EX Series Switches) on page 2336 


Syntax 


show mpls call-admission-control 
<instance instance-name> 

<logical-system (all | logical-system-name)> 
<Isp-name> 


Syntax (EX Series Switches) 


show mpls call-admission-control 
<Isp-name> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
instance instance-name option added in Junos OS Release 15.1. 


Description 
Display Multiprotocol Label Switching (MPLS) label-switched path (LSP) call admission control (CAC) 
information. 


Options 
none—Display CAC information for all LSPs. 


instance instance-name—(Optional) Display MPLS LSP CAC information for the specified instance. If 
instance-name is omitted, MPLS LSP CAC information for the master instance is displayed. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Isp-name—(Optional) Display CAC information for the specified LSP only. 


Additional Information 


The available bandwidth on an LSP path at a particular class type is the total path bandwidth at that class 
type minus the total bandwidth reserved by any Layer 2 connection at that class type. 


Required Privilege Level 
view 
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List of Sample Output 
show mpls call-admission-control on page 2337 


Output Fields 


Table 49 on page 2337 describes the output fields for the show mpls call-admission-control command. 
Output fields are listed in the approximate order in which they appear. 


Table 49: show mpls call-admission-control Output Fields 


Field Name Field Description 


Available bandwidth | Current available bandwidth on each LSP path. Depending on whether the LSP is an E-LSP or 
a regular LSP, either per-class bandwidth or a single bandwidth value (corresponding to 
best-effort bandwidth at ct0) is displayed. The available bandwidth on an LSP path at a particular 
class type is the total path bandwidth at that class type minus the total bandwidth reserved 
by some Layer 2 connections at that class type. 


Layer2 connections | Different Layer 2 connections that had some bandwidth requirement and were admitted into 
an LSP path. 


LSP name LSP pathname. 


Neighbor address Neighbor address from which CAC and bandwidth booking are configured for Layer 2 circuits. 


Circuit Interface name and circuit information. 

Primary LSP's primary standby path. 

Standby LSP's secondary standby path. 

VC bandwidth Bandwidth constraints associated with a Layer 2 circuit route. 


| Sample Output 


show mpls call-admission-control 


user@host# show mpls call-admission-control 


LSP name: prol-be 
“Ee LINEN 


Available bandwidth: Obps 
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LSP name: prol-be-1 
*Primary 


Available bandwidth: 60kbps 


LSP name: prol—be-gold 
*Primary 
Available bandwidth: <ct0 50kbps> <ctl 20kbps> <ct2 30kbps> <ct3 Obps> 
Layer2 connections: 
NeaGiooe eelleascis 10). 255,245,215, Ciimewits so-0/3/O0.0Gve 5) 
VC bandwidth: <ct0O 50kbps> <ctl 40kbps> <ct2 40kbps> 


LSP name: prol-be-gold-2 
“EE LIEN 


Available bandwidth: <ct0 Obps> <ctl 40kbps> <ct2 40kbps> <ct3 Obps> 





LSP name: prol-be-silver 

*Primary priml 

Available bandwidth: <ct0O 10kbps> <ctl 20kbps> <ct2 Obps> <ct3 40kbps> 
Layer2 connections: 
NeaLelnlxoie scllcesss 10.,255.245,215, Caiwemiies so-0/S/0.iiGwe 3) 
VC bandwidth: <ct0O 20kbps> <ct1l 20kbps> 

Standby secl 

Available bandwidth: <ct0O 10kbps> <ctl 10kbps> <ct2 20kbps> <ct3 Obps> 
Layer2 connections: 
Nedighbormaddness  lOm 255m 245i 2a > Cire use SO 0/3) Omea Gems) 
VC bandwidth: <ct0O 20kbps> <ctl 20kbps> 
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| show mpls container-lsp 


Syntax 


show mpls container-Isp 

<brief | detail | extensive | terse> 
<count-active-routes> 
<defaults> 

<descriptions> 

<down | up> 

<egress> 

<ingress> 

<logical-system (all | logical-system-name)> 
<name name> 

<statistics> 

<transit> 

<unidirectional> 


Release Information 
Command introduced in Junos OS Release 14.2. 
Statement introduced for QFX Switches in Junos OS Release 15.1X53-D30. 


Description 


Display information about configured and active Multiprotocol Label Switching (MPLS) container 
label-switched paths (LSPs). 


Options 


none—Display standard information about all configured and active member LSPs of the container LSP. 


brief | detail | extensive | terse—(Optional) Display the specified level of output. The extensive option 
displays the same information as the detail option, but covers the most recent 50 events. 


count-active-routes—(Optional) Show active routes for the container LSP. 
defaults—(Optional) Display the default settings of the container LSP. 


descriptions—(Optional) Display the container LSP descriptions. To view this information, you must 
configure the description statement at the [edit protocol mpls container-Isp] hierarchy level. Only the 
LSPs with a description are displayed. This command is only valid for the ingress routing device, because 
the description is not propagated in RSVP messages. 


down | up—(Optional) Display only LSPs that are inactive or active, respectively. 


egress—(Optional) Display the LSPs ending at this device. 
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NOTE: The egress option displays all the LSPs including regular LSPs, members of container 
LSPs, and transit LSPs. This is an expected behavior for all platforms. 


ingress—(Optional) Display the member LSPs originating from this device. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


name name—(Optional) Display information about the specified LSP or group of LSPs. 


statistics—(Optional) Display accounting information about LSPs. Statistics are not available for LSPs on 
the egress routing device, because the penultimate routing device in the LSP sets the label to O. Also, 
as the packet arrives at the egress routing device, the hardware removes its MPLS header and the 
packet reverts to being an IPv4 packet. Therefore, it is counted as an IPv4 packet, not an MPLS packet. 


transit—(Optional) Display LSPs transiting this routing device. 


unidirectional—(Optional) Display unidirectional LSP information. 


Required Privilege Level 


view 


RELATED DOCUMENTATION 


request mpls container-Isp | 2300 


clear mpls container-Isp | 2265 


List of Sample Output 
show mpls container-Isp on page 2345 
show mpls container-Isp extensive on page 2345 


Output Fields 
Table 50 on page 2340 describes the output fields for the show mpls container-Isp command. Output fields 
are listed in the approximate order in which they appear. 


Table 50: show mpls container-Isp Output Fields 


Field Name Field Description Level of Output 


Ingress LSP Information about the member LSPs on the ingress routing device. Each | All levels 
LSP has one line of output. 


Table 50: show mpls container-Isp Output Fields (continued) 


Field Name 


Container LSP 
name 


Member LSP 
count 


To 


From 


State 


Rt 


ActivePath 


LSPname 


Egress LSP 


Transit LSP 


Min LSPs 


Max LSPs 


Field Description 


Name of the container LSP. 


Number of member LSPs in the container LSP. 


Destination (egress routing device) of the session. 


Source (ingress routing device) of the session. 


State of the LSP handled by this RSVP session: 


e Up 
e Dn (down) 


e Restart 


Number of active routes (prefixes) installed in the routing table. For ingress 
RSVP sessions, the routing table is the primary IPv4 table (inet.0). For 
transit and egress RSVP sessions, the routing table is the primary MPLS 
table (mpls.0). 


Path. An asterisk (*) underneath this column indicates that the LSP is a 
primary path. 


(Ingress LSP) Name of the active path: Primary or Secondary. 

Name of the member LSP. 

Information about the LSPs on the egress routing device. MPLS learns 
this information by querying RSVP, which holds all the transit and egress 
session information. Each session has one line of output. 

Number of LSPs on the transit routing devices and the state of these 
paths. MPLS learns this information by querying RSVP, which holds all 


the transit and egress session information. 


Minimum number of member LSPs. 


Default: 1 


Number of member LSPs that the container LSP can have at maximum. 


Default: 64 (due to ECMP limit) 
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Level of Output 


All levels 


All levels 


brief 


brief detail 


brief detail 


brief 


brief 


detail extensive 


brief detail 


All levels 


All levels 


extensive 


extensive 
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Table 50: show mpls container-Isp Output Fields (continued) 


Field Name Field Description Level of Output 
Aggregate Sum of the bandwidths of all member LSPs. extensive 
bandwidth 

NormalizeTimer Duration between two normalization events. extensive 


When not configured, 21600 seconds (6 hours) is set as the default value. 


NormalizeThreshold | Change in aggregate LSP utilization to trigger splitting or merging extensive 
expressed in percentage. 


Max Signaling BW = Maximum bandwidth used to signal LSPs after a normalization event. extensive 


Default value is O bps. When not configured, the value is inherited from 
the splitting bandwidth configuration. 


NOTE: Between two normalization events, when auto-bandwidth 
adjustment happens, the per-LSP auto-bandwidth configuration and 
thresholds are used, instead of the maximum signaling bandwidth 
threshold. 


Min Signaling BW = Minimum bandwidth used to signal LSPs after a normalization event. extensive 


Default value is O bps. When not configured, the value is inherited from 
the merging bandwidth configuration. 


NOTE: Between two normalization events, when auto-bandwidth 
adjustment happens, the per-LSP auto-bandwidth configuration and 
thresholds are used, instead of the minimum signaling bandwidth threshold. 


Splitting BW Bandwidth used for LSP splitting and merging. extensive 


Default value is O bps. When not configured, the value is inherited from 
the auto-bandwidth maximum bandwidth configuration. 


Merging BW Bandwidth used for LSP splitting and merging. extensive 


Default value is O bps. When not configured, the value is inherited from 
the auto-bandwidth minimum bandwidth configuration. 


LSPtype extensive 


LoadBalance extensive 


MinBW Minimum LSP bandwidth in bps related to auto-bandwidth. extensive 


Table 50: show mpls container-Isp Output Fields (continued) 


Field Name 


AdjustTimer 


Max AvgBW util 


Overflow limit 


Underflow limit 


Encoding type 


Switching type 


GPID 


Priorities 


Bandwidth 


SmartOptimizeTimer 


Computed ERO 


Field Description 


Total amount of time in seconds allowed before LSP bandwidth adjustment 
take place. 


Range: 300 through 315360000 seconds 


Current value of the actual maximum average bandwidth utilization in 
bps. 


Threshold overflow limit. 


Threshold underflow limit. 


Setup priority and hold priority values. 
For setup priority, O and 7 is the highest and lowest priority, respectively. 


When not explicitly configured, 7 and O are set as the default values for 
the setup priority and hold priority, respectively. 


Time in seconds allowed before path reoptimization. 


Computed explicit route. A series of hops, each with an address followed 
by a hop indicator. The value of the hop indicator can be strict (S) or loose 


(L). 


Level of Output 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 
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Table 50: show mpls container-Isp Output Fields (continued) 


Field Name 


Received RRO 


Make-before-break 


Record Route 


Field Description 


Received record route. 


RRO is a series of hops, each with an address followed by a flag. In most 
cases, the received RRO is the same as the computed ERO. If the received 
RRO is different from the computed ERO, there is a topology change in 


the network, and the route is taking a detour. 


The following flags identify the protection capability and status of the 
downstream node: 


e 0x01—Local protection available. The link downstream from this node 
is protected by a local repair mechanism. This flag can be set only if the 
local protection flag was set in the SESSION_ATTRIBUTE object of the 


corresponding path message. 


e 0x02—Local protection in use. A local repair mechanism is in use to 
maintain this tunnel (usually because of an outage of the link it was 
routed over previously). 


e 0x03—Combination of 0x01 and 0x02. 


e 0x04—Bandwidth protection. The downstream routing device has a 
backup path providing the same bandwidth guarantee as the protected 
LSP for the protected section. 


e 0x08—Node protection. The downstream routing device has a backup 
path providing protection against link and node failure on the 
corresponding path section. If the downstream routing device can set 
up only a link-protection backup path, the local protection available bit 
is set but the node protection bit is cleared. 

e 0x09—Detour is established. Combination of 0x01 and 0x08. 

e 0x10—Preemption pending. The preempting node sets this flag if a 
pending preemption is in progress for the traffic engine LSP. This flag 
indicates to the ingress legacy edge router (LER) of this LSP that it 
should be rerouted. 

e 0x20—Node ID. Indicates that the address specified in the RRO’s IPv4 
or IPv6 sub-object is a node ID address, which refers to the router 


address or router ID. Nodes must use the same address consistently. 


e Oxb—Detour is in use. Combination of 0x01, 0x02, and 0x08. 
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Level of Output 


extensive 


extensive 


extensive 


Table 50: show mpls container-Isp Output Fields (continued) 


Field Name Field Description 
Automatic 

Autobw 

adjustment 

succeeded 


CSPF 


Created Date and time the LSP was created. 


| Sample Output 
show mpls container-Isp 


user@host> show mpls container-Isp 


Ingress LSP: 1 sessions 


Container LSP name 





meisie 

1) From Siescee Bye le 
10.255. 107 . 76 10.2556 L07 6 7 Up Ones 
10 .255-107 .76 10 .255.6107 78 Up Ome 
Total 2 displayed, Up 2, Down 0 





naling Egress LSP: 1 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


show mpls container-Isp extensive 


user@host> show mpls container-Isp extensive 


Ingress LSP: 1 sessions 





Container LSP name: test, Member count: 2 


Normalization 


Min LSPs: 2, Max LSPs: 64, Aggregate bandwidth: Obps 


NormalizeTimer: 1800 secs, NormalizeThreshold: 0% 


ActivePath 
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Level of Output 


extensive 


extensive 


extensive 


Member LSP count 


2 
LSPname 
ESSE IL 
ESSIEN 
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Max Signaling BW: 2kbps, Min Signaling BW: 2kbps, Splitting BW: 5Mbps, Merging 
BW: 2kbps 

Normalization in 989 second(s) 
10 2555107 .716 

From: 10.255.107.78, State: Up, ActiveRoute: 0, LSPname: test-1 

ActivePath: (primary) 
LSPtype: Dynamic Configured, Penultimate hop popping 





LoadBalance: Random 

Autobandwidth 

MinBW: 1000bps 

AdjustTimer: 300 secs 

ax AvgBW util: Obps, Bandwidth Adjustment in 89 second(s). 

Overflow limit: 0, Overflow sample count: 0 

Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: Obps 
Encoding type: Packet, Switching type: Packet, GPID: IPv4 





+ 


Primary State: Up, No-decrement-ttl 

| =p as oa ob 0) 

Bandwidth: 1000bps 

SmartOptimizeTimer: 180 

Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2) 

LeSoOo2 S&S IntoO ol § 

Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID) : 
1535002 doFsOot 
11 Jul 13 20:08:26.613 Make-before-break: Switched to new instance 
10 vol 1s ZOsssO4. 360 Recor Remees L.3.0.4 1o7.Wol 
9 dul 13 ZOsWssO4, 360 Ue 
8 Jul 13 20:08:04.360 Automatic Autobw adjustment succeeded: BW changes from 
2000 bps to 1000 bps 
Jul 13 20:08:04.314 Originate make-before-break call 
Jui 13 20s08eO4.sil4 CSeits Comeuicacion resulle acecerec 1.3.0.2 147,01 
1 13 20:05:02.423 Selected as active path 
Jul 1s ZOsWss02.422 Recor IRowres bodcO0o2 toy oWoi 
vill 1S ZOs0S302.421 Us 
SUIS 20: VS 02S om Origanatcm allt 
i gw 13 Z2ZOs05s02.376 CSikis Coljomicacioa mesulle acessrec i153,0.2 147,021 

Cxeacecds Sere wil 1s 20e0S3s0S ZOLS 
10.2555 107.76 
From: 10.255.107.78, State: Up, ActiveRoute: 0, LSPname: test-2 











ISy tes) Ss (nk en Sa 
cy 
G 








ActivePath: (primary) 
LSPtype: Dynamic Configured, Penultimate hop popping 





LoadBalance: Random 
Autobandwidth 
MinBW: 1000bps 
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AdjustTimer: 300 secs 
Max AvgBW util: Obps, Bandwidth Adjustment in 89 second(s). 
Overflow limit: 0, Overflow sample count: 0 


Underflow limit: 0, Underflow sample count: 0, Underflow Max AvgBW: Obps 





Encoding type: Packet, Switching type: Packet, GPID: IPv4 


*Primary State: Up, No-decrement-ttl 


Priorities: 7 0 
Bandwidth: 1000bps 


SmartOptimizeTimer: 180 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 2) 
beSoOn2 S GeO. 2 S 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 





20=Node-ID): 


12.062 1,450.2 
11 Jul 13 20:08:05.363 Make-before-break: Switched to new instance 
LO woul 1s ZOsOseO4 A50) inscomc RewreSes Lo2.0.2 1.4.0.2 
9 Jul 13 20:08:04.449 Up 
8 Jul 13 20:08:04.449 Automatic Autobw adjustment succeeded: BW changes from 


2000 bps to 1000 bps 





Jul 13 20:08:04.327 Originate make-before-break call 
aul 13 2ZOsOseO4A S27 CSiees CemisotlicsicLem mesulle acecseeec 1.2.0.2 1.4.0.2 
Jul 13 20:05:00.849 Selected as active path 
Jul Is ZOsIOSsOO 84 Recor owmcee 153,02 1.7.0.1 
Jw 13 2ZO,0Ss00.831 Up 
vu 13 20s0SsOO.513 Oricamate Cali 
i gwul 1S 2ZOsOSs00.,502 CSErs COmpuIEaciem result acessittec 1.3.0.2 1.7.0.1 
Cwserecls Sere vel 1s 2Ws0ss03 2013 


[Sy 163) SS Gn ten 
| 








Total 2 displayed, Up 2, Down 0 








Egress LSP: 1 sessions 
Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 
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| show mpls context-identifer 


Syntax 


show mpls context-identifer 

<brief | detail> 

<logical-system (all | logical-system-name)> 
<primary>; 

<protector>; 


Release Information 
Command introduced in Junos OS Release 11.4R3. 


Description 


Display information about configured egress protection context identifiers. 


Options 


none—Display standard information about egress protection. 
brief | detail—(Optional) Display the specified level of output. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


primary—(Optional) Perform this operation on the primary node. 


protector—(Optional) Perform this operation on the protector node. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


Example: Configuring Layer 3 VPN Egress Protection with RSVP and LDP 
Example: Configuring MPLS Egress Protection for Layer 3 VPN Services 


List of Sample Output 
show mpls context-identifier detail (Protector) on page 2349 
show mpls context-identifier detail (Primary) on page 2350 


Output Fields 


Table 51 on page 2349 describes the output fields for the show mpls egress-protection detail command. 
Output fields are listed in the approximate order in which they appear. 


Table 51: show mpls Isp Output Fields 
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Field Name Field Description Level of Output 

ID Context identifier. All levels 

Type Indicates node type: protector or primary All levels 

Metric MPLS cost value of the context identifier route. This | All levels 
route appears in inet.O on the protector and primary 
nodes. On the protector node, the metric is a larger 
number. 

Mode Indicates advertise-mode: proxy or alias detail 

Context table Name of the MPLS routing table created for egress All levels 
protection. 

Context LSPs Names of the LSPs that have egress protection detail 
configured. 
Loopback interface addresses of the devices from 
which the LSPs are originated. 

Total Total number of primary and protector nodes. All levels 

Primary Number of primary nodes. All levels 

Protector Number of protector nodes. All levels 

| Sample Output 
show mpls context-identifier detail (Protector) 
user@host> show mpls context-identifier detail 
WBS 6G. ., 3.4 il 
Type: protector, Metric: 16777215, Mode: alias 
Context eabile: eel 6oe ls Tee nplsn0)) babel outs 92999168 
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| Sample Output 


show mpls context-identifier detail (Primary) 


user@host> show mpls context-identifier detail 


WDE UGGs ls dod 


Type: primary, Metric: 1, Mode: alias 


Total 1, Primary 1, Protector 0 


2351 


| show mpls correlation label 


Syntax 


show mpls correlation label label-value 
<brief | detail | extensive | terse> 
<descriptions> 


<logical-system (all | logical-system-name)> 


Release Information 
Command introduced in Junos OS Release 15.2 for the M Series, MX Series, and T Series. 


Description 
Display the correlation information for the Multiprotocol Label Switching (MPLS) label-switched path (LSP) 
with the owner of the label. 


Options 


label-value—Display information about the specified label. 


brief | detail | extensive | terse—(Optional) Display the specified level of output. The extensive option 
displays the same information as the detail option, but covers the most recent 50 events. 


descriptions—(Optional) Display the LSP descriptions. To view this information, you must configure the 
description statement at the [edit protocol mpls Isp] hierarchy level. Only the LSPs with a description 
are displayed. This command is only valid for the ingress routing device, because the description is 
not propagated in RSVP messages. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


show mpls correlation nexthop-id | 2352 


show mpls association | 2334 
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| show mpls correlation nexthop-id 


Syntax 


show mpls correlation nexthop-id nexthop-id 
<descriptions> 
<logical-system (all | logical-system-name)> 


Release Information 
Command introduced in Junos OS Release 16.1 for the M Series, MX Series, and T Series. 


Description 
Display the correlation information for the Multiprotocol Label Switching (MPLS) label-switched path (LSP) 
with the owner of the next-hop ID. 


Options 
nexthop-id—Display information about the specified next-hop ID. 


descriptions—(Optional) Display the LSP descriptions. To view this information, you must configure the 
description statement at the [edit protocol mpls Isp] hierarchy level. Only the LSPs with a description 
are displayed. This command is only valid for the ingress routing device, because the description is 
not propagated in RSVP messages. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


show mpls association | 2334 


List of Sample Output 
show mpls correlation nexthop-id on page 2353 


Output Fields 


Table 52 on page 2353 describes the output fields for the show mpls correlation nexthop-id command. 
Output fields are listed in the approximate order in which they appear. 


Table 52: show mpls correlation nexthop-id Output Fields 


Field Name Field Description 


LSP name Name of the LSP associated with the specified next-hop ID. 


| Sample Output 


show mpls correlation nexthop-id 


user@host> show mpls correlation nexthop-id nexthop-id 


LSP name: LSP-ABC 
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| show mpls cspf 


List of Syntax 
Syntax on page 2354 
Syntax (EX Series Switches) on page 2354 


Syntax 


show mpls cspf 
<instance instance-name> 
<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


show mpls cspf 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
instance instance-name option added in Junos OS Release 15.1. 


Description 
Display Multiprotocol Label Switching (MPLS) Constrained Shortest Path First (CSPF) statistics. 


Options 
none—Display MPLS CSFP statistics. 


instance instance-name—(Optional) Display MPLS CSPF information for the specified instance. If 
instance-name is omitted, MPLS CSPF information for the master instance is displayed. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


List of Sample Output 
show mpls cspf on page 2356 


Output Fields 
Table 53 on page 2355 describes the output fields for the show mpls cspf command. Output fields are listed 
in the approximate order in which they appear. 
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Table 53: show mpls cspf Output Fields 


Field Name 


Queue length 


current 


maximum 


dequeued 


Paths 


total 


successful 


no route 


Sys Error 


CSPFs 


Time 


Total 


CSPFs 


Avg per CSPF 


% of rpd 


Field Description 


Number of LSPs queued for automatic path computation. 


Current queue length. 


Maximum queue length (high-water mark). 


Number of aborted computation attempts. 


Counters for label-switched path computations. 


Sum of the next four fields. 


Number of path computations that were successfully 
completed. 


Number of path computations that failed because the 
destination is unreachable. 


Number of path computations that failed because of lack of 
memory. 


Total number of CSPF computations. A single path might 
require multiple CSPF computations. 


Time, in seconds, required to perform the label-switched path 
computation. 


Total amount of time consumed by the CSPF path computation 
algorithm. 


Total number of CSPF computations. 


Average amount of time required for each CSPF computation. 


Percentage of routing process CPU used in the CSPF 
computation. 


| Sample Output 
show mpls cspf 


user@host> show mpls cspf 


CSDEMESiECeasie kes 


Queue length current 


0 
Paths EOI SUL 
0 
Time (secs) total 


0.000000 


maximum 

0 

Success mull 
0 

SEES 
0.000000 


dequeued 

0 

Ine) 1e(OVNETS) 

0 

Be; joeie CSR 
0.000000 
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sys error CSEBHS 
0 0 
% of rpd 
0.0000 
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| show mpls diffserv-te 


List of Syntax 
Syntax on page 2357 
Syntax (EX Series Switches) on page 2357 


Syntax 


show mpls diffserve-te 
<instance instance-name> 
<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


show mpls diffserve-te 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
instance instance-name option added in Junos OS Release 15.1. 


Description 
Display Multiprotocol Label Switching (MPLS) label-switched path (LSP) Differentiated Services (DiffServ) 
class and preemption priority information. 


Options 
none—Display DiffServ classes and priorities used by MPLS LSPs. 


instance instance-name—(Optional) Display DiffServ classes and priorities used by MPLS LSPs for the 
specified instance. If instance-name is omitted, DiffServ information for the master instance is displayed. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


List of Sample Output 
show mpls diffserv-te on page 2358 


Output Fields 


Table 54 on page 2358 describes the output fields for the show mpls diffserv-te command. Output fields 
are listed in the approximate order in which they appear. 


2358 


Table 54: show mpls diffserv-te Output Fields 


Field Name 


Bandwidth model 


TE class 


Traffic class 


Priority 


| Sample Output 


show mpls diffserv-te 


Field Description 


Bandwidth constraint model supported. The maximum 
allocation model (MAM) for EXP-inferred LSPs (E-LSPs) is 


currently supported. 


DiffServ traffic engineering class. 


MPLS class type that corresponds to the DiffServ traffic 
engineering class: 


e ctO—Best effort 
e cti—Assured forwarding 


e ct2—Expedited forwarding 


ct3—Network control 


MPLS preemption priority for this class type, a value from O 
through 7. Interior gateway protocols (IGPs) distribute 
information about the available bandwidth for each traffic 


engineering class. 


user@host> show mpls diffserv-te 





Bandwidth model: Maximum Allocation Model with support for E-LSPs. 





ia Cilagis 
ted 
tel 


Trariie class | agukeraubieny, 
Sel 3 
Gell Z 
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| show mpls interface 


Syntax 


show mpls interface 


Release Information 
Command introduced in Junos OS Release 9.5 for EX Series switches. 


Description 

Display information about MPLS-enabled interfaces. MPLS is enabled on an interface when the interface 
is configured with both the set protocols mpls interface interface-name and set interfaces interface-name 
unit O family mpls commands. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


Example: Configuring MPLS on EX8200 and EX4500 Switches | 42 

Configuring CoS on an MPLS Provider Edge Switch Using IP Over MPLS | 1225 
Configuring CoS on an MPLS Provider Edge Switch Using Circuit Cross-Connect | 1228 
Configuring MPLS on EX8200 and EX4500 Provider Switches | 78 





List of Sample Output 
show mpls interface on page 2360 


Output Fields 
Table 55 on page 2359 describes the output fields for the show mpls interface command. Output fields are 
listed in the approximate order in which they appear. 


Table 55: show mpls interface Output Fields 


Field Name Field Description 
Interface Name of the interface. 
State State of the interface: Up or Dn (down). 


Administrative groups Administratively assigned colors of the link. 
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| Sample Output 
show mpls interface 


user@switch> show mpls interface 


Interface State Administrative groups 
SO=L/0/@.0 Wis Blue Yellow Red 
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| show mpls egress-protection 


Syntax 


show mpls egress-protection 
<brief | detail> 


<logical-system (all | logical-system-name)> 


Release Information 
Command introduced in Junos OS Release 11.4R3. 


Description 


Display information about egress protection. 


NOTE: Use this command on the device configured as the protector PE router to display 
information about egress protection. If you use this command on the device configured as the 
primary PE router, no output is displayed. 


Options 


none—Display standard information about egress protection. 
brief | detail—(Optional) Display the specified level of output. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


Example: Configuring MPLS Egress Protection for Layer 3 VPN Services 
Example: Configuring Layer 3 VPN Egress Protection with RSVP and LDP 


List of Sample Output 
show mpls egress-protection detail (Centralized Protector) on page 2362 
show mpls egress-protection detail (Collocated Protector) on page 2362 


Output Fields 
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Table 51 on page 2349 describes the output fields for the show mpls egress-protection detail command. 
Output fields are listed in the approximate order in which they appear. 


Table 56: show mpls Isp Output Fields 


Field Name Field Description 

Instance Indicates egress instance name 

Type Indicates type of the VRF. It can be either local-vrf or remote-vrf 
RIB Indicates the edge-protection created routing table 

Context-Id Indicates the context-ID associated with the RIB. 


heface/Ehencaxtodap == Show VT interfaces associated with the backup RIB. 


Shows Enhanced-lookup for MX Series 5G Universal Routing Platforms 
with the Enhanced IP Network Services mode configured using the 
network-services enhanced-ip statement at the [edit chassis] hierarchy 
level. 


| Sample Output 


show mpls egress-protection detail (Centralized Protector) 


user@host> show mpls egress-protection detail 


instance Type Protection-Type 


rsitel remote-vrf Protector 





REB Qe I9e JOA ast a nee Oconee — don Imi 4 tnhianced— Lookup 
Route Target 1:1 


rsite24 remote-vrf Protector 





RIB __99.99.1.4-rsite24 _.inet.0, Context-Id 99.99.1.4, Enhanced-lookup 
Route Target 100:1023 


| Sample Output 


show mpls egress-protection detail (Collocated Protector) 


user@host> show mpls egress-protection detail 
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instance Type Protection-Type 
site2 local —=wieit Protector 
RIB __66.6.6.6-site2. _.inet.0, Context-Id 66.6.6.6, Interface vt-1/3/0.87031809 


Route Target 100:251 
sitel2 Io@eul—=ywaeit Protector 


RIB __66.6.6.6-sitel2 .inet.0, Context-Id 66.6.6.6, Interface vt-1/3/0.87031808 


Route Target 100:250 





Route Target 100:251 


site2 sL@xeal ll —waeic Protector 


RIB __66.6.6.6-site2 _.inet.0, Context-Id 66.6.6.6, Interface vt-1/3/0.87031809 





Route Target 100:251 
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| show mpls interface 


List of Syntax 
Syntax on page 2364 
Syntax (EX Series Switches) on page 2364 


Syntax 


show mpls interface 
<instance instance-name> 


<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


show mpls interface 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
instance instance-name option added in Junos OS Release 15.1. 


Description 


Display information about Multiprotocol Label Switching (MPLS)-enabled interfaces. 


Options 


none—Display information about MPLS-enabled interfaces. 


instance instance-name—(Optional) Display information about MPLS-enabled interfaces for the specified 
routing instance. If instance-name is omitted, information about MPLS-enabled interfaces is displayed 
for the master instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Additional Information 


MPLS is enabled on an interface when the interface is configured with both the set protocol mpls interface 
interface-name and set interface interface-name unit 0 family mpls statements. 


Required Privilege Level 
view 


List of Sample Output 
show mpls interface on page 2366 


Output Fields 
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Table 57 on page 2365 describes the output fields for the show mpls interface command. Output fields are 


listed in the approximate order in which they appear. 


Table 57: show mpls interface Output Fields 


Field Name 


Interface 


State 


Administrative groups 


Maximum labels 


Static protection revert 
time 


Always mark connection 
protection tlv 


Field Description 


Name of the interface. 


State of the interface: Up or Dn (down). 


Administratively assigned colors of the link. 


Maximum number of MPLS labels upon which MPLS can 
operate on a logical interface. This is configured using the 
maximum-labels statement at the [edit logical-systems 
logical-system-name interfaces interface-name unit 
logical-unit-number family mpls] or the [edit interfaces 
interface-name unit logical-unit-number family mpls] hierarchy 
levels. 


Time (in seconds) that a static LSP must wait before traffic 
reverts from the bypass path to the original path. This is 
configured using the protection-revert-time statement at the 
[edit logical-systems logical-system-name protocols mpls 
interface interface-name static] or the [edit protocols mpls 
interface interface-name static] hierarchy levels. 


Enabled or Disabled: Enabled indicates that the 
always-mark-connection-protection-tlv statement is 
configured at the [edit logical-systems logical-system-name 
protocols mpls interface interface-name static] or the [edit 
protocols mpls interface interface-name static] hierarchy levels. 
When this statement is configured, it marks all OAM traffic 
transiting this interface in preparation for switching the traffic 
to an alternate path based on the OAM functionality. To switch 
traffic to the bypass LSP, the switch-away-lIsps statement must 


be configured. 
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Table 57: show mpls interface Output Fields (continued) 


Field Name Field Description 


Switch away Isps Enabled or Disabled: Enabled indicates that the 
switch-away-Isps statement is configured at the [edit 
logical-systems logical-system-name protocols mpls interface 
interface-name static] or the [edit protocols mpls interface 
interface-name static] hierarchy levels. This enables you to 
switch an LSP away from a network node using a bypass LSP. 
This feature can be used in maintenance of active networks 
when a network device needs to be replaced without 
interrupting traffic passing through the network. The LSPs can 
be either static or dynamic. 


Sample Output 


show mpls interface 


user@host> show mpls interface 


Interface: ge-0/2/1.57 
State: Up 
Administrative group: <none> 


Maximum labels: 5 





Static protection revert time: 5 seconds 
Always mark connection protection tlv: Disabled 


Switch away lsps : Disabled 
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| show mpls label usage 


Syntax 


show mpls label usage 

<label label value> 

<label-range range-start range-end> 
<logical-system (all | logical-sytem-name)> 


Release Information 

Command introduced in Junos OS Release 15.1. 

Support for the label statement added in Junos OS Release 17.2. 
Support for the label-range statement added in Junos OS Release 17.2. 


Description 

Show the available label space resource in RPD and also the applications that use the label space in RPD. 
There are four different label spaces currently used in MPLS—namely LSI, dynamic, block, and static. Each 
label space has a fixed number and cannot grow beyond the fixed value. Using this command, the 
administrator can monitor the available labels in each label space and the applications that are using the 
labels. Based on the availability of labels, the administrator can decide to stop any service and free some 
labels or use other service where the labels are available. 


Starting in Junos OS Release 17.2, you can configure the enhanced-ip command, which is supported on 
platforms using Modular Port Concentrators (MPCs) equipped with Junos Trio chipsets. You can also 
separate the MPLS labels used for different label spaces which provides more flexibility and scalability. 


When you set each member router’s network services to enhanced-ip, only MPC or Modular Interface 
Cards (MICs) modules and Multiservices Dense Port Concentrator (MS-DPC) modules are powered on in 
the chassis. Non-service DPCs do not work with enhanced IP network services. 


Options 


none— Display the available labels in each label space and the applications using the labels. 


label label value—(Optional) Display the information about which label value is used by which protocol, if 
any. 


label-range range-start range-end —(Optional) Display the complete information about the label-range 
specified. WIth the enhanced-ip command enabled on the supported device, effective ranges and 
configured ranges along with details of different label spaces such as LSI, dynamic, block, and static 
types are displayed. 


logical-system (all |logical-system-name)—(Optional) Perform this operation on all logical systems or on a 
particular logical system. 


Additional Information 
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Once the label space crosses the threshold, a new syslog message is added. 
<label-space-name> label space usage crossed threshold limit of 90%. 


For instance, LSI label space usage crossed threshold limit of 90%. 


Required Privilege Level 
view 


List of Sample Output 
show mpls label usage on page 2368 


Output Fields 
Table 58 on page 2368 describes the output fields for the show mpls label usage command. Output fields 
are listed in the order in which they appear. 


Table 58: show mpls label usage Fields 


Field Name Field Description 

Label Space Indicates the different types of labels currently used in MPLS. 
Total Indicates the total label space available. 

Available Indicates the number of freely available labels and also the 


percentage of the label space available. 
Applications Indicates the applications that use the MPLS label spaces. 


Effective Ranges Indicates actual ranges in use, which can be different from 
configured ranges, if conflicting with label already allocated. 


Configured Ranges Indicates the currently configured range assigned to different 
label spaces on the device. 


| Sample Output 
show mpls label usage 


user@host> show mpls label usage 


Label space Total Available Applications 
layeue 999984 999971 (100.00%) BGP/LDP VPLS with no-tunnel-services, BGP 








L3VPN with vrf-table-label 


Block 
Dynamic 


MVPN, EVPN 





Static 


999984 999971 (100.00%) BGP/LDP VPLS with tunnel-services, BGP L2VPN 
999984 SVSIEML (NOW ONOS)) IRISWWA2, IWDI2, IM, InSWPIN, IRSWIP SI 2MIP Ide =I) Z Miley, 

Pe SGE 
48576 ASSIS (CUOO OW) Siceiete WS, Siege Ii) 


With enhanced-ip enabled on the supported device, you get the following additional output. 


user@host> 


Label spac 
St 

L3VPN with 
Block 
Dynamic 


(VPN, EVPN 





Siecle 


Range name 


Dynamic 





Dynamic 
Siealeelic’ 
SRGB 
SRGB 


show mpls label usage 





Effective Ranges 





Configured Ranges 


Range name 
Dynamic 
Dynamic 
Sieaicaic 
SRGB 

SRGB 


user@host> 


Label 101 


user@host> 


Label 102 


user@host> 





e Total Available Applications 

996983 996983 (100.00%) BGP/LDP VPLS with no-tunnel-services, BGP 
Wares eicllolc slecio cals 

996983 996983 (100.00%) BGP/LDP VPLS with tunnel-services, BGP L2VPN 

MIoIIS QWIoVss (10.002) IWS, De, Bi, SWeIN, INSWI2=22IMl2, IDI —22IMie, 
meSGe 

48576 AGI (OO ,O0%S) Siceicae Se, Sicaicaue Ii 

Shared with Start End 

16 QQ) 

4001 MO9I99) 

1000000 1048575 

1000 BONS) OSPE 

3000 4000 GLOBAL 

Shared with Start End 

16 QQ) 

4001 VIMY) 

1000000 1048575 

1000 BODY) OSPE 

3000 4000 GLOBAL 


show mpls label usage label 101 


is used by protocol BGP 


show mpls label usage label 102 


is used by protocol LDP 


show mpls label usage label 103 
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| show mpls label usage label-range 


Syntax 


show mpls label usage label-range 
<block-label-range range-start range-end> 
<dynamic-label-range range-start range-end> 
<label-limit label-limit value> 

<lsi-label-range range-start range-end> 
<static-label-range range-start range-end> 


Release Information 
Command introduced in Junos OS Release 17.2. 


Description 

There are four different label spaces currently used in MPLS—namely LSI, dynamic, block, and static. Each 
label space has a fixed number and cannot grow beyond the fixed value. Using show mpls label usage 
label-range command, the administrator can monitor the available labels in each label space and the 
applications that are using the labels. Based on the availability of labels, the administrator can decide to 
stop any service and free some labels or use other service where the labels are available. 


Starting in Junos OS Release 17.2, you can configure the enhanced-ip command, which is supported on 
platforms using Modular Port Concentrators (MPCs) equipped with Junos Trio chipsets. You can also 
separate the MPLS labels used for different label spaces which provides more flexibility and scalability. 


When you set each member router’s network services to enhanced-ip, only MPC or Modular Interface 
Cards (MICs) modules and Multiservices Dense Port Concentrator (MS-DPC) modules are powered on in 
the chassis. Non-service DPCs do not work with enhanced IP network services. 


Options 
block-label-range range-start range-end—Display the details of block label type. 


dynamic-label-range range-start range-end —Display the details of dynamic label type. 
label-limit label-limit value—Limit for the number of concurrent active labels. 
Isi-label-range range-start range-end—Display the details of LSI label type. 


static-label-range range-start range-end—Display the details of static label type. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 
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show mpls label usage | 2367 


Output Fields 
Table 59 on page 2372 describes the output fields for the show mpls label usage label-range command. 
Output fields are listed in the order in which they appear. 


Table 59: show mpls label usage label-range Fields 


Field Name Field Description 

Label Space Indicates the different types of labels currently used in MPLS. 
Total Indicates the total label space available. 

Available Indicates the number of freely available labels and also the 


percentage of the label space available. 
Applications Indicates the applications that use the MPLS label spaces. 


Effective Ranges Indicates actual ranges in use, which can be different from 
configured ranges, if conflicting with label already allocated. 


Configured Ranges Indicates the currently configured range assigned to different 
label spaces on the device. 


Total Indicates the currently used labels with label type and 
application type details. 


| Sample Output 


With the enhanced-ip command enabled on the supported device, you get the following output. 


user@host> show mpls label usage label-range 16 600 


Label space Total Available Applications 

IeySh1c iL@al Hg) (98.02% ) BGP/LDP VPLS with no-tunnel-services, BGP 
L3VPN with vrf-table-label 

Block LOA. IL@aL (100.00%) BGP/LDP VPLS with tunnel-services, BGP L2VPN 
Dynamic 101 98 (97.03% ) RSVP, LDP, PW, L3VPN, RSVP-P2MP, LDP-P2MP, 





‘VPN, EVPN, BGP 
Simei 48576 48576 (100 00%) Sireicie WSR, Siceicae Pn 








Effective Ranges 


Range name 
LSI 

Block 
Dynamic 


Sieaicene 


Shared with Start End 





300 400 
500 600 
100 200 


1000000 1048575 


Configured Ranges 


Range name 
St 

Block 
Dynamic 


Sivaisene 


Total (16 to 


Label type 
St 
Dynamic 
App type 
LDP 

BGP 
RT_INSTANCI 








Ey 


Shared with Start End 





300 400 
500 600 
100 200 
1000000 1048575 
600) 5 
Alloc count 
2 

3 

Alloc count 
al 

2 

2 
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| show mpls Isp 


List of Syntax 
Syntax on page 2374 
Syntax (EX Series Switches) on page 2374 


Syntax 


show mpls Isp 

<brief | detail | extensive | terse> 
<abstract-computation> 
<autobandwidth> 

<bidirectional | unidirectional> 
<bypass> 

<count-active-routes> 
<defaults> 

<descriptions> 

<down | up> 
<externally-controlled> 
<externally-provisioned> 
<instance routing-instance-name> 
<locally-provisioned> 
<logical-system (all | logical-system-name)> 
<Isp-type> 

<name name> 

<p2mp> 

<reverse-statistics> 

<segment> 

<statistics> 

<transit> 


Syntax (EX Series Switches) 


show mpls Isp 

<brief | detail | extensive | terse> 
<bidirectional | unidirectional> 
<bypass> 

<descriptions> 

<down | up> 
<externally-controlled> 
<externally-provisioned> 
<Isp-type> 

<name name> 


<p2mp> 
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<statistics> 
<transit> 


Release Information 

Command introduced before Junos OS Release 7.4. 

defaults option added in Junos OS Release 8.5. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
autobandwidth option added in Junos OS Release 11.4. 
externally-controlled option added in Junos OS Release 12.3. 
externally-provisioned option added in Junos OS Release 13.3. 
Command introduced in Junos OS Release 13.2X51-D15 for QFX Series. 
instance instance-name option added in Junos OS Release 15.1. 


Description 
Display information about configured and active dynamic Multiprotocol Label Switching (MPLS) 
label-switched paths (LSPs). 


Options 


none—Display standard information about all configured and active dynamic MPLS LSPs. 


brief | detail | extensive | terse—(Optional) Display the specified level of output. The extensive option 
displays the same information as the detail option, but covers the most recent 50 events. 


In the extensive command output, the duplicate back-to-back messages are recorded as aggregated 
messages. An additional timestamp is included for these aggregated messages, where if the aggregated 
messages are five or less, timestamp deltas are recorded for each message, and if the aggregated 
messages are greater than five, the first and last timestamp is recorded. 


For example: 


e All timestamps 


M204 gon 29) IseZ3cas405 S4. 239 43, 110s wsqollueie imowises loacl SicriLGei: mouIre iS 
Cass — LIs2LeOO, LSseecOil, Lse2se2l0] 





e Timestamp deltas 


Q204 gon 29) IseeZsc4s 405 SA 239 43, 110s wsqolieie ikewites loach Sieriei: moure iS 
tease = WSs ZL), srils@il, qe eaO] 





e First and last timestamp 
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C204 wim 29 Isse seas “HOS 54.259 .43 is iegollilenic INSwIESas ISacl Sere rOUES [16 
Tealnias = LSSZLeoo, lsis2seilO] 


abstract-computation—(Optional) Display abstract computation preprocessing for LSPs. 


See show mpls Isp abstract-computation for more details. 


autobandwidth—(Optional) Display automatic bandwidth information. This option is explained separately 
(see show mpls Isp autobandwidth). 


bidirectional | unidirectional—(Optional) Display bidirectional or unidirectional LSP information, respectively. 
bypass—(Optional) Display LSPs used for protecting other LSPs. 

count-active-routes—(Optional) Display active routes for LSPs. 

defaults—(Optional) Display the MPLS LSP default settings. 


descriptions—(Optional) Display the MPLS label-switched path (LSP) descriptions. To view this information, 
you must configure the description statement at the [edit protocol mpls Isp] hierarchy level. Only LSPs 
with a description are displayed. This command is only valid for the ingress routing device, because 
the description is not propagated in RSVP messages. 


down | up—(Optional) Display only LSPs that are inactive or active, respectively. 


externally-controlled—(Optional) Display the LSPs that are under the control of an external Path 
Computation Element (PCE). 


externally-provisioned—(Optional) Display the LSPs that are generated dynamically and provisioned by 
an external Path Computation Element (PCE). 


instance instance-name—(Optional) Display MPLS LSP information for the specified instance. If instance-name 
is omitted, MPLS LSP information is displayed for the master instance. 


locally-provisioned—(Optional) Display LSPs that have been provisioned locally by the Path Computation 
Client (PCC). 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Isp-type—(Optional) Display information about a particular LSP type: 


e bypass—Sessions for bypass LSPs. 
e egress—Sessions that terminate on this routing device. 


e ingress—Sessions that originate from this routing device. 
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e pop-and-forward—Sessions that originate from RSVP-TE pop-and-forward LSP tunnels. 


e transit—Sessions that pass through this routing device. 


name name—(Optional) Display information about the specified LSP or group of LSPs. 
p2mp—(Optional) Display information about point-to-multipoint LSPs. 
reverse-statistics—(Optional) Display packet statistics for reverse direction of LSPs. 
segment—(Optional) Display segment identifier (SID) labels. 


statistics—(Optional) (Ingress and transit routers only) Display accounting information about LSPs. Statistics 
are not available for LSPs on the egress routing device, because the penultimate routing device in the 
LSP sets the label to O. Also, as the packet arrives at the egress routing device, the hardware removes 
its MPLS header and the packet reverts to being an IPv4 packet. Therefore, it is counted as an IPv4 
packet, not an MPLS packet. 


NOTE: If a bypass LSP is configured for the primary static LSP, display cumulative statistics of 
packets traversing through the protected LSP and bypass LSP when traffic is re-optimized 
when the protected LSP link is restored. (Bypass LSPs are not supported on QFX Series switches.) 


When used with the bypass option (show mpls Isp bypass statistics), display statistics for the 
traffic that flows only through the bypass LSP. 


transit—(Optional) Display LSPs transiting this routing device. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


clear mpls Isp | 2263 
show mpls Isp autobandwidth | 2403 


List of Sample Output 

show mpls Isp defaults on page 2388 

show mpls Isp descriptions on page 2388 

show mpls Isp detail on page 2388 

show mpls Isp detail (When Egress Protection Is in Standby Mode) on page 2389 

show mpls Isp detail (When Egress Protection Is in Effect During a Local Repair) on page 2390 
show mpls Isp extensive on page 2391 


show mpls Isp ingress extensive on page 2393 
show mpls Isp extensive (automatic bandwidth adjustment enabled) on page 2394 
show mpls Isp bypass extensive on page 2395 


show mpls Isp p2mp on page 2396 
show mpls Isp p2mp detail on page 2396 


show mpls Isp detail count-active-routes on page 2397 


show mpls Isp statistics extensive on page 2398 


Output Fields 
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Table 60 on page 2378 describes the output fields for the show mpls Isp command. Output fields are listed 
in the approximate order in which they appear. 


Table 60: show mpls Isp Output Fields 


Field Name 


Ingress LSP 


Egress LSP 


Transit LSP 


P2MP name 


P2MP branch 
count 


address 


To 


From 


State 


Field Description 


Information about LSPs on the ingress routing device. Each session has 
one line of output. 


Information about the LSPs on the egress routing device. MPLS learns 
this information by querying RSVP, which holds all the transit and egress 
session information. Each session has one line of output. 

Number of LSPs on the transit routing devices and the state of these 
paths. MPLS learns this information by querying RSVP, which holds all 
the transit and egress session information. 

Name of the point-to-multipoint LSP. Dynamically generated P2MP LSPs 
used for VPLS flooding use dynamically generated P2MP LSP names. The 
name uses the format identifier:vpls:router-id:routing-instance-name. The 


identifier is automatically generated by Junos OS. 


Number of destination LSPs the point-to-multipoint LSP is transmitting 
to. 


An asterisk (*) under this heading indicates that the LSP is a primary path. 


(detail and extensive) Destination (egress routing device) of the LSP. 


Destination (egress routing device) of the session. 


Source (ingress routing device) of the session. 


State of the LSP handled by this RSVP session: Up, Dn (down), or Restart. 


Level of Output 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


detail extensive 


brief 


brief detail 


brief detail 


Table 60: show mpls Isp Output Fields (continued) 


Field Name 


Active Route 


Rt 


ActivePath 


LSPname 


Statistics 


Aggregate 
statistics 


Packets 


Bytes 


DiffServelnfo 


LSPtype 


Field Description 


Number of active routes (prefixes) installed in the forwarding table. For 
ingress LSPs, the forwarding table is the primary IPv4 table (inet.0). For 
transit and egress RSVP sessions, the forwarding table is the primary 
MPLS table (mpls.0). 


Number of active routes (prefixes) installed in the routing table. For ingress 
RSVP sessions, the routing table is the primary IPv4 table (inet.0). For 
transit and egress RSVP sessions, the routing table is the primary MPLS 
table (mpls.0). 


Path. An asterisk (*) underneath this column indicates that the LSP is a 
primary path. 


(Ingress LSP) Name of the active path: Primary or Secondary. 


Name of the LSP. 


Displays the number of packets and the number of bytes transmitted over 
the LSP. These counters are reset to zero whenever the LSP path is 
optimized (for example, during an automatic bandwidth allocation). 


Displays the number of packets and the number of bytes transmitted over 
the LSP. These counters continue to iterate even if the LSP path is 
optimized. You can reset these counters to zero using the clear mpls Isp 
statistics command. 


Displays the number of packets transmitted over the LSP. 


Displays the number of bytes transmitted over the LSP. 


Type of LSP: multiclass LSP (multiclass diffServ-TE LSP) or 
Differentiated-Services-aware traffic engineering LSP (diffServ-TE LSP). 


Type of LSP: 


e Static configured—Static 
e Dynamic configured—Dynamic 
e Externally controlled—External path computing entity 


Also indicates if the LSP is a Penultimate hop popping LSP or an Ultimate 
hop popping LSP. 
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Level of Output 


detail extensive 


brief 


brief 


detail extensive 


brief detail 


extensive 


extensive 


brief extensive 


brief extensive 


detail 


detail extensive 


Table 60: show mpls Isp Output Fields (continued) 


Field Name 


Bypass 


LSPpath 


Bidir 


Bidirectional 


FastReroute 
desired 


Link protection 
desired 


Node/Link 
protection 
desired 


LSP Control 
Status 


Field Description 


(Bypass LSP) Destination address (egress routing device) for the bypass 
LSP. 


Indicates whether the RSVP session is for the primary or secondary LSP 
path. LSPpath can be either primary or secondary and can be displayed 
on the ingress, egress, and transit routing devices. 


(GMPLS) The LSP allows data to travel in both directions between GMPLS 
devices. 


(GMPLS) The LSP allows data to travel both ways between GMPLS devices. 


Fast reroute has been requested by the ingress routing device. 


Link protection has been requested by the ingress routing device. 


Link protection has been requested by the ingress routing device. 


(Ingress LSP) LSP control mode: 


e External—By default, all PCE-controlled LSPs are under external control. 
When an LSP is under external control, the PCC uses the PCE-provided 
parameters to set up the LSP. 


e Local—A PCE-controlled LSP can come under local control. When the 
LSP switches from external control to local control, path computation 
is done using the CLI-configured parameters and constraint-based 
routing. Such a switchover happens only when there is a trigger to 
re-signal the LSP. Until then, the PCC uses the PCE-provided parameters 
to signal the PCE-controlled LSP, although the LSP remains under local 
control. 


A PCE-controlled LSP switches to local control from its default external 
control mode in cases such as no connectivity to a PCE or when a PCE 
returns delegation of LSPs back to the PCC. 
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Level of Output 


All levels 


detail 


All levels 


All levels 


detail 


detail 


detail 


extensive 


Table 60: show mpls Isp Output Fields (continued) 


Field Name 


External Path 
CSPF status 


Externally 
Computed ERO 


EXTCTRL_LSP 


flap counter 


LoadBalance 


Signal type 


Encoding type 


Switching type 


GPID 


Protection 


Upstream label in 


Upstream label 


out 


Suggested label 
received 


Field Description 


(PCE-controlled LSPs) Status of the PCE-controlled LSP with per path 
attributes: 


e Local 


e External 


(PCE-controlled LSPs) Externally computed explicit route when the route 
object is not null or empty. A series of hops, each with an address followed 
by a hop indicator. The value of the hop indicator can be strict (S) or loose 


(L). 


(PCE-controlled LSPs) Display path history including the bandwidth, 
priority, and metric values received from the external controller. 


Counts the number of times a LSP flaps down or up. 


(Ingress LSP) CSPF load-balancing rule that was configured to select the 
LSP's path among equal-cost paths: Most-fill, Least-fill, or Random. 


Signal type for GMPLS LSPs. The signal type determines the peak data 
rate for the LSP: DSO, DS3, STS-1, STM-1, or STM-4. 


LSP encoding type: Packet, Ethernet, PDH, SDH/SONET, Lambda, or 
Fiber. 


Type of switching on the links needed for the LSP: Fiber, Lamda, Packet, 
TDM, or PSC-1. 


Generalized Payload Identifier (identifier of the payload carried by an 
LSP): HDLC, Ethernet, IPv4, PPP, or Unknown. 


Configured protection capability desired for the LSP: Extra, Enhanced, 
none, One plus one, One to one, or Shared. 


(Bidirectional LSPs) Incoming label for reverse direction traffic for this 
LSP. 


(Bidirectional LSPs) Outgoing label for reverse direction traffic for this 
LSP. 


(Bidirectional LSPs) Label the upstream interface suggests to use in the 
Resv message that is sent. 


Level of Output 


extensive 


extensive 


extensive 


extensive 


detail extensive 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 
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Table 60: show mpls Isp Output Fields (continued) 


Field Name 


Suggested label 
sent 


Autobandwidth 


Mbb counter 


MinBW 


MaxBW 


Dynamic MinBW 


Dynamic MinBW 


AdjustTimer 


Adjustment 
Threshold 


Time for Next 


Adjustment 


Time of Last 
Adjustment 


MaxAvgBW util 


Overflow limit 


Overflow sample 
count 


Field Description 


(Bidirectional LSPs) Label the downstream node suggests to use in the 
Resv message that is returned. 


(Ingress LSP) The LSP is performing autobandwidth allocation. 


Counts the number of times a LSP incurs MBB. 


(Ingress LSP) Configured minimum value of the LSP, in bps. 


(Ingress LSP) Configured maximum value of the LSP, in bps. 


(Ingress LSP) Displays the current dynamically specified minimum 
bandwidth allocation for the LSP, in bps. 


(Ingress LSP) Displays the current dynamically specified minimum 
bandwidth allocation for the LSP, in bps. 


(Ingress LSP) Configured value for the adjust-timer statement, indicating 
the total amount of time allowed before bandwidth adjustment will take 


place, in seconds. 


(Ingress LSP) Configured value for the adjust-threshold statement. 
Specifies how sensitive the automatic bandwidth adjustment for an LSP 
is to changes in bandwidth utilization. 


(Ingress LSP) Time in seconds until the next automatic bandwidth 
adjustment sample is taken. 


(Ingress LSP) Date and time since the last automatic bandwidth adjustment 


was completed. 


(Ingress LSP) Current value of the actual maximum average bandwidth 


utilization, in bps. 


(Ingress LSP) Configured value of the threshold overflow limit. 


(Ingress LSP) Current value for the overflow sample count. 


Level of Output 


All levels 


detail extensive 


extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 
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Table 60: show mpls Isp Output Fields (continued) 


Field Name 
Bandwidth 
Adjustment in 
nnn second(s) 


Underflow limit 


Underflow 
sample count 


Underflow Max 


AvgBW 


Active path 
indicator 


Primary 


Secondary 


Standby 


State 


cos 


Bandwidth per 
class 


Priorities 


OptimizeTimer 


Field Description 


(Ingress LSP) Current value of the bandwidth adjustment timer, indicating 
the amount of time remaining until the bandwidth adjustment will take 


place, in seconds. 


(Ingress LSP) Configured value of the threshold underflow limit. 


(Ingress LSP) Current value for the underflow sample count. 


(Ingress LSP) The highest sample bandwidth among the underflow samples 
recorded currently. This is the signaling bandwidth if an adjustment occurs 
because of an underflow. 


(Ingress LSP) A value of * indicates that the path is active. The absence 
of * indicates that the path is not active. In the following example, “long” 
is the active path. 


*Primary long 
Standby short 


(Ingress LSP) Name of the primary path. 


(Ingress LSP) Name of the secondary path. 


(Ingress LSP) Name of the path in standby mode. 


(Ingress LSP) State of the path: Up or Dn (down). 


(Ingress LSP) Class-of-service value. 


(Ingress LSP) Active bandwidth for the LSP path for each MPLS class type, 
in bps. 


(Ingress LSP) Configured value of the setup priority and the hold priority 
respecitively (the setup priority is displayed first), where O is the highest 
priority and 7 is the lowest priority. If you have not explicitly configured 
these values, the default values are displayed (7 for the setup priority and 
O for the hold priority). 


(Ingress LSP) Configured value of the optimize timer, indicating the total 
amount of time allowed before path reoptimization, in seconds. 


Level of Output 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 
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Table 60: show mpls Isp Output Fields (continued) 


Field Name 


SmartOptimizeTimer 


Reoptimization in 
Xxx seconds 


Computed ERO 
(S [L] denotes 
strict [loose] 
hops) 


CSPF metric 


Field Description 


(Ingress LSP) Configured value of the smart optimize timer, indicating the 
total amount of time allowed before path reoptimization, in seconds. 


(Ingress LSP) Current value of the optimize timer, indicating the amount 
of time remaining until the path will be reoptimized, in seconds. 


(Ingress LSP) Computed explicit route. A series of hops, each with an 


address followed by a hop indicator. The value of the hop indicator can 
be strict (S) or loose (L). 


(Ingress LSP) Constrained Shortest Path First metric for this path. 
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Level of Output 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


Table 60: show mpls Isp Output Fields (continued) 


Field Name 


Received RRO 


Labels 


Index number 


Field Description 


(Ingress LSP) Received record route. A series of hops, each with an address 
followed by a flag. (In most cases, the received record route is the same 
as the computed explicit route. If Received RRO is different from 
Computed ERO, there is a topology change in the network, and the route 
is taking a detour.) The following flags identify the protection capability 
and status of the downstream node: 


e 0x01—Local protection available. The link downstream from this node 
is protected by a local repair mechanism. This flag can be set only if the 
Local protection flag was set in the SESSION_ATTRIBUTE object of 
the corresponding Path message. 


e 0x02—Local protection in use. A local repair mechanism is in use to 
maintain this tunnel (usually because of an outage of the link it was 
routed over previously). 

e 0x03—Combination of 0x01 and 0x02. 

e 0x04—Bandwidth protection. The downstream routing device has a 
backup path providing the same bandwidth guarantee as the protected 
LSP for the protected section. 

e 0x08—Node protection. The downstream routing device has a backup 
path providing protection against link and node failure on the 
corresponding path section. If the downstream routing device can set 
up only a link-protection backup path, the Local protection available 
bit is set but the Node protection bit is cleared. 

e 0x09—Detour is established. Combination of 0x01 and 0x08. 

e 0x10—Preemption pending. The preempting node sets this flag if a 
pending preemption is in progress for the traffic engine LSP. This flag 
indicates to the ingress legacy edge router (LER) of this LSP that it 
should be rerouted. 

e 0x20—Node ID. Indicates that the address specified in the RRO’s IPv4 
or IPv6 sub-object is a node ID address, which refers to the router 


address or router ID. Nodes must use the same address consistently. 


e Oxb—Detour is in use. Combination of 0x01, 0x02, and 0x08. 
Labels of pop-and-forward LSP tunnel: 


e P—Pop labels. 
e D—Delegation labels. 
(Ingress LSP) Log entry number of each LSP path event. The numbers are 


in chronological descending order, with a maximum of 50 index numbers 
displayed. 
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Level of Output 


detail extensive 


extensive 


extensive 


Table 60: show mpls Isp Output Fields (continued) 


Field Name 


Date 


Time 


Event 


Created 


Resv style 


Labelin 


Labelout 


LSPname 


Time left 


Since 


Tspec 


Port number 


PATH rcvfrom 


PATH sentto 


RESV rcvfrom 


Field Description 

(Ingress LSP) Date of the LSP event. 

(Ingress LSP) Time of the LSP event. 

(Ingress LSP) Description of the LSP event. 

(Ingress LSP) Date and time the LSP was created. 

(Bypass) RSVP reservation style. This field consists of two parts. The first 
is the number of active reservations. The second is the reservation style, 
which can be FF (fixed filter), SE (shared explicit), or WF (wildcard filter). 
Incoming label for this LSP. 

Outgoing label for this LSP. 

Name of the LSP. 

Number of seconds remaining in the lifetime of the reservation. 


Date and time when the RSVP session was initiated. 


Sender's traffic specification, which describes the sender's traffic 
parameters. 


Protocol ID and sender or receiver port used in this RSVP session. 


Address of the previous-hop (upstream) routing device or client, interface 
the neighbor used to reach this router, and number of packets received 


from the upstream neighbor. 


Address of the next-hop (downstream) routing device or client, interface 
used to reach this neighbor, and number of packets sent to the 
downstream routing device. 


Address of the previous-hop (upstream) routing device or client, interface 
the neighbor used to reach this routing device, and number of packets 
received from the upstream neighbor. The output in this field, which is 
consistent with that in the PATH rcvfrom field, indicates that the RSVP 
negotiation is complete. 


2386 


Level of Output 


extensive 


extensive 


extensive 


extensive 


brief detail extensive 


brief detail 


brief detail 


brief detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


Table 60: show mpls Isp Output Fields (continued) 


Field Name 


Record route 


Pop-and-forward 


ETLD In 


ETLD Out 


Delegation hop 


Soft preempt 


Soft preemption 
pending 


MPLS-TE LSP 
Defaults 


Field Description 


Recorded route for the session, taken from the record route object. 


Attributes of the pop-and-forward LSP tunnel. 


Number of transport labels that the LSP-Hop can potentially receive from 
its upstream hop. It is recorded as Effective Transport Label Depth (ETLD) 
at the transit and egress devices. 


Number of transport labels the LSP-Hop can potentially send to its 
downstream hop. It is recorded as ETLD at the transit and ingress devices. 


Specifies if the transit hop is selected as a delegation label: 


e Yes 


e No 


Number of soft preemptions that occurred on a path and when the last 
soft preemption occurred. Only successful soft preemptions are counted 
(those that actually resulted in a new path being used). 


Path is in the process of being soft preempted. This display is removed 
once the ingress router has calculated a new path. 


Default settings for MPLS traffic engineered LSPs: 


e LSP Holding Priority—Determines the degree to which an LSP holds 
on to its session reservation after the LSP has been set up successfully. 


e LSP Setup Priority—Determines whether a new LSP that preempts an 
existing LSP can be established. 


e Hop Limit—Specifies the maximum number of routers the LSP can 
traverse (including the ingress and egress). 


e Bandwidth—Specifies the bandwidth in bits per second for the LSP. 


e LSP Retry Timer—Length of time in seconds that the ingress router 
waits between attempts to establish the primary path. 


2387 


Level of Output 


detail 


extensive 


extensive 


extensive 


extensive 


detail 


detail 


defaults 


The XML tag name of the bandwidth tag under the auto-bandwidth tag has been updated to 
maximum-average-bandwidth . You can see the new tag when you issue the show mpls Isp extensive 


command with the | display xml pipe option. If you have any scripts that use the bandwidth tag, ensure 
that they are updated to maximum-average-bandwidth. 


| Sample Output 


show mpls Isp defaults 


user@host> show mpls Isp defaults 


MPLS-TE LSP Defaults 





LSP Holding Priority 0 

LSP Setup Priority 7 

Hop Limit 255) 
Bandwidth 0 

LSP Retry Timer 30 seconds 





show mpls Isp descriptions 


user@host> show mpls Isp descriptions 


Ingress LSP: 3 sessions 








To LSP name Description 

10 -0.0.195 to-sanjose to-sanjose-desc 
LO s0.0.,195 to-sanjose-other-desc other-desc 
Total 2 displayed, Up 2, Down 0 


show mpls Isp detail 


user@host> show mpls Isp detail 


Ingress LSP: 1 sessions 


192,168,044 
From: 192.168.0.5, State: Up, ActiveRoute: 0, LSPname: E-D 





ActivePath: (primary) 
LSPtype: Static Configured, Penultimate hop popping 
LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


+ 





Primary SieeicSe Wis) 

Priorities: 7 0 

SmartOptimizeTimer: 180 

Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 
10,0.0,18 S 10,0,0.,22 § 








Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPr 
20=Node-ID): 
10,.0.0,18 10.0,.0.282 
Total 1 displayed, Up 1, Down 0 
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Egress LSP: 1 sessions 


192 168,05 
From: 192.168.0.4, LSPstate: Up, ActiveRoute: 0 





LSPname: E-D, LSPpath: Primary 
Suggested label received: -, Suggested label sent: 








Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Time eities IS7, Saimeee Wee gull it 17sSseil2 2012 





Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 1 receiver 46128 protocol 0 
SyNnsl secwareomns IO ,0.0,18 (he-1/2/0.17) 38 joltes 
Adspec: received MTU 1500 








PATH sentto: localclient 





Rag wewareoms ilkoeaille livemic 
Record route: 10.0.0.22 10.0.0.18 <self> 





otal 1 displayed, Up 1, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


show mpls Isp detail (When Egress Protection Is in Standby Mode) 


user@host> show mpls Isp detail 


Ingress LSP: 1 sessions 


192 168.0 5% 
From: 192.168.0.5, State: Up, ActiveRoute: 0, LSPname: E-D 





ActivePath: (primary) 
LSPtype: Static Configured, Ultimate hop popping 
LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


= 





Primary Side m UO 

| =a oa oni 0) 

SmartOptimizeTimer: 180 

Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 

10.0.0,18 S 10,0.,0.,22 § 

Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID) : 
10.0.0.13 10.0.0.22 

11 Sep 20 15:54:35.032 Make-before-break: Switched to new instance 
10 Seo 20 Isgstes4 029 intacorme Rouces 10.0 ,0,18 10,.0,0.22 
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Sep 20) 15354:34.-029 Up 
Sep 20 15:54:20.271 Originate make-before-break call 
Scomz 052542082 IN CSPE cCompulcabrtons Lesulinnaccepteedy | NOOO nes On OnOn 27, 
Sep 20 15:52:10.247 Selected as active path 
SepeZU wa o2 7 Ue 24 oe RecondeRourcr On OR On Sm hOR On On22 
Sejo 20 ISs52¢10,245 ws 
Se pee Oman oO) Sew ome OrelceincliacmG cule: 
Séfo 20 lsss2cOO, 745 Sirens Genismesiciem mesulhe acecocecl 10,0,0.i18 10,0.0.22 
i Seo 2O Uscbilss9.90S Cie tagdiecs me mowmes coma 192. i168 ,0,4 
Created: Thu Sep 20 15:51:08 2012 
Total 1 displayed, Up 1, Down 0 





hel (Gs) Ss (onl ony Stee) WN) 





Egress LSP: 1 sessions 


192,168.05 
From: 192.168.0.4, LSPstate: Up, ActiveRoute: 0 





LSPname: E-D, LSPpath: Primary 
Suggested label received: -, Suggested label sent: 








Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Time left: 148, Since: Thu Sep 20 15:52:10 2012 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 1 receiver 49601 protocol 0 
Sans sowareoms IO,0.0,13 (he=l/2/0,17) 27 jokes 
Adspec: received MTU 1500 








PATH sentto: localclient 





RESV revfrom: localclient 
Record route: 10.0.0.22 10.0.0.18 <self> 





otal 1 displayed, Up 1, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


show mpls Isp detail (When Egress Protection Is in Effect During a Local Repair) 


user@host> show mpls Isp detail 


Ingress LSP: 1 sessions 


192,168.04 
From: 192.168.0.5, State: Up, ActiveRoute: 0, LSPname: 





lia) 
| 
le) 


ActivePath: (primary) 
LSPtype: Static Configured, Penultimate hop popping 





LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


+ 





Primary State: Up 
PAGO tints ee Sts a0) 


SmartOptimizeTimer: 180 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 
OR OM ORES Sarr r Ore ans 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID): 
10.0.0.18 10,.0,.0.42 
Total 1 displayed, Up 1, Down 0 





Egress LSP: 1 sessions 


192,168.05 
From: 192.168.0.4, LSPstate: Down, ActiveRoute: 0 





LSPname: E-D, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
dime eities I57, Saimeee Weel gull it 17sSseil2 2012 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 


Port number: sender 1 receiver 46128 protocol 0 





Egress protection PLR as protector: In Use 
DAW iewncicome 100,018 (ke=l/2/0,17) & polices 
Adspec: received MTU 1500 
PATH sentto: localclient 





RESV revfrom: localclient 
Record route: 10.0.0.22 10.0.0.18 <self> 
Total 1 displayed, Up 1, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


show mpls Isp extensive 


user@host> show mpls Isp extensive 


Ingress LSP: 1 sessions 


192,168.04 
From: 192.168.0.5, State: Up, ActiveRoute: 0, LSPname: E-D 





ActivePath: (primary) 
LSPtype: Static Configured, Ultimate hop popping 








LSP Control Status: Externally controlled 
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Metric: 


+ 








Primary 





LoadBalance: 


10 


Encoding type: 


Priorities: 


Random 


7 O 
External Path CSPF status: local 
Bandwidth: 
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Packet, Switching type: Packet, GPID: IPv4 


State: Up 


98.76kbps 


SmartOptimizeTimer: 180 


Include All: 
Externally Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 0) 


green 


leSosue S Gesinsee & 





20=Node-ID): 
OOP Ore CmelOR Or Ora 2 
9 May 17 16:55:06.574 EXTCTRL LSP: Sent Path computation request and LSP status 





Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 








8 May 17 16:55:06.574 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 98760 req BW 0 admin group(exclude 0 include any 0 include all 16) 
priority SStuo S lacie 4 Inegoss a2ZsSa2 2oSeda2z 

7 May 17 16:55:06.574 Selected as active path 

6 May 17 16:55:06.558 EXTCTRL LSP: Sent Path computation request and LSP status 





8 May 17 16:55:06.574 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 98760 req BW 0 admin group(exclude 0 include any 0 include all 16) 
priority Setue S agile 4“ Ingjose 142,.35.2 2.355352 

7 May 17 16:55:06.574 Selected as active path 

6 May 17 16:55:06.558 EXTCTRL LSP: Sent Path computation request and LSP status 





5 May 17 16:55:06.558 EXTCTRL_LSP: Computation request/lsp status contains: 





signalled bw 98760 req BW 0 admin group(exclude 0 include any 0 include all 16) 


priority setup 5 hold 


4 May 
3 May 
2 May 
1 May 


Ly 
7 
ala 
iy 


L@8 5S) 
1G 5 SS) 
1685S) 
LOE SS) 


MAO eA PHA CSO AeA 





Created: 


Tue May 


salons 
£06. 
FOG. 
706: 


Ly 


A Wnejos § sks Sak Bodedad 

557 Recowel IROWITSS Le2cSo2 2.So8o2 
B71 Wis 

382 Originate Call 





382 EXTCTRL_LSP: Received setup parameters :: local_cspf, 


IGESS307 AOS 


Total 1 displayed, Up 1, Down 0 





LEY 5 LOS} 410) 5 


imeoms 192, i168 .0.4, 


LSPname: 


CfeSss ISI 


D 


ih 





=D). 


1 sessions 


LSPstate: Up, ActiveRoute: 0 
LSPpath: Primary 
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Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 
Resv style: 1 FF, Label in: 3, Label out: - 
Time left: 148, Since: Thu Sep 20 15:52:10 2012 





[spec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 1 receiver 49601 protocol 0 
Snel sowareoms IO,0.0,13 (Ghe=l/2/0,17) 27 jokes 
Adspec: received MTU 1500 


PATH sentto: localclient 











RESV revfrom: localclient 
Record route: 10.0.0.22 10.0.0.18 <self> 





show mpls Isp ingress extensive 


user@host> show mpls Isp ingress extensive 


Ingress LSP: 1 sessions 


BOO 06H 
From: 10.0.0.1, State: Up, ActiveRoute: 0, LSPname: test 
ActivePath: (primary) 
LSPtype: Static Pop-and-forward Configured, Penultimate hop popping 
LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


+ 





Primary SiesieSe Wis) 

Piealoreiictess 7 (0) 

OptimizeTimer: 300 

SmartOptimizeTimer: 180 

Reoptimization in 240 second(s). 

Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 3) 

Lotvilee & 454.451 & BeSesus 

Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 

20=Node-ID): 











(Labels: P=Pop D=Delegation) 
80.1.1.2(Label=18 P) 50.1.1.2(Label=17 P) 70.1.1.2(Label=16 P) 
92.1.1.1(Label=16 D) 93.1.1.2(Label=16 P) 99.1.1.1(Label=16 P) 
99.2.1.1(Label=16 P) 99.3.1.2 (Label=3) 








17 Aug 3 13:17:33.601 CSPF: computation result ignored, new path less avail 
bw[3 times] 
16 Aug 3 13:02:51.283 CSPF: computation result ignored, new path no benefit [2 
times] 
15 Aug 3 12:54:36.678 Selected as active path 
14 og 3 I2e54e S36. 676 iInecowe Rowees Lol.d.2 4.4s4o1 5.92552 
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is Aue 3 IAs oHe 3G .676 Whe) 

12 Aug 3 12:54:33.924 Deselected as active 
II WAUG NS 2543359243 Originate Call 
LOMA GC esel2  54ts 92S elas Calli 


9 Aug 3 Ieeb4es3 923 CSieirs ConlsMtabLom maswllte aceeoceol Iail,ls2 &o.4.4.01 5s5.522 


CAC Ose odio SIA Ae ee NOR OEM TOWwa rma cs 
7 Aug 3 12:54:28.177 CSPF: computation result ignored, new path no benefit [4 


times] 
6 Aug 3 12:35:03.830 Selected as active path 
8 Aug 3 L29ssWS 928 Neeorwe INemEeSs B2o2,8.2 2035552 
AL ug OS) eS SSOS 827 Ue 
3 Aug 3° 12335:032814 Originate: Call 
2 moe 3 l2esocOs 814 CSPPe eoOlisuiretnoem cmesulle acecstecl 2,252.2 So3e3e2 
IAG SUZ 34 S42 CSREES Ealed nem EOulEcn GOwascluo ORO Onc 


Created: Tue Aug 3 12:34:35 2010 


Total 1 displayed, Up 1, Down 0 


show mpls Isp extensive (automatic bandwidth adjustment enabled) 


user@host> show mpls Isp extensive 


Ingress LSP: 1 sessions 


1925 Loe} 0,4 


+ 


al 


From: 192.168.0.5, State: Up, ActiveRoute: 0, LSPname: E-D 





ActivePath: (primary) 
Node/Link protection desired 


LSPtype: Static Configured, Penultimate hop popping 





LoadBalance: Random 

Autobandwidth 

MinBW: 300bps, MaxBW: 1000bps, Dynamic MinBW: 1000bps 
Adjustment Timer: 300 secs AdjustThreshold: 25% 

ax AvgBW util: 963.739bps, Bandwidth Adjustment in 0 second(s). 
in BW Adjust Interval: 1000, MinBW Adjust Threshold (in %): 50 


Overflow limit: 0, Overflow sample count: 0 





Underflow limit: 0, Underflow sample count: 9, Underflow Max AvgBW: 614.421bps 
Encoding type: Packet, Switching type: Packet, GPID: IPv4 





Primary State: Up 

Priemilriess 7 

Bandwidth: 1000bps 

SmartOptimizeTimer: 180 

Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 
O.0.0.18 S 10,0,0,.22 § 





IM O50. Ms (ikeloe l= 299) 7 


Created: 
Total 1 displayed, 








Cees ISS 
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Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID): 
192.168.0.6(flag=0x20) 10.0.0.18(Label=299792) 192.168.0.4(flag=0x20) 
10.0.0.22 (Label=3) 

if Mow S10) LOg25ei7/ 
iil Wor 310) IOs25s16 
10.0.0.18 (Label=299792) 192.168.0.4(flag=0x20) 10.0.0.22 (Label=3) 
1@ Aor 30 LTOS25 eis 


) owe 30) 20s 252116 
300 bps to 1000 bps 


SADE sO 
7 Apr 30 
@ Wow SiO) 
& Wore Si) 


4 Apr 30 
3 ore Si) 
2 Apr 30 
1 Apr 30 


Transit LSP: 


LOs2 
LOg 2 
LOs a 
LL) 9 al 


LL) g al 
L@g 1 
LOs 1 
L@g a 





Sed 
aed 
6:4 





6:4 
6:4 





6:42. 
6:14. 
Tue Apr 30 


5) 
5) 
2 
6:42. 
7 
2 
7 


Up 





.024 Make-before-break: Switched to new instance 
.023 Record Route: 192.168.0.6(flag=0x20) 


.023 Up 


.023 Automatic Autobw adjustment succeeded: BW changes from 





-946 Originate make-before-break call 

-946 CSPF: computation result accepted 10.0.0.18 10.0.0.22 
.891 Selected as active path 

891 Record Route: 192.168.0.6(flag=0x20) 

6) 192.168.0.4(flag=0x20) 10.0.0.22 (Label=3) 

-890 Up 

MOA Cm Oa cpbniciacme culm. 

828 CSPF: computation result accepted 10.0.0.18 10.0.0.22 
064 CSPF: could not determine self[2 times] 

IMgiSsio 2013 

1, Down 0 


0 sessions 


Total 0 displayed, Up 0, Down 0 


0 sessions 


Total 0 displayed, Up 0, Down 0 


show mpls Isp bypass extensive 


user@host # show mpls lsp bypass extensive 


LinGieSSS ISI’ 


Dato ots 


From: 





LSPname: 


LSPtype: 


1 sessions 


Wedel othe, 


LSPstate: Up, ActiveRoute: 0 
BYyOeSS—H1 eA ok 
Static Configured 





Suggested label received: -, Suggested label sent: 





Resv style: 


Ise ISH 8 





1 § 





rs 


Recovery label received: -, Recovery label sent: 300032 
, Label in: , Label out: 300032 








, Siimeas Wes Dee 8 IFsilGMeAs) LOIS 
[spec: rate Obps size Obps peak Infbps m 20 M 1500 











Port number: sender 1 receiver 55750 protocol 0 
Type: Bypass LSP 
Number of data route tunnel through: 1 
Number of RSVP session tunnel through: 0 
PATH rcevfrom: localclient 
Adspec: sent MTU 1500 
Path MTU: received 1500 
Qin sSemecos L,1.S5.2 (he-l/2/0.15) 1221 jokes 








Eogolletc mourees Is1.8.2 1.26551 
Record route: <self> 1.1.5.2 1.2.5.1 





F A ise «= 3} WS SILAS) INeoourel INomESe Ii. G.2 Uoeooe 
ar 3 Dee o as ilS)s aus) lof) 

ar 2 Dec 3 15:19:49 CSPF: computation result accepted 
+ il Dee 2 ISsil@eay OrriealingirSe Calli 


Total 1 displayed, Up 1, Down 0 


Egress LSP: 0 sessions 
Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 


show mpls Isp p2mp 


user@host> show mpls Isp p2mp 


Ingress LSP: 2 sessions 


P2MP name: p2mp-lspl, P2MP branch count: 1 














fe) From State Rt P ActivePath 
10 .255.245.51 10.255 6245 . 50 Up OR moat 
P2MP name: p2mp-lsp2, P2MP branch count: 1 

[To From State Rt P ActivePath 
10.255). 245, Sil 10.2555 245.. 50 Up 0 * pathl 


Total 2 displayed, Up 2, Down 0 


Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


show mpls Isp p2mp detail 


user@host> show mpls Isp p2mp detail 


RIG wewirwoms ds, 5.2 (ilie-1/2/0.15) 1221 jokics;, minicwopy llalxails No 


LSPname 


p2mp-branch-1 


LSPname 


AMPe Sees orals 
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Ingress LSP: 2 sessions 


P2MP name: p2mp-lspl, P2MP branch count: 1 


10-255 o245 45 
From: 10.255.245.50, State: Up, ActiveRoute: 0, LSPname: p2mp-branch-1 





ActivePath: pathl (primary) 
P2MP name: p2mp-lspl 
LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





*Primary pathl State: Up 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 25) 
192 168.208 .i17 & 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt) : 





192.168.5208 .17) 
P2MP name: p2mp-lsp2, P2MP branch count: 1 


10.255 .245 51 
From: 10.255.245.50, State: Up, ActiveRoute: 0, LSPname: p2mp-st-brl 
ActivePath: pathl (primary) 

P2MP name: p2mp-lsp2 

LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





*Primary pathl State: Up 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 25) 
192 (168,208.17 § 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt) : 





192,168,208 17) 
Total 2 displayed, Up 2, Down 0 


show mpls Isp detail count-active-routes 


user@host> show mpls Isp detail count-active-routes 


Ingress LSP: 1 sessions 


2S) WLS), WO 2 
From: 156.154.162.128, State: Up, ActiveRoute: 1, LSPname: to-lahore 
ActivePath: (primary) 

LSPtype: Static Configured 





LoadBalance: Random 
Autobandwidth 
MinBW: 5Mbps MaxBW: 250Mbps 
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AdjustTimer: 300 secs 
Max AvgBW util: Obps, Bandwidth Adjustment in 102 second(s). 
Overflow limit: 0, Overflow sample count: 0 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 


= 





Primary Stace: Ws 
Prile@milriess 7 
Bandwidth: 5Mbps 


SmartOptimizeTimer: 180 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 4) 
10.25250,L77 § 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID): 
10.252 .0.177) 
Total 1 displayed, Up 1, Down 0 








Egress LSP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit LSP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


show mpls Isp statistics extensive 


user@host> show mpls lsp statistics extensive 


Ingress LSP: 1 sessions 


192 , 168, 0,4 
From: 192.168.0.5, State: Up, ActiveRoute: 0, LSPname: 
Statistics: Packets 302, Bytes 28992 





lea 
| 
iw) 


Aggregate statistics: Packets 302, Bytes 28992 
ActivePath: (primary) 

LSPtype: Static Configured, Penultimate hop popping 
LoadBalance: Random 


Encoding type: Packet, Switching type: Packet, GPID: IPv4 





+ 


Primary Sitaces Wis) 
Prie@cilriess 7 


SmartOptimizeTimer: 180 





Computed ERO (S [L] denotes strict [loose] hops): (CSPF metric: 30) 
ROP OPORP Sm Sm On OM OneAymes 
Received RRO (ProtectionFlag 1=Available 2=InUse 4=B/W 8=Node 10=SoftPreempt 
20=Node-ID): 
IO .0.0,13 10.0.0.22 
6 Oct 3 11:18:28.281 Selected as active path 





5) 
4 
5 
2 


il 


Created: 


cir 
Ocir 
Ocir 
Oct 
Ocir 


deal 


WWW WwW Ww 


als 


ial ¢ 
amie 
alll 


gg 
g Altes 
Sg 
Ss 
alee 


Wed Oct 
Total 1 displayed, 


BS o 
28" 
Allo 
Al» 
59. 


Up 


SAL 
280 
O05 
995 
118 
ig 
1, 


Record Route: 


Up 


ROR ROR ORs Sams ORN OP Oker 212) 


Originate Call 
CSPF: Computation result accepted 10.0.0.18 10.0.0.22 


CSPF failed: 
LYSOL Z2Ql2 


Down 0 


no route toward 192.168.0.4[2 times] 
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| show mpls Isp abstract-computation 


Syntax 


show mpls Isp abstract-computation 
<brief | detail | extensive>; 
<logical-system (all | logical-system-name)>; 
<name Isp-name>; 


Release Information 
Command introduced in Junos OS Release 17.1 for all platforms. 


Description 

Display the ingress to egress abstract hop computation used by the constrained shortest path in the 
preprocessing for LSPs. The command output displays the various computation passes involved per LSP, 
and the qualifying exit devices for each pass. It also displays the affinity per pass, and the current start 
device chosen for the pass. 


Options 


brief | detail | extensive—(Optional) Display the desired level of output. 


logical-system (all | logical-system-name)—(Optional) Display the abstract computation for abstract hop 
constraints on all logical systems or on a particular logical system. 


Isp-name—(Optional) Name of the LSP for which the abstract hop computation is displayed. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


Example: Configuring Abstract Hops for MPLS LSPs | 442 
abstract-hop | 1696 
constituent-list | 1742 





show mpls abstract-hop-membership | 2330 


List of Sample Output 
show mpls Isp abstract-computation on page 2401 


Output Fields 


Table 61 on page 2401 describes the output fields for the show mpls Isp abstract-computation command. 
Output fields are listed in the approximate order in which they appear. 
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Table 61: show mpls Isp abstract-computation Output Fields 


Field Name 


Path computation using abstract hops for 
LSP 


Path type 

Path name 

Credibility 

Total no of CSPF passes 
CSPF pass no 

Start address of the pass 
Affinity 

Destination 


State 


| Sample Output 


show mpls Isp abstract-computation 


Field Description 


Name of the LSP for which the abstract hop computation is performed. 


The type of the path can be primary or secondary. 


Name of the path. 


Credibility value associated with the interior gateway protocol in use. 


Number of constrained shortest path passes for the abstract hop. 


Constrained shortest path pass number for the abstract hop computation. 


IP address where the pass starts. 


Name of the abstract hop. 


Destination IP address for a node in the pass. 


State of the backtracking: 


e Valid 
e Disqualified 


user@RO> show mpls Isp abstract-computation 


Path computation using abstract hops for LSP: RO-R31 


Path type: Primary, Path name: 


prim 


Credibility: 0, Total no of CSPF passes: 2 


CSR RMP cls sme anO) 


Start address of the pass: 127.0.0.6 


DeSseainaicaoms 127 ,.0,0.1, Sreaices 
DS Sieelnicitesle@ mile Orl Ones mote citecrs 
Desitalniciestom a le2 Or Omormoieciteer 
AGE anitya all 


VALID 
VALID 





VALID 


COREE Pasism lol 


Start address of the pass: 


Destination: 
Path type: Se 
Path type: St 
Credibility: 
COPE pasis enol 
Start address 
Destination: 
Destination: 
Affinity: ah2 
CORE Pelsis enol 
Sivas addreisis 


Destination: 


‘iL 


er Or 


condary, 


3, 


Path name: 


State: 


andby, Path name: 


0, Total no of CSPF passes: 


0 

of the 
127 0.0. 
127.00. 


il 
of the 
127 oOo. 


pass: 


3, 
4, 


pass: 


3, 


State: 
State: 


State: 


127 6OoOot 


VALID 


nonstdby 


stdby 


VAI 


127 60.0.6 


LID 





VAI 


LID 


L276 O 0054 


VALID 


2 
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| show mpls Isp autobandwidth 


Syntax 


show mpls Isp autobandwidth 
<brief | detail | extensive> 
<logical-system (all | logical-system-name)> 


<name Isp-name> 


Release Information 

Statement introduced in Junos OS Release 11.4. 

Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 
Statement introduced in Junos OS Release 15.1X54-D60 for the ACX5000 Series. 
Statement introduced in Junos OS Release 17.2R1 for QFX10000 Series switches. 
namelsp-name option introduced in Junos OS Release 18.1R1 for all platforms. 


Description 


Display automatic bandwidth information for the LSP(s). 


After a Routing Engine switchover, the output of the show mpls autobandwidth command might not be 
up-to-date, as the automatic bandwidth information for the LSP(s) is gathered by the new master Routing 
Engine during the first adjustment interval. 


Options 
brief | detail | extensive —(Optional) Display the specified level of output. The extensive option displays 
the same information as the detail option, but covers the most recent 50 events. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


name Isp-name—(Optional) Specify name of the LSP for which the automatic bandwidth information should 
be displayed. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


show mpls Isp | 2374 
Achieving a Make-Before-Break, Hitless Switchover for LSPs | 508 


List of Sample Output 
show mpls Isp autobandwidth on page 2405 


Output Fields 


Table 62 on page 2404 describes the output fields for the show mpls Isp autobandwidth command. Output 


fields are listed in the approximate order in which they appear. 


Table 62: show mpls Isp autobandwidth Output Fields 


Field Name 


To 


From 


LSPname 


Min BW 


Max BW 


Max AvgBW util 


Overflow limit 


Overflow sample 
count 


Underflow limit 


Underflow 
sample count 


Adjustment 


Timer 


Adjustment 
Threshold 


Time for Next 
Adjustment 


Field Description 


Destination (egress routing device) of the session. 


Source (ingress routing device) of the session. 


Name of the LSP. 


(Ingress LSP) Configured minimum value of the LSP, in bps. 


(Ingress LSP) Configured maximum value of the LSP, in bps. 


(Ingress LSP) Current value of the actual maximum average bandwidth 
utilization, in bps. 


NOTE: Incalculating this value, the sample collected during make before 
break (MBB) is ignored to prevent inaccurate results. The first sample 
after a bandwidth adjustment, or after a change in the LSP ID (regardless 
of path change), is also ignored. 


(Ingress LSP) Configured value of the threshold overflow limit. 


(Ingress LSP) Current value for the overflow sample count. 


(Ingress LSP) Configured value of the threshold underflow limit. 


(Ingress LSP) Current value for the underflow sample count. 


(Ingress LSP) Configured value for the adjust-timer statement, indicating 
the total amount of time allowed before bandwidth adjustment will take 
place, in seconds. 


(Ingress LSP) Configured value for the adjust-threshold statement. Specifies 
how sensitive the automatic bandwidth adjustment for an LSP is to 
changes in bandwidth utilization. 


(Ingress LSP) Time in seconds until the next automatic bandwidth 
adjustment sample is taken. 


Level of Output 


All Levels 


All Levels 


All Levels 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


Table 62: show mpls Isp autobandwidth Output Fields (continued) 


Field Name Field Description Level of Output 
Time of Last (Ingress LSP) Date and time since the last automatic bandwidth adjustment | detail extensive 
Adjustment was completed. 

Last BW Previous active bandwidth of the LSP. detail extensive 
Last Requested Bandwidth requested in the previous automatic bandwidth adjustment. | detail extensive 
BW 

Last Signaled BW = Bandwidth signaled in the previous automatic bandwidth adjustment. detail extensive 
Highest Maximum bandwidth used by the LSP. detail extensive 
Watermark BW 


Total AutoBw 


Total number of attempts to adjust automatic bandwidth including failed 


detail extensive 


Adjustments and successful adjustments. 

Successful Number of successful automatic bandwidth adjustments. detail extensive 
Adjustments 

Failed Number of failed automatic bandwidth adjustments. detail extensive 
Adjustments 
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| Sample Output 


show mpls Isp autobandwidth 


user@host> show mpls Isp autobandwidth extensive 


Tos 10.255. 106,133, 
10 .255,.106. 135, 
100kbps, Max BW: 


eae i 
Obps, Max AvgBW util: 


From: LSPname: 


Min BW: 2.33249Mbps 
Overflow limit: 0, Overflow sample count: 0 
Underflow limit: 0, Underflow sample count: 0 


Adjustment Timer: 300 sec, Adjustment Threshold: 0 


Time for Next Adjustment: 23 sec, Time of Last Adjustment: Fri Jun 3 21:05:37 
2011 
Last BW: 100kbps, Last Requested BW: 2.2169Mbps, Last Signaled BW: 2.2169Mbps, 


Highest Watermark BW: 2.33249Mbps 


Total AutoBw Adjustments: 1, Successful Adjustments: 1, Failed Adjustments: 0 
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| show mpls path 


List of Syntax 
Syntax on page 2406 
Syntax (EX Series Switches) on page 2406 


Syntax 


show mpls path 

<instance instance-name> 

<logical-system (all | logical-system-name)> 
<path-name> 


Syntax (EX Series Switches) 


show mpls path 
<path-name> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
instance instance-name option added in Junos OS Release 15.1. 


Description 
Display dynamic Multiprotocol Label Switching (MPLS) label-switched paths (LSPs). 


Options 
none—Display standard information about all MPLS LSPs. 


instance instance-name—(Optional) Display the dynamic MPLS LSP for the specified instance. If 
instance-name is omitted, dynamic MPLS LSP for the master instance is displayed. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


path-name—(Optional) Display information about the specified LSP only. 


Required Privilege Level 
view 


List of Sample Output 
show mpls path on page 2407 


Output Fields 
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Table 63 on page 2407 describes the output fields for the show mpls path command. Output fields are listed 
in the approximate order in which they appear. 


Table 63: show mpls path Output Fields 


Field Name Field Description 

Path name Information about ingress LSPs. Each path has one line of 
output. 

Address Addresses of the routing devices that form the LSP. 

Strict/loose address Whether the address is a configured as a strict or loose address. 


| Sample Output 


show mpls path 


user@host> show mpls path 


Path name Address Strict/loose address 
foul 123,456.55 26 Sie wie 
L2S) 456, 1.6 Loose 


p2 191.456.1.4 Strict 
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| show mpls srlg 


Syntax 


show mpls srlg 
<logical-systems (all | logical-system-name)> 


Release Information 
Command introduced before Junos OS Release 11.4. 


Description 


Display Shared Risk Link Group (SRLG) cost and value configuration information. 


NOTE: If an SRLG is associated with a link that is used by an ingress LSP in the router, then on 
deleting the SRLG configuration from that router, the SRLG gets removed from the SRLG table 
only on the next reoptimization of the LSP. Until then, the output of the run show mpls srlg 
command displays Unknown-XXxX instead of the SRLG name and a non zero srlg-cost for that 
SRLG. 


Options 
logical-system (all | logical-system-name)—(Optional) View SRLG configuration information for all logical 
systems or a particular logical system. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


Example: Configuring SRLG | 201 


Output Fields 


Table 64 on page 2408 lists the output fields for the show mpls srlg command. Output fields are listed in the 
approximate order in which they appear. 


Table 64: show mpls srlg Output Fields 


Field Name Field Description 


SRLG Name of the SRLG. 
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Table 64: show mpls srlg Output Fields (continued) 


Field Name Field Description 
Value A group ID for the SRLG ranging from 1 through 4294967295. 
Cost A cost for the Shared Risk Link Group (SRLG) ranging from 1 through 65535. 


| Sample Output 


user@host> show mpls srlg 


SRLG Value Cosie 
Susie IH O)AL 10 
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| show mpls static-Isp 


Syntax 


show mpls static-Isp 

<brief | detail | extensive | terse> 
<bypass> 

<descriptions> 

<down | up> 

<ingress> 

<instance instance-name> 
<logical-system (all | logical-system-name)> 
<Isp-type> 

<name name> 

<statistics> 

<transit> 


Release Information 

Command introduced in Junos OS Release 10.1. 

Command updated in Junos OS Release 14.1X53-D25 to accommodate the stitching feature of MPLS. 
Statement introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Statement introduced in Junos OS Release 14.1X53-D30 for QFX Virtual Chassis and Virtual Chassis 
Fabric. 


Description 
Display information about configured and active static Multiprotocol Label Switching (MPLS) label-switched 
paths (LSPs). 


Options 


none—Display standard information about all configured and active static MPLS LSPs. 


brief | detail | extensive | terse—(Optional) Display the specified level of output. The extensive option 
displays the same information as the detail option, but covers the most recent 50 events. 


bypass—(Optional) Display LSPs used for protecting other static LSPs. 


descriptions—(Optional) Display the MPLS static LSP descriptions. To view this information, you must 
configure the description statement at the [edit protocols mpls static-label-switched-path path-name 
bypass], [edit protocols mpls static-label-switched-path path-name ingress], or [edit protocols mpls 
static-label-switched-path path-name transit incoming-label] hierarchy levels. Only static LSPs with a 
description are displayed. 


down | up—(Optional) Display only static LSPs that are inactive or active, respectively. 
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instance instance-name—(Optional) Display information about all configured and active static MPLS LSPs 
for the specified routing instance. If instance-name is omitted, information about all configured and 
active static MPLS LSPs for the master instance is displayed. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Isp-type—(Optional) Display information about a particular LSP type: 


e bypass—Sessions for bypass LSPs. 
e ingress—Sessions that originate from this routing device. 


e transit—Sessions that pass through this routing device. 


name name—(Optional) Display information about the specified static LSP or group of LSPs. 
statistics—(Optional) Display accounting information about static LSPs. 


transit—(Optional) Display static LSPs transiting this routing device. 


Required Privilege Level 
view 


List of Sample Output 

show mpls static-Ilsp extensive on page 2412 

show mpls static-Isp statistics ingress on page 2413 

show mpls static-Isp (when MPLS stitching is used) on page 2413 


Output Fields 


Table 50 on page 2340 describes the output fields for the show mpls static-Isp command. Output fields are 
listed in the approximate order in which they appear. 


Table 65: show mpls static-Isp Output Fields 


Field Name Field Description Level of Output 


Ingress LSPs Information about the static LSPs on the ingress routing device. Each All levels 
session has one line of output. 


Transit LSPs Number of static LSPs on the transit routing devices and the state of these All levels 
paths. MPLS learns this information by querying RSVP, which holds all 


the transit and egress session information. 


Bypass LSPs Information about the bypass LSPs configured on the routing device. Each | All levels 


session has one line of output. 


LSPname Name of the static LSP. All levels 


Table 65: show mpls static-Isp Output Fields (continued) 
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Field Name Field Description Level of Output 
To Destination (egress routing device) of the session. All levels 

State State of the static LSP handled by this RSVP session: Up, Dn (down), or — All levels 

Restart. 

Packets Number of packet transiting the static LSP (statistics option only). All levels 

Bytes Number of bytes transiting the static LSP (statistics option only). All levels 
Nexthop IP address for the next-hop router for the static LSP. detail, extensive 
Bypass (Bypass LSP) Destination address (egress routing device) for the bypass | All levels 


Link protection 
desired 


LabelOperation 


Outgoing-label 


LSP. 


Link protection has been requested by the ingress routing device. 


Label operation to perform: Push, Pop, Swap. 


Outgoing label to use for the MPLS packet in either push or swap label 
operations. 


detail, extensive 


detail, extensive 


detail, extensive 


Created (Ingress LSP) Date and time the static LSP was created. extensive 
Bandwidth Bandwidth configured for the static LSP. detail, extensive 
Resv style (Bypass) RSVP reservation style. This field consists of two parts: the All levels 


number of active reservations and the reservation style, which can be FF 
(fixed filter), SE (shared explicit), or WF (wildcard filter). 


| Sample Output 


show mpls static-Isp extensive 


user@host> show mpls static-Ilsp extensive 


Ingresiss HSPs: 


LSPname: alpha-to-beta, To: 192.168.14.1 


State: Dn 


iNepaelareyss ILS)2 5 ANG) 5 ILO). aL 


LabelOperation: Push, Outgoing-label: 1000001 
Created: Thu Jan 14 16:44:43 2010 
Bandwidth: 0 bps 

Total 1, displayed 1, Up 0, Down 1 


Transit LSPs: 





Total 0, displayed 0, Up 0, Down 0 


Bypals sees bist. 
Total 0, displayed 0, Up 0, Down 0 


show mpls static-Isp statistics ingress 


user@host> show mpls static-Isp statistics ingress 


iMG isSsisy IVS s/s 


LSPname ho) State Packets Bytes 
alpha-to-beta ISVS 5 SIS}, EL AL Dn NA NA 
Total 1, displayed 1, Up 0, Down 1 


show mpls static-Isp (when MPLS stitching is used) 


The show mpls static-lsp command was extended in Junos release 14.1X53-D25 to accommodate the 
stitching feature of MPLS. This example shows the LSP state as 'InProgress' because the LSP is waiting 
for protocol next-hop resolution. For more information, see 


user@host> show mpls static-Isp 


INS SSSis} ISIS) 8 


Total 0, displayed 0, Up 0, Down 0 








Transit LSPs: LSPname Incoming-label State 


icO=— 165 1000000 InProgress 
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| show performance-monitoring mpls Isp 


Syntax 


show performance-monitoring mpls Isp 
<brief | detail | extensive> 
<name Isp name> 


Release Information 
Command introduced in Junos OS Release 15.1. 


Description 


Display the following performance monitoring data: 


e Packet loss measurement 

e Packet throughput measurement 
e Two-way channel delay 

e Round-trip delay 


e Inter-packet delay variation (IPDV) 


Options 


none—Display standard information performance monitoring data. 


brief | detail | extensive—(Optional) Display the specified level of output. 


NOTE: The extensive option displays the same information as the detail option. 


name Isp name—(Optional) Display information about the specified LSP. 


Required Privilege Level 
View 


RELATED DOCUMENTATION 


clear performance-monitoring mpls Isp | 2267 


performance-monitoring (Protocols MPLS) | 1893 


List of Sample Output 
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show performance-monitoring mpls Isp on page 2418 
show performance-monitoring mpls Isp detail on page 2419 


Output Fields 
Table 66 on page 2415 describes the output fields for the show performance-monitoring mpls Isp command. 
Output fields are listed in the approximate order in which they appear. 


Table 66: show performance-monitoring mpls Isp Output Fields 


Field Name Display Data Field Description Level of Output 


Session Total Total number of performance All Levels 
monitoring sessions created. 


Up Number of performance All Levels 
monitoring sessions that are up 
and running. 

Down Number of performance All Levels 


monitoring sessions that are 
down. 


LSP name Name of the LSP. All Levels 


Table 66: show performance-monitoring mpls Isp Output Fields (continued) 


Field Name 


Loss measurement 
Data 


Display Data 


Traffic-class 


Queries sent 


Responses received 


Responses dropped due to errors 


Queries timeout 


Forward loss Average packet 


measurement loss 


Average packet 


throughput 
Reverse loss Average packet 
measurement loss 


Average packet 
throughput 


Field Description 


Traffic class for which loss 
measurement is performed. 


Total number of queries sent for 
loss measurement. 


Total number of responses 
received for loss measurement 
queries. 


Total number of loss 
measurement responses dropped 
due to errors. 


Number of timed out queries sent 
for loss measurement. 


Average packet loss (total loss of 
packets divided by the total 
number of samples used since the 
session is up). 


Total number of packets sent 
divided by the time considered 
for measurement. 


Average packet loss (total loss of 
packets divided by the total 
number of samples used since the 
session is up). 


Total number of packets sent 
divided by the time considered 
for measurement. 
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Level of Output 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


Table 66: show performance-monitoring mpls Isp Output Fields (continued) 


Field Name 


Delay measurement 
Data 


Display Data 


Traffic-class 


Queries sent 


Responses received 


Responses dropped due to errors 


Queries timeout 


Best 2-way channel delay 


Worst 2-way channel delay 


Best round trip time 


Worst round trip time 


Avg absolute fw delay variation 


Avg absolute rv delay variation 


Two-way channel delay 


Two-way round trip delay 


Field Description 


Traffic class for which delay 
measurement is performed. 


Total number of queries sent for 
delay measurement. 


Total number of responses 
received for delay measurement 
queries. 


Total number of delay 
measurement responses dropped 


due to errors. 


Number of timed out queries sent 
for delay measurement. 


Best available two-way channel 
delay. 


Worst available two-way channel 
delay. 


Best available round-trip time. 


Worst available round-trip time. 


Average of the variation in 
forward delay. 


Average of the variation in 
reverse delay. 


Sum of packet delays, excluding 
the processing time of the remote 
provider edge (PE) router. 


Total time taken for completing 
round-trip of packet. 
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Level of Output 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


detail, extensive 


detail, extensive 


| Sample Output 


show performance-monitoring mpls Isp 


user@host> show performance-monitoring mpls Isp 


Session Total: 3 Up: 3 Down: 0 


ESP 


name:to_bad, PM State:Up 


Loss measurement Data: 


ESP 


ESP 


Diieatesomem OOO 4e243) 
Traffic-class: None 


Queries sent: 282 





Responses received: 282 
Responses dropped due to errors: 0 
Queries timeout: 0 
Forward loss measurement: 

Average packet loss: 0 

Average packet throughput: 554338 
Reverse loss measurement: 

Average packet loss: 0 

Average packet throughput: 1352077 
name:to_bad, PM State:Up 





lay measurement Data: 
Duration: 00:04:43 
Migeueicee—Cllesisy¢ (0 
Queries sent: 282 


Responses received: 282 





Responses dropped due to errors: 0 

Queries timeout: 0 

Best 2-way channel delay: 72 usecs 

Worst 2-way channel delay: 365 usecs 

Best round trip time: 843 usecs 

Worst round trip time: 105523 usecs 

Avg absolute fw delay variation: 1619 usecs 
Avg absolute rv delay variation: 1619 usecs 


name:to_bad, PM State:Up 


Loss measurement Data: 


Duration: 00:04:43 
irate classe NOme 
Queries sent: 282 


Responses received: 282 





Responses dropped due to errors: 0 
Queries timeout: 0 
Forward loss measurement: 


Average packet loss: 0 
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Average packet throughput: 553927 
Reverse loss measurement: 

Average packet loss: 0 

Average packet throughput: 1351531 


Delay measurement Data: 





Best 2-way channel delay: 76 usecs 

Worst 2-way channel delay: 368 usecs 

Best round trip time: 1082 usecs 

Worst round trip time: 126146 usecs 

Avg absolute fw delay variation: 1618 usecs 


Avg absolute rv delay variation: 1619 usecs 


show performance-monitoring mpls Isp detail 


user@host> show performance-monitoring mpls Isp detail 


Se SSHhOnmell oe cll: rom On mmomD OwinemnO 
LSP name:to_bad, PM State:Up 
he Sismmcasuiaeme miteae citecles 
Duration: 00:04:53 
Traffic-class: None 


Queries sent: 292 





Responses received: 292 
Responses dropped due to errors: 0 
Queries timeout: 0 
Forward loss measurement: 
Average packet loss: 0 
Average packet throughput: 554486 
Packet loss samples: 
00000000 00000000 00000000 00000000 00000000 
Packet throughput samples: 
OOSSA002 O0557550 OOS57/717 O0OS53S22 OOSST107 
Reverse loss measurement: 
Average packet loss: 0 
Average packet throughput: 1352406 
Packet loss samples: 
00000000 00000000 00000000 00000000 00000000 
Packet throughput samples: 
OMS SOS SM ONES CoO ACOs 5S 97 CMO SiO Aol aewieS 
LSP name:to_bad, PM State:Up 





Delay measurement Data: 
Duration: 00:04:53 
Tearric-Glasss © 


Queries sent: 292 
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Responses received: 292 

Responses dropped due to errors: 0 

Queries timeout: 0 

Best 2-way channel delay: 72 usecs 

Worst 2-way channel delay: 365 usecs 

Best round trip time: 843 usecs 

WoreSiemerOlUn GlntealpmEelniCE mE EO oo om useless 

Avg absolute fw delay variation: 1683 usecs 
Avg absolute rv delay variation: 1684 usecs 
Two-way channel delay: 


73 usecs 73 usecs 73 usecs 73 usecs 72 usecs 





Two-way round trip delay: 
U2 7 USC CSm7 7S mUSCCS moc MUS CC smal tenuis Cc Comma mUSC eS 
LSP name:to_bad, PM State:Up 
ih@Ssiciem Cals Use me mite citecls. 
Duration: 00:04:53 
Traffic-class: None 
Queries sent: 292 


Responses received: 292 





Responses dropped due to errors: 0 
Queries timeout: 0 
Forward loss measurement: 
Average packet loss: 0 
Average packet throughput: 554089 
Packet loss samples: 
00000000 00000000 00000000 00000000 00000000 
Packet throughput samples: 
00554007 00557548 00557713 00558547 00557385 
Reverse loss measurement: 
Average packet loss: 0 
Average packet throughput: 1351914 
Packet loss samples: 
00000000 00000000 00000000 00000000 00000000 
Packet throughput samples: 
01358923 01352980 01362436 01223841 01496977 


Delay measurement Data: 





Best 2-way channel delay: 76 usecs 

Worst 2-way channel delay: 368 usecs 

Best round trip time: 1082 usecs 

Worst round trip time: 126146 usecs 

Avg absolute fw delay variation: 1682 usecs 

Avg absolute rv delay variation: 1683 usecs 
Two-way channel delay: 


76 usecs 76 usecs 76 usecs 77 usecs 77 usecs 
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Two-way round trip delay: 
107496 usecs 102369 usecs 104048 usecs 1433 usecs 103306 usecs 
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| show route forwarding-table 


Syntax 


show route forwarding-table 
<detail | extensive | summary> 
<ccc ccc-interface-name> 
<destination> 

<family family-name> 

<label label> 

<matching ip_prefix> 
<multicast> 

<vpn vpn> 


Release Information 

Command introduced in Junos OS Release 9.5 for EX Series switches. 

Command introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 

Command introduced in Junos OS Release 14.1X53-D30 for QFX Virtual Chassis and Virtual Chassis 
Fabric. 


Description 

Display the Routing Engine's forwarding table, including the network-layer prefixes and their next hops. 
This command is used to help verify that the routing protocol process has relayed the correction information 
to the forwarding table. The Routing Engine constructs and maintains one or more routing tables. From 
the routing tables, the Routing Engine derives a table of active routes, called the forwarding table. 


Options 


none—Display the routes in the forwarding table. 

detail | extensive | summary—(Optional) Display the specified level of output. 

ccc—(Optional) Display the specified circuit cross-connect interface name for entries to match. 
destination—(Optional) Display the destination prefix. 


family family-name—(Optional) Display routing table entries for the specified family: ethernet-switching, 
inet, inet6, iso, mpls, vlan classification. 


label label—(Optional) Display route entries for the specified label name. 
matching ip_prefix—(Optional) Display route entries for the specified IP prefix. 
multicast—(Optional) Display route entries for multicast routes. 


vpn vpn—(Optional) Display route entries for the specified VPN. 
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Required Privilege Level 
view 


RELATED DOCUMENTATION 


Example: Configuring MPLS on EX8200 and EX4500 Switches | 42 
Configuring MPLS on EX8200 and EX4500 Provider Switches | 78 


List of Sample Output 

show route forwarding-table on page 2426 

show route forwarding-table summary on page 2427 
show route forwarding-table extensive on page 2427 
show route forwarding-table ccc on page 2429 

show route forwarding-table family (MPLS) on page 2429 
show route forwarding-table family (IPv6) on page 2430 
show route forwarding-table label on page 2431 

show route forwarding-table matching on page 2431 
show route forwarding-table multicast on page 2431 


Output Fields 

Table 67 on page 2423 lists the output fields for the show route forwarding-table command. Output fields 
are listed in the approximate order in which they appear. Field names might be abbreviated (as shown in 
parentheses) when no level of output is specified or when the detail keyword is used instead of the 
extensive keyword. 


Table 67: show route forwarding-table Output Fields 


Field Name Field Description Level of Output 
Routing table Name of the routing table (for example, inet, inet6, mpls). All levels 
Address family Address family (for example, IP, IPv6, ISO, MPLS). All levels 


Destination Destination of the route. detail, extensive 
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Table 67: show route forwarding-table Output Fields (continued) 


Field Name 


Route Type 
(Type) 


Route reference 
(RtRef) 


Flags 


Nexthop 


Field Description Level of Output 


How the route was placed into the forwarding table. When the detail All levels 
keyword is used, the route type might be abbreviated (as shown in 
parentheses): 


e cloned (clon)—(TCP or multicast only) Cloned route. 


e destination (dest)—Remote addresses directly reachable through an 
interface. 


e destination down (iddn)—Destination route for which the interface is 
unreachable. 


e interface cloned (ifcl)—Cloned route for which the interface is 
unreachable. 


e route down (ifdn)—Interface route for which the interface is 
unreachable. 


e ignore (ignr)—Ignore this route. 
e interface (intf)—Installed as a result of configuring an interface. 


e permanent (perm)—Routes installed by the kernel when the routing 
table is initialized. 


e user—Routes installed by the routing protocol process or as a result of 
the configuration. 


Number of routes to reference. detail, extensive 


Route type flags: extensive 


e none—No flags are enabled. 

e accounting—Route has accounting enabled. 

e cached—Cache route. 

e incoming-iface interface-number —Check against incoming interface. 
e prefix load balance—Load balancing is enabled for this prefix. 

e sent to PFE—Route has been sent to the Packet Forwarding Engine. 


e static—Static route. 


IP address of the next hop to the destination. detail, extensive 


Table 67: show route forwarding-table Output Fields (continued) 


Field Name 


Next hop type 
(Type) 


Index 


Route 
interface-index 


Reference 
(NhRef) 


Next-hop 
interface (Netif) 


Alternate 
forward nh index 


Next-hop L3 
Interface 


Field Description 


Next-hop type. When the detail keyword is used, the next-hop type might 
be abbreviated (as indicated in parentheses): 


e broadcast (bcst)—Broadcast. 

e deny—Deny. 

e hold—Next hop is waiting to be resolved into a unicast or multicast 
type. 

e indexed (idxd)—Indexed next hop. 

e indirect (indr)—Indirect next hop. 

e local (locl)—Local address on an interface. 

e routed multicast (mcrt)—Regular multicast next hop 

e multicast (mcst)—Wire multicast next hop (limited to the LAN). 

e multicast discard (mdsc)—Multicast discard. 

e multicast group (mgrp) —Multicast group member. 

e receive (recv)—Receive. 

e reject (rjct)—Discard. An ICMP unreachable message was sent. 

e resolve (rslv)—Resolving the next hop. 

e unicast (ucst)—Unicast. 


e unilist (ulst)—List of unicast next hops. A packet sent to this next hop 
goes to any next hop in the list. 


Software index of the next hop that is used to route the traffic for a given 
prefix. 


Logical interface index from which the route is learned. For example, for 
interface routes, this is the logical interface index of the route itself. For 
static routes, this field is zero. For routes learned through routing 

protocols, this is the logical interface index from which the route is learned. 


Number of routes that refer to this next hop. 


Interface used to reach the next hop. 


Index number of the alternate next hop interface. Seen with multicast 
option only. 


The next hop layer 3 interface. This option can be expressed as a VLAN 
name and is only seen with the multicast option. 
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Level of Output 


detail, extensive 


detail, extensive 
none 


extensive 


none detail, 
extensive 


none detail, 
extensive 


extensive 


extensive 


Table 67: show route forwarding-table Output Fields (continued) 


Field Name 


Next-hop L2 


Interfaces 


| Sample Output 


Field Description 


The next hop layer 2 interfaces. Seen with multicast option only. 


show route forwarding-table 


user@switch> show route forwarding-table 


Routing table: 


Internet: 


Destination 
default 
default 
0/32 
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hsieue 


perm 


perm 


abraitert= 


des 


des 


SLigue ie 


des 


des 


Eibraite sta 


des 


starters 


des 
des 


des 





WSs 


Use 


SLIgNe ie 
user 


eibraite d= 


des 


aibraite ta 


des 


dest 


des 





aL shin 


default.inet 


RtRef 
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Level of Output 


extensive 





Typ 
Ucse 
eee 
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ieSly 
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uUcSseE 
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korea 
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14. 
14. 
14. 
14. 
14. 


oe 
ee 
BD 
AS) 


14. 
14. 
14. 
14. 
14. 
Agile 
4.0. 
4.0. 
Bo45 


14. 


14 


14. 
14. 
14. 


0732 iddn 
sO BZ user 
2/32 aLiaue 3 
BY XE iddn 
2S) // 32 iddn 
.0/4 perm 
oll fz perm 
oB/ 3a user 


22RD 82) pen 


ey 1) er [= «ey if ver jr © 


14. 


14. 
14. 
14. 


224.0%, 
224.0. 


show route forwarding-table summary 


LZ 


14. 
14. 
14. 


14. 


14. 
14. 


14 


ba 


user@switch> show route forwarding-table summary 


Routing table: 


Internet: 


user: 
perm: 
cleiaitetare 
iS Sirs 
aLieGlia g 
iddn: 


default.inet 


6 rou 


rou 


TEXONEL 


rou 


rou 


rou 


Ces 


BSS) 


Ces 


Ces 


Es) 





Ces 


show route forwarding-table extensive 


user@switch> show route forwarding-table extensive 


Routing table: 


Internet: 


Destination: 








Flags: 
Nexthop: 


ROULS Lype: 


Sent 


Destination: 


Rout 


default.inet 


default 


Ulsiore 


Route reference: 2 





[Index 0] 


to PFE, rt nh decoupled 


Oe ie oie ova il oiche 80) 


Next—-hop type: unicast 


default 





typ 


permanent 


Route reference: 0 


Next-hop interface: me0.0 


Rout 


recv 
eal cits 
oe 
l@el 
bese 
mdsc 
mest 
mcst 


best 


interfac 


137) 
36 
1318 
USL) 
LSALS 
S85 
Sal 
hal 
32 


index: 





Index: 


IS) 


0 


il 
2 
2 
2 
1 
il 
Ss) 
5 
1 


Reference: 





Rout 


interfac 


index: 


0 


ge-0/0/25.0 


ge-0/0/25.0 


5 
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Flags: none 


Next-hop type: reject 


DSGtimeeicas O00 ,0/ 32 





Route type: permanent 


Route reference: 0 





Flags: sent to PFE 
Next-hop type: discard 


Destination: 2.2.2.0/24 
Route type: interfac 





Route reference: 0 





Flags: sent to PFE 
Next-hop type: resolve 


Next-hop interface: ae0.0 


Destination: 2.2.2.0/32 
Route type: destination 


Route reference: 0 





Flags: sent to PFE 
Nexthop: 2.2.2.0 


Next-hop type: receive 








Next-hop interface: ae0.0 


DSSicainaetems  2,2,2,1/ 32 
Route type: destination 


Route reference: 0 





Flags: sent to PFE 
Ne xMelMess Ox Zig aVecess9 seu) 


Next—-hop type: unicast 








Next-hop interface: ae0.0 


DSStimaieiems 2.2.2 2/32 
Route type: interface 
Route reference: 0 
Flags: sent to PFE 
NEXIEIMNCISS 2o2o2n2 
Next-hop type: local 


DSSELiMaietems 2.2.2 ,2/ 32 
Route type: destination 
Route reference: 0 
Flags: none 


INESAEINGISNS Bo2o8ok 


Index: 


36 
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Reference: 2 





Rout 


Index: 


interfac 


34 


index: 0 


Reference: 1 





Rout 


Index: 


interfac 


ESOS 


index: 66 


Reference: 1 





Rout 


Index: 


interfac 


L3O7 


index: 66 


Reference: 1 





Rout 


Index: 


interfac 


S70 


index: 66 


Reference: 1 





Rout 


Index: 


interfac 


1308 


index: 0 


Reference: 2 





Rout 


interfac 


index: 66 
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Next-hop type: local Index: 1308 Reference: 2 


DSSicdimeicwems 2,2,2 255/32 


Route type: destination 





Route reference: 0 Route interface-index: 66 
Flags: sent to PFE 
Nexthop 3252.41.25 





Next—-hop type: broadcast Index: 1306 Reference: 1 








Next-hop interface: ae0.0 


show route forwarding-table ccc 


user@switch> show route forwarding-table ccc ge-0/0/0.10 


Routing table: default.mpls 





MPLS: 
Destination Type RtRef Next hop Type Index NhRef Netif 
Cea 00/0 OMe CC) mas ere O SudeSo2 Push JOO 2 ls 43 2 ael.0 


show route forwarding-table family (MPLS) 


user@switch> show route forwarding-table family mpls 


Routing table: default.mpls 





MPLS: 

Destination Type RtRef Next hop Type Index NhRef Netif 
default perm 0 dscd 0) il 

0 user 0 recv 49 ) 

il user 0 recv 49 5 

2 user 0 recv 49 3) 

BOTT user 0 Pop 1334 2 ge-0/0/0.10 
ZOO Sz user 0 Pop LIBS 2 ge-0/0/0.14 
299808 user 0 Pop 1341 2 ge-0/0/0.2 
299824 user 0 Pop 1344 2 ge-0/0/0.11 
299840 user 0 Pop 1345 2 ge-0/0/0.13 
299856 user 0 Pop 1346 2 ¢S=-0/ 0/018 
299872 user 0 Pop 1347 CG O10 AO eaG 
299888 user 0 Pop 1348 2 ge-0/0/0.7 
299904 user 0 Pop 1349 2 ge-0/0/0.20 
299920 user 0 Pop 1350 2 ge-0/0/0.19 
299936 user 0 Pop LSS i, 2 ¢2e-0/ 0/017 
299952 user 0 Pop L352 2 ge-0/0/0.9 
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299968 user 0 Pop Lass Veit OV AO a0 
299984 user 0 Pop 1354 2 ge-0/0/0.12 
300000 user 0 Pop 1355) 2 ge-0/0/0.8 
300016 user 0 Pop 1356 2 ge-0/0/0.4 
300032 user 0 Pop 1357 2 ge-0/0/0.5 
300048 user 0 Pop 1358 2 ge-0/0/0.3 
300064 user 0 Pop 135% Zages 0) 0/7 0rES 
ge-0/0/0.1 (CCC) user O 3595302 Push 300064 1340 2 ael.0 
ge-0/0/0.2 (CCC) user O Se Socio2! Push 299872 1328 2 ael.0 
ge-0/0/0.3 (CCC) user O S585 302 Push 299792 1323 2 ael.0 
ge-0/0/0.4 (CCC) user O Si. 353o2 Push 300016 1337 2 ael.0 
Gea 010/10r Sun (CCC )mumusene O So 85302 Push 299824 1325 2 ael.0 
ge-0/0/0.7 (CCC) user O So desoX2 Push 299920 1331 2 ael.0 
ge-0/0/0.8 (CCC) user OES eer sree. Push 299840 1326 2 ael.0 
ge-0/0/0.9 (CCC) user 0 3585352 Push 299888 1329 2 ael.0 
Gee 0 O/f0rOmen (ESC) muses O Bo3o3o2 Push 300112 1343 2 aveil 0 
ge-0/0/0.11 (CCC) user 0 Sadada# Sos LOGO s22 2 ael.0 
Gea 0/0 0a (C CC) sex O Sudo So2 Disa LYNH52 si sys 2 ael.0 
ge-0/0/0.13 (CCC) user 0 SadaSaZ Push 300096 1342 2 aii sO 
Gee 00/0 AS (ECC) muses O Seda de® Push 299984 1335 2 ael.0 
Ge O/0re Seen (ECC) muses O So3o3o2 Susi 2IGI3G 32 2 ael.0 
Ge-O/O/O.16 (CCC) wseie OMSeesrers ee Push 299808 1324 2 ae 10 
CS—O/O/O by (Ce) weer O Sade 3o2 Push 300000 1336 2 ael.0 
ge-0/0/0.18 (CCC) user 0 SadaSaZ Pushes 00082 ae lesis 2 ael.0 
ge-0/0/0.19 (CCC) user O Su3eo352 Push 299904 1330 A ied 410 
ge-0/0/0.20 (CCC) user O So3o3o2 Push 299856 1327 2 evel, 
show route forwarding-table family (IPv6) 
user@switch> show route forwarding-table family inet6 
Routing table: default.inet6é 
Interneté6: 
Destination Type RtRef Next hop Type Index NhRef Netif 
default perm 0 ie Cie 44 il 
Bo fiat} perm 0 dscd 42 il 
eEOOS S/S perm 0 mdsc 43 1 
EO28 3 1/12 perm ) ser (029 ¢ al mest By AL 
Routing table: default-switch.inet6 
Internet6: 
Destination Type RtRef Next hop Type Index NhRef Netif 
default perm 0 ie CIE 530 iL 


S33 /L28 perm 0 dscd 528 1 





Asis sao / silz user 0 aboyelie iL iLO 7/7 2 
comp 3/2 il 
Boils g 3ei2/ 3.20 user 0 alinelie 1S L071 3 
comp 51/3 1 
23138 3airo/ 320 user 0 alieyelie il 3311 (0)7/ aL 3 
comp 313 1 
Agi ss xr O00s 3 /HG user 0 mdsc 528) B 
HEOOS 3 /B perm 0 mdsc 52g 2 
OAS 2 iL / MZ} perm 0) se1c02'9 9 Al mest SAG 1 
Routing table: __master.anon__.inet6 
Internet6: 
Destination Type RtRef Next hop Type Index NhRef Netif 
default perm 0 iS Ce. 554 1 
G3 / 128 perm 0 dscd B52 1 
OOS 3/8 perm 0 mdsc 353 1 
EOL 21/128 perm Q sO29 3 1 mcst S510 iL 


show route forwarding-table label 


user@switch> show route forwarding-table label 29976 


Routing table: default.mpls 





MP ES: 
Destination Type RtRef Next hop Type Index NhRef Netif 
2ONT IG user 0 Pop 1334 2 ge-0/0/0.10 


show route forwarding-table matching 


user@switch> show route forwarding-table matching 3 


Routing table: default.inet 


Internet: 


show route forwarding-table multicast 


user@switch> show route forwarding-table multicast 


Routing table: default.inet 
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IME Sie nSHe, 8 

Destination 
224.0.0.0/4 
ABE Os 051/ 32 
22 AMOR Oras 2 


Routing table: 


IME SHEINENC 8 

Destination 
ZZA OV OF 0/4 
224 Os0.1/ 32 


Routing table: 


Interneté6: 
Destination 
EEOOS 8/2 
OZR eI / LAs 


Type RtRef Next hop 

perm alt 

perm @ 224.0,0.1 

user i Zee 0,055 
__master.anon__.inet 

Type RtRef Next hop 

perm 0 

perm O 224.0 ,051 
default .inet6 

Type RtRef Next hop 

perm 0 

perm @ 02 ai 











Type Index NhRef Netif 
mdsc 55 i 

mcst Sid S 

mcst Sil 3 

Type Index NhRef Netif 
mele: 29) il 

mesic LAGS lf 

Type Index NhRef Netif 
mdsc 43 

mcst $8) il 
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| show route table 


List of Syntax 
Syntax on page 2433 
Syntax (EX Series Switches, QFX Series Switches) on page 2433 


Syntax 


show route table routing-table-name 
<brief | detail | extensive | terse> 


<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches, QFX Series Switches) 


show route table routing-table-name 
<brief | detail | extensive | terse> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

Statement introduced in Junos OS Release 14.1X53-D15 for QFX Series switches. 

Show route table evpn statement introduced in Junos OS Release 15.1X53-D30 for QFX Series switches. 


Description 


Display the route entries in a particular routing table. 


Options 


brief | detail | extensive | terse—(Optional) Display the specified level of output. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on a 
particular logical system. 


routing-table-name—Display route entries for all routing tables whose names begin with this string (for 
example, inet.O0 and inet6.0 are both displayed when you run the show route table inet command). 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


show route summary 


List of Sample Output 


show route table bgp.I2vpn.0 on page 2447 

show route table inet.0 on page 2447 

show route table inet.3 on page 2448 

show route table inet.3 protocol ospf on page 2448 
show route table inet6.0 on page 2448 

show route table inet6.3 on page 2449 

show route table I2circuit.0 on page 2449 

show route table Isdist.0 on page 2450 

show route table mpls on page 2450 

show route table mpls.0 protocol ospf on page 2450 
show route table VPN-AB.inet.0 on page 2451 


Output Fields 


Table 68 on page 2434 describes the output fields for the show route table command. Output fields are 
listed in the approximate order in which they appear. 


Table 68: show route table Output Fields 


Field Name 


routing-table-name 


Restart complete 


number destinations 


Field Description 


Name of the routing table (for example, inet.0). 


All protocols have restarted for this routing table. 
Restart state: 


e Pending:protocol-name—List of protocols that have not yet completed graceful restart for 
this routing table. 


e Complete—All protocols have restarted for this routing table. 


For example, if the output shows- 


e LDP.inet.0 : 5 routes (4 active, 1 holddown, O hidden) 


Restart Pending: OSPF LDP VPN 


This indicates that OSPF, LDP, and VPN protocols did not restart for the LDP.inet.0 routing 
table. 


e vpls_1.12vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 
hidden) 
Restart Complete 


This indicates that all protocols have restarted for the vpls_1.I2vpn.0 routing table. 


Number of destinations for which there are routes in the routing table. 
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Table 68: show route table Output Fields (continued) 


Field Name 


number routes 


route-destination 


(entry, announced) 


Field Description 


Number of routes in the routing table and total number of routes in the following states: 


e active (routes that are active) 


e holddown (routes that are in the pending state before being declared inactive) 


e hidden (routes that are not used because of a routing policy) 


Route destination (for example:10.0.0.1/24). The entry value is the number of routes for this 


destination, and the announced value is the number of routes being announced for this 


destination. Sometimes the route destination is presented in another format, such as: 


e MPLS-label (for example, 80001). 


e interface-name (for example, ge-1/0/2). 


e neighbor-address:control-word-status:encapsulation type:vc-id:source (Layer 2 circuit only; for 
example, 10.1.1.195:NoCtrlWord:1:1:Local/96). 


neighbor-address—Address of the neighbor. 


control-word-status—Whether the use of the control word has been negotiated for this 
virtual circuit: NoCtrlWord or CtrlWord. 


encapsulation type—Type of encapsulation, represented by a number: (1) Frame Relay 
DLCl, (2) ATM AAL5 VCC transport, (3) ATM transparent cell transport, (4) Ethernet, (5) 
VLAN Ethernet, (6) HDLC, (7) PPP, (8) ATM VCC cell transport, (10) ATM VPC cell 
transport. 


vc-id—Virtual circuit identifier. 


source—Source of the advertisement: Local or Remote. 


e inclusive multicast Ethernet tag route—Type of route destination represented by (for example, 
3:100.100.100.10:100::0::10::100.100.100.10/384): 


route distinguisher—(8 octets) Route distinguisher (RD) must be the RD of the EVPN 
instance (EVI) that is advertising the NLRI. 


Ethernet tag ID—(4 octets) Identifier of the Ethernet tag. Can set to 0 or to a valid Ethernet 
tag value. 

IP address length—(1 octet) Length of IP address in bits. 

originating router’s IP address—(4 or 16 octets) Must set to the provider edge (PE) device’s 
IP address. This address should be common for all EVIs on the PE device, and may be the 
PE device's loopback address. 
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Table 68: show route table Output Fields (continued) 


Field Name 


label stacking 


[protocol, preference] 


Level 


Route Distinguisher 


PMSI 


Next-hop type 


Next-hop reference 


count 


Field Description 


(Next-to-the-last-hop routing device for MPLS only) Depth of the MPLS label stack, where 
the label-popping operation is needed to remove one or more labels from the top of the stack. 
A pair of routes is displayed, because the pop operation is performed only when the stack 
depth is two or more labels. 


e S=0 route indicates that a packet with an incoming label stack depth of 2 or more exits this 
routing device with one fewer label (the label-popping operation is performed). 


e If there is no S= information, the route is a normal MPLS route, which has a stack depth of 
1 (the label-popping operation is not performed). 


Protocol from which the route was learned and the preference value for the route. 


e +—A plus sign indicates the active route, which is the route installed from the routing table 
into the forwarding table. 


e -—A hyphen indicates the last active route. 


e *—An asterisk indicates that the route is both the active and the last active route. An asterisk 
before a to line indicates the best subpath to the route. 


In every routing metric except for the BGP LocalPref attribute, a lesser value is preferred. In 
order to use common comparison routines, Junos OS stores the 1's complement of the LocalPref 
value in the Preference2 field. For example, if the LocalPref value for Route 1 is 100, the 
Preference2 value is -101. If the LocalPref value for Route 2 is 155, the Preference2 value is 
-156. Route 2 is preferred because it has a higher LocalPref value and a lower Preference2 
value. 


(IS-IS only). In IS-IS, a single AS can be divided into smaller groups called areas. Routing between 
areas is organized hierarchically, allowing a domain to be administratively divided into smaller 
areas. This organization is accomplished by configuring Level 1 and Level 2 intermediate 
systems. Level 1 systems route within an area. When the destination is outside an area, they 
route toward a Level 2 system. Level 2 intermediate systems route between areas and toward 
other ASs. 

IP subnet augmented with a 64-bit prefix. 

Provider multicast service interface (MVPN routing table). 


Type of next hop. For a description of possible values for this field, see Table 69 on page 2441. 


Number of references made to the next hop. 
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Table 68: show route table Output Fields (continued) 


Field Name 
Flood nexthop 
branches exceed 
maximum message 
Source 


Next hop 


via 


Label-switched-path 
Isp-path-name 


Label operation 


Interface 


Protocol next hop 


Indirect next hop 


State 


Local AS 


Age 


Field Description 


Indicates that the number of flood next-hop branches exceeded the system limit of 32 branches, 
and only a subset of the flood next-hop branches were installed in the kernel. 


IP address of the route source. 


Network layer address of the directly reachable neighboring system. 


Interface used to reach the next hop. If there is more than one interface available to the next 
hop, the name of the interface that is actually used is followed by the word Selected. This 


field can also contain the following information: 


e Weight—Value used to distinguish primary, secondary, and fast reroute backup routes. 
Weight information is available when MPLS label-switched path (LSP) link protection, 
node-link protection, or fast reroute is enabled, or when the standby state is enabled for 
secondary paths. A lower weight value is preferred. Among routes with the same weight 
value, load balancing is possible. 

e Balance—Balance coefficient indicating how traffic of unequal cost is distributed among 
next hops when a routing device is performing unequal-cost load balancing. This information 
is available when you enable BGP multipath load balancing. 


Name of the LSP used to reach the next hop. 


MPLS label and operation occurring at this routing device. The operation can be pop (where 
a label is removed from the top of the stack), push (where another label is added to the label 
stack), or swap (where a label is replaced by another label). 


(Local only) Local interface name. 


Network layer address of the remote routing device that advertised the prefix. This address 


is used to derive a forwarding next hop. 


Index designation used to specify the mapping between protocol next hops, tags, kernel export 


policy, and the forwarding next hops. 


State of the route (a route can be in more than one state). See Table 70 on page 2443. 


AS number of the local routing devices. 


How long the route has been known. 
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Table 68: show route table Output Fields (continued) 


Field Name 


AIGP 


Metricn 


MED-plus-IGP 


TTL-Action 


Task 


Announcement bits 


Field Description 


Accumulated interior gateway protocol (AIGP) BGP attribute. 


Cost value of the indicated route. For routes within an AS, the cost is determined by IGP and 
the individual protocol metrics. For external routes, destinations, or routing domains, the cost 
is determined by a preference value. 


Metric value for BGP path selection to which the IGP cost to the next-hop destination has 
been added. 


For MPLS LSPs, state of the TTL propagation attribute. Can be enabled or disabled for all 
RSVP-signaled and LDP-signaled LSPs or for specific VRF routing instances. 


Name of the protocol that has added the route. 


The number of BGP peers or protocols to which Junos OS has announced this route, followed 
by the list of the recipients of the announcement. Junos OS can also announce the route to 
the kernel routing table (KRT) for installing the route into the Packet Forwarding Engine, to a 
resolve tree, a Layer 2 VC, or even a VPN. For example, n-Resolve inet indicates that the 
specified route is used for route resolution for next hops found in the routing table. 


e n—An index used by Juniper Networks customer support only. 
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Table 68: show route table Output Fields (continued) 


Field Name 


AS path 


validation-state 


FECs bound to route 


Field Description 


AS path through which the route was learned. The letters at the end of the AS path indicate 
the path origin, providing an indication of the state of the route at the point at which the AS 
path originated: 


e I—IGP. 

e E—EGP. 

e Recorded—The AS path is recorded by the sample process (sampled). 
e ?—Incomplete; typically, the AS path was aggregated. 


When AS path numbers are included in the route, the format is as follows: 


e []—Brackets enclose the number that precedes the AS path. This number represents the 
number of ASs present in the AS path, when calculated as defined in RFC 4271. This value 
is used in the AS-path merge process, as defined in RFC 4893. 

e []—If more than one AS number is configured on the routing device, or if AS path prepending 
is configured, brackets enclose the local AS number associated with the AS path. 

e {}—Braces enclose AS sets, which are groups of AS numbers in which the order does not 
matter. A set commonly results from route aggregation. The numbers in each AS set are 
displayed in ascending order. 


e ()—Parentheses enclose a confederation. 


e ([])—Parentheses and brackets enclose a confederation set. 


NOTE: InJunos OS Release 10.3 and later, the AS path field displays an unrecognized attribute 
and associated hexadecimal value if BGP receives attribute 128 (attribute set) and you have 
not configured an independent domain in any routing instance. 


(BGP-learned routes) Validation status of the route: 


e Invalid—Indicates that the prefix is found, but either the corresponding AS received from 
the EBGP peer is not the AS that appears in the database, or the prefix length in the BGP 
update message is longer than the maximum length permitted in the database. 

e Unknown-—Indicates that the prefix is not among the prefixes or prefix ranges in the database. 

e Unverified—Indicates that the origin of the prefix is not verified against the database. This 
is because the database got populated and the validation is not called for in the BGP import 
policy, although origin validation is enabled, or the origin validation is not enabled for the 


BGP peers. 


e Valid—Indicates that the prefix and autonomous system pair are found in the database. 


Indicates point-to-multipoint root address, multicast source address, and multicast group 
address when multipoint LDP (M-LDP) inband signaling is configured. 
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Table 68: show route table Output Fields (continued) 


Field Name 


Primary Upstream 


RPF Nexthops 


Label 


weight 


VC Label 


MTU 


VLAN ID 


Prefixes bound to 
route 


Communities 


Layer2-info: encaps 


control flags 


mtu 


Label-Base, range 


status vector 


Accepted Multipath 


Field Description 

When multipoint LDP with multicast-only fast reroute (MoFRR) is configured, indicates the 
primary upstream path. MoFRR transmits a multicast join message from a receiver toward a 
source ona primary path, while also transmitting a secondary multicast join message from the 
receiver toward the source on a backup path. 

When multipoint LDP with MoFRR is configured, indicates the reverse-path forwarding (RPF) 
next-hop information. Data packets are received from both the primary path and the secondary 
paths. The redundant packets are discarded at topology merge points due to the RPF checks. 
Multiple MPLS labels are used to control MoFRR stream selection. Each label represents a 
separate route, but each references the same interface list check. Only the primary label is 
forwarded while all others are dropped. Multiple interfaces can receive packets using the same 


label. 


Value used to distinguish MoFRR primary and backup routes. A lower weight value is preferred. 
Among routes with the same weight value, load balancing is possible. 


MPLS label assigned to the Layer 2 circuit virtual connection. 


Maximum transmission unit (MTU) of the Layer 2 circuit. 


VLAN identifier of the Layer 2 circuit. 


Forwarding equivalent class (FEC) bound to this route. Applicable only to routes installed by 
LDP. 


Community path attribute for the route. See Table 71 on page 2445 for all possible values for 
this field. 


Layer 2 encapsulation (for example, VPLS). 


Control flags: none or Site Down. 


Maximum transmission unit (MTU) information. 


First label in a block of labels and label block size. A remote PE routing device uses this first 
label when sending traffic toward the advertising PE routing device. 


Layer 2 VPN and VPLS network layer reachability information (NLRI). 


Current active path when BGP multipath is configured. 


Table 68: show route table Output Fields (continued) 


Field Name 


Accepted 
LongLivedStale 


Accepted 
LongLivedStalelmport 


ImportAccepted 
LongLivedStalelmport 


Accepted 
MultipathContrib 


Localpref 


Router ID 


Primary Routing 
Table 


Secondary Tables 


Field Description 


The LongLivedStale flag indicates that the route was marked LLGR-stale by this router, as part 
of the operation of LLGR receiver mode. Either this flag or the LongLivedStalelmport flag 
might be displayed for a route. Neither of these flags is displayed at the same time as the Stale 
(ordinary GR stale) flag. 


The LongLivedStalelmport flag indicates that the route was marked LLGR-stale when it was 
received from a peer, or by import policy. Either this flag or the LongLivedStale flag might be 
displayed for a route. Neither of these flags is displayed at the same time as the Stale (ordinary 
GR stale) flag. 


Accept all received BGP long-lived graceful restart (LLGR) and LLGR stale routes learned from 
configured neighbors and import into the inet.O routing table 


Accept all received BGP long-lived graceful restart (LLGR) and LLGR stale routes learned from 
configured neighbors and imported into the inet.O routing table 


The LongLivedStalelmport flag indicates that the route was marked LLGR-stale when it was 
received from a peer, or by import policy. 


Path currently contributing to BGP multipath. 


Local preference value included in the route. 


BGP router ID as advertised by the neighbor in the open message. 


In a routing table group, the name of the primary routing table in which the route resides. 


In arouting table group, the name of one or more secondary tables in which the route resides. 


Table 69 on page 2441 describes all possible values for the Next-hop Types output field. 


Table 69: Next-hop Types Output Field Values 


Next-Hop Type 


Broadcast (bcast) 


Deny 


Discard 


Description 


Broadcast next hop. 


Deny next hop. 


Discard next hop. 
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Table 69: Next-hop Types Output Field Values (continued) 


Next-Hop Type 


Flood 


Hold 


Indexed (idxd) 


Indirect (indr) 


Interface 


Local (locl) 


Multicast (mcst) 


Multicast discard (mdsc) 


Multicast group (mgrp) 


Receive (recv) 


Reject (rjct) 


Resolve (rslv) 


Routed multicast (mcrt) 


Description 

Flood next hop. Consists of components called branches, up to a 
maximum of 32 branches. Each flood next-hop branch sends a copy 
of the traffic to the forwarding interface. Used by point-to-multipoint 
RSVP, point-to-multipoint LDP, point-to-multipoint CCC, and 
multicast. 

Next hop is waiting to be resolved into a unicast or multicast type. 
Indexed next hop. 

Used with applications that have a protocol next hop address that is 
remote. You are likely to see this next-hop type for internal BGP 
(IBGP) routes when the BGP next hop is a BGP neighbor that is not 
directly connected. 

Used for a network address assigned to an interface. Unlike the router 
next hop, the interface next hop does not reference any specific node 


on the network. 


Local address on an interface. This next-hop type causes packets with 
this destination address to be received locally. 


Wire multicast next hop (limited to the LAN). 


Multicast discard. 


Multicast group member. 


Receive. 


Discard. An ICMP unreachable message was sent. 


Resolving next hop. 


Regular multicast next hop. 
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Table 69: Next-hop Types Output Field Values (continued) 


Next-Hop Type 


Router 


Table 


Unicast (ucst) 


Unilist (ulst) 


Description 


A specific node or set of nodes to which the routing device forwards 
packets that match the route prefix. 


To qualify as a next-hop type router, the route must meet the 
following criteria: 


e Must not be a direct or local subnet for the routing device. 


e Must have a next hop that is directly connected to the routing 
device. 


Routing table next hop. 


Unicast. 


List of unicast next hops. A packet sent to this next hop goes to any 
next hop in the list. 


Table 70 on page 2443 describes all possible values for the State output field. A route can be in more than 
one state (for example, <Active NoReadvrt Int Ext>). 


Table 70: State Output Field Values 


Value 


Accounting 


Active 


Always Compare MED 


AS path 


Cisco Non-deterministic MED selection 


Clone 


Cluster list length 


Delete 


Ex 


Description 


Route needs accounting. 


Route is active. 


Path with a lower multiple exit discriminator (MED) is available. 


Shorter AS path is available. 


Cisco nondeterministic MED is enabled, and a path with a lower MED is 
available. 


Route is a clone. 


Length of cluster list sent by the route reflector. 


Route has been deleted. 


Exterior route. 
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Table 70: State Output Field Values (continued) 


Value 


Ext 


FlashAll 


Hidden 


IfCheck 


IGP metric 


Inactive reason 


Initial 


Int 


Int Ext 


Interior > Exterior > Exterior via Interior 


Local Preference 


Martian 


MartianOK 


Next hop address 


No difference 


NoReadvrt 


NotBest 


Not Best in its group 


NotlInstall 


Description 

BGP route received from an external BGP neighbor. 

Forces all protocols to be notified of a change to any route, active or 
inactive, for a prefix. When not set, protocols are informed of a prefix 
only when the active route changes. 

Route not used because of routing policy. 

Route needs forwarding RPF check. 


Path through next hop with lower IGP metric is available. 


Flags for this route, which was not selected as best for a particular 


destination. 


Route being added. 


Interior route. 


BGP route received from an internal BGP peer or a BGP confederation 


peer. 


Direct, static, IGP, or EBGP path is available. 


Path with a higher local preference value is available. 


Route is a martian (ignored because it is obviously invalid). 


Route exempt from martian filtering. 


Path with lower metric next hop is available. 


Path from neighbor with lower IP address is available. 


Route not to be advertised. 


Route not chosen because it does not have the lowest MED. 


Incoming BGP AS is not the best of a group (only one AS can be the best). 


Route not to be installed in the forwarding table. 


2445 


Table 70: State Output Field Values (continued) 


Value 


Number of gateways 


Origin 


Pending 


Release 


RIB preference 


Route Distinguisher 


Route Metric or MED comparison 


Route Preference 


Router ID 


Secondary 


Unusable path 


Update source 


Description 


Path with a greater number of next hops is available. 


Path with a lower origin code is available. 


Route pending because of a hold-down configured on another route. 


Route scheduled for release. 


Route from a higher-numbered routing table is available. 


64-bit prefix added to IP subnets to make them unique. 


Route with a lower metric or MED is available. 


Route with lower preference value is available. 


Path through a neighbor with lower ID is available. 


Route not a primary route. 


Path is not usable because of one of the following conditions: 


e The route is damped. 
e The route is rejected by an import policy. 


e The route is unresolved. 


Last tiebreaker is the lowest IP address value. 


Table 71 on page 2445 describes the possible values for the Communities output field. 


Table 71: Communities Output Field Values 


Value Description 
area-number 4 bytes, encoding a 32-bit area number. For AS-external routes, the value is 0. A 
nonzero value identifies the route as internal to the OSPF domain, and as within the 
identified area. Area numbers are relative to a particular OSPF domain. 


bandwidth: local AS 
number:link-bandwidth-number | has several candidate paths available for multipath purposes, it does not perform 


Link-bandwidth community value used for unequal-cost load balancing. When BGP 


unequal-cost load balancing according to the link-bandwidth community unless all 
candidate paths have this attribute. 
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Table 71: Communities Output Field Values (continued) 


Value 


domain-id 


domain-id-vendor 


link-bandwidth-number 


local AS number 


options 


origin 


ospf-route-type 


route-type-vendor 


rte-type 


target 


unknown IANA 


unknown OSPF vendor 


community 


evpn-mcast-flags 


evpn-|2-info 


Description 


Unique configurable number that identifies the OSPF domain. 


Unique configurable number that further identifies the OSPF domain. 


Link-bandwidth number: from 0 through 4,294,967,295 (bytes per second). 


Local AS number: from 1 through 65,535. 


1 byte. Currently this is only used if the route type is 5 or 7. Setting the least 
significant bit in the field indicates that the route carries a type 2 metric. 


(Used with VPNs) Identifies where the route came from. 


1 byte, encoded as 1 or 2 for intra-area routes (depending on whether the route 
came from a type 1 or a type 2 LSA); 3 for summary routes; 5 for external routes 
(area number must beO); 7 for NSSA routes; or 129 for sham link endpoint addresses. 


Displays the area number, OSPF route type, and option of the route. This is configured 
using the BGP extended community attribute Ox8000. The format is 
area-number:ospf-route-type:options. 


Displays the area number, OSPF route type, and option of the route. This is configured 
using the BGP extended community attribute 0x0306. The format is 
area-number:ospf-route-type:options. 


Defines which VPN the route participates in; target has the format 32-bit IP 
address:16-bit number. For example, 10.19.0.0:100. 


Incoming IANA codes with a value between Ox1 and Ox7fff. This code of the BGP 
extended community attribute is accepted, but it is not recognized. 


Incoming IANA codes with a value above 0x8000. This code of the BGP extended 
community attribute is accepted, but it is not recognized. 


Identifies the value in the multicast flags extended community and whether snooping 
is enabled. A value of Ox1 indicates that the route supports IGMP proxy. 


Identifies whether Multihomed Proxy MAC and IP Address Route Advertisement is 
enabled. A value of 0x20 indicates that the proxy bit is set. . 


Use the show bridge mac-ip-table extensive statement to determine whether the 
MAC and IP address route was learned locally or from a PE device. 
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| Sample Output 


show route table bgp.I2vpn.0 


user@host> show route table bgp.I2vpn.0 


bgp.12vpn.0: 1 destinations, 1 routes (1 active, 0 holddown, O hidden) 








+ = Active Route, Last Active, * = Both 


192 168,24. bgilsael (Os 
“[ES/LIO] OLeOSsS8, ikoeaiilisieeie 100, itm 192,168.24. i 
ASP pach: 
> co LO,0516.2 Wila re-O0/O/1,0, Ialoeil—sijaiicclvecl josie sin 


show route table inet.0 


user@host> show route table inet.0 


inet.0: 12 destinations, 12 routes (11 active, 0 holddown, 1 hidden) 
kt = 




















+ = Active Route, Last Active, = Both 

ORO ROR OLA0 “(StactLe/S] Ossie S7 
> tO 172.,16.,5,254 wia esq). 

10.0,.0,1/32 ‘[Datsecte/ Ol OO Sik 58 
Eplouraie= 51/3/00 

10.0.0.2/32 Seca / Oi] Ws Sil sss) 
Local 

10 512.12 21/32 = Inca /@]) OWsSils 57 
Reject 

IO, 13,135.13 / 32 + Darreet/ Ol) OOo 1es58 
= wile t3—-5/2/1.0 

10,13,13,14/32 “[Local/Oi| Og Si3 5 
Local 

1@.13,.13,21/ 32 =[Local/@]| OMsSi25e 
Local 

10.13.13 .22/32 “x ([Dakiascie /O]| OWSsssay 
> Wile tS-5/2/0.0 

127 0.0. lf 32 Dalmace/ 0] WOsSile Ss 
> via 100.0 

10.222 .5 0/24 “|Daiwecit/O]] OO Sie se 
S wale i450) , (0) 

10,222 .5.81/ 32 Alo call 0) MOOR Sis: S18 





Local 


show route table inet.3 


user@host> show route table inet.3 
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inet.3: 5 destinations, 5 routes (5 active, 0 holddown, O hidden) 
+ = Active Route, Last Active, * = Both 
10.0.0. 5/32 “[LD2/9] OOs25243, maccic lO, tac 200 
EO 10,.2,94,2 wie Me=i1/2/0.,49 
> EtG 10,2,3.2 wha le=1/2/0,23 
show route table inet.3 protocol ospf 
user@host> show route table inet.3 protocol ospf 
inet.3: 9 destinations, 18 routes (9 active, 0 holddown, 0 hidden) 
+ = Active Route, Last Active, * = Both 
1,1,1,20/32 [L-OSPF/10] 1d 00:00:56, metric 2 
> co 10,010.70 wila iie—1/2/0,14, Pusin SOOO2Z0 
Tom lO MOR Gr OOM Wtaee tt 22/0 lA ish ec OO O20 Plsiis OUlOSONCEop) 
1,1,1,30/32 [L-OSPF/10] 1d 00:01:01, metric 3 
Se Onl Ons OniOmvaltcilets— ae 27/0 eee cine OOO 0 
Ou ORO 6- 6 Ovals — 1/27/02 Perish OOOO 
1, 40/32 [L-OSPF/10] 1d 00:01:01, metric 4 
SEO 10,0,10,70 wie e-1/2/0.14, Pisin SOOOA4W 
to 10.0.6.60 via 1lt-1/2/0.12, Push 800040 
1,151,50/32 [L-OSPF/10] 1d 00:01:01, metric 5 
Sco 10,010, 70 wile Ie—1/2/0,14, Pucin SOOOSH 
co 100,606,680 waa le-l/2/0.12, Pusia SOO050 
1,1,1,60/32 [L-—OS27 /i10)) ikcl OOZOLeOiL, meee © 
> co 1LO.0.10,70 wie iit—1/2/0,14, Pusin SOOOGO 
e@ 10,056.60 wie Me-1/2/O0.12, Pee 
show route table inet6.0 
user@host> show route table inet6.0 
inet6.0: 3 destinations, 3 routes (3 active, 0 holddown, O hidden) 





* 





+ = Active Route, Last Route, 
fec0:0:0:3::/64 *[Direct/0] 


Pye te=0/1/ 0.0 


OO 0134 


Both 


HSCOLOLOMeSse/il2Ze “[ihkacall/O]| MOs@ils sa 


>Local 
tee sOeOcwles/ed “= [Gieaicae/s] OMe @ils 34 


Sce©® uSeleOsGeSegrtre waa Le-0/1/0.0 


show route table inet6.3 


user@router> show route table inet6.3 


inet6.3: 2 destinations, 2 routes (2 active, 0 holddown, 0 hidden) 


+ = Active Route, Last Active, * = Both 








6310 ,255, 245, 195/128 
“(D2 /9]| OOsO0s22, mecrie i 
> via so-1/0/0.0 
8210 ,255 245, 196/128 
= (IHD2/S]| OOSOOSOS, mreicieske iL 
> via so-1/0/0.0, Push 100008 


show route table I2circuit.0 


user@host> show route table I2circuit.0 


12circuit.0: 4 destinations, 4 routes (4 active, 0 holddown, 0O hidden) 


+ = Active Route, Last Active, * = Both 








HOR peo No Girl Wordly sleoeally/A916 
= [mec / 7] OOsS0347 
> via so-0/1/2.0, Push 100049 
Vics On0)/5/ SO ;ebusiie KOO OAS 
10.1.1.195:NoCtrlWord:1:1:Remote/96 
= [D2 /9]] Os S03 14 
Discard 
IM .1, 1 ,1MS sCerilwjorels 1323 eee / IE 
Pe CRs OOM Onray7 
> via so-0/1/2.0, Push 100049 
via so-0/1/3.0, Push 100049 
GeO SC tral Woreclulks ey Remomcy/.o)6 
= [D2 /9]] Os S03 14 


Discard 
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show route table Isdist.0 


user@host> show route table Isdist.0 


SCL SE 0) 5 


+ = Activ 


3 destinations, 








LINK { Local { AS:4 BGP-LS I 
IEPs IDS IO WP wls a. We to} 
* [BGP-LS-EPE/170] 


LINK { Local { AS:4 BGP-LS I 


Rout 


, 


Last Active, 











Fictitious 





3 routes 


(3 active, 
* = Both 


CORA OR a16 


0 holddown, 


D:100 IPv4:4.4.4.4 }.{ IPv4:4. 
of MEWS 76 oS Wievcleseainvexols 0) 


D:100 IPv4:4.4.4.4 }.{ IPv4:4. 


REMOES yf ASH IEPs IDs 00) UPWARVs7odnd ol Wewestetado tal 


PINK hoce ae AS 4s GP hSeesl)- a 
BEP= 55 WD 100 wewleS.565.5 fod 
* [BGP-LS-— 


show route table mpls 


IBGE S lon 











Fictitious 














Hacrate lous 


user@host> show route table mpls 


MPS Oks 


+ = Activ 


4 destinations, 


4 routes 








1024 


Rout 


, 





Last Active, 


MPLS/0] 
Receive 
MPLS/0] 
Receive 
MPLS/0] 


Receive 





V. 


U 





show route table mpls.0 protocol ospf 


EPE/170] 


(4 active, 


CORA Onta16 


WOR ZO S16 


oy = even lal 


OWsiseSS, meieresle 


OOsiseS5S, meieresae 





OOsiseS5,. mrererese 


/0] 00:04:18 


to table red.inet.0O, 


Pop 


user@host> show route table mpls.0 protocol ospf 


MONS 4 OS 


+ = Activ 


29 destinations, 


29 routes 








Bout 


, 


Last Active, 


(@oiacienrcy 
* = Both 


0 holddown, 


0 holddown, 


OQ hidden) 


4.4.4 } Remote { AS:4 


7152 


4.4.4 IfIndex:339 } 
} Undefined:0 }/1152 


lOO TPy434.4.4.4 ).f TPv4:50.1.1.1 }) Remote { As <4 
LPV4As50 1.1.2 } Unmclatimads@ 1/1152 
EPE/170] 


0 hidden) 


0 hidden) 
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ASE) S\ SV 2. =(L-OSPs/10]) 23s59e42, mecicie © 
Sco 10,010.70 wa le-l/2/0.14, Pes 
to 10.0.6.60 via 1t-1/2/0.12, Swap 800070, Push 800030 (top) 
29D 5 2Z5(S—0)) “[L-OSPi/10]) 2Ich9sd2, mercicile O 
Sco 10,010.70 wile le=-l/2/0.14, Pes 
to 10.0.6.60 via 1t-1/2/0.12, Swap 800070, Push 800030 (top) 
299968 = ([L-OSPN/10] 23eo9c4s, meicicle © 
> cO 10,0,6.60 wie le=1/2/0,12, Pes 


show route table VPN-AB.inet.0 


user@host> show route table VPN-AB.inet.O 


VPN-AB.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, O hidden) 




















+ = Active Route, Last Active, * = Both 
10,39.1.0/30 FALOSE Ey / sO OO ROME SAAT mem eeraclomml 
> wile so-7/S/1.0 
10539), 154/30 *[Direct/0] 00:08:42 
> wie so-5/1/0.0 
10539), 156/32 *[Local/0] 00:08:46 
Local 
1.2555 71.16/32 PaliCitscite ey oil OO One 
> wie so-2/0/0.0 
10,255), 7il. ly 732 = XES/L7/0] OOSO7324, Mian) 1, ilecalljouceie 00, ieee 
10,255. 71.15 
IMS jOeNElaAg I 
> Wila so-2/1/0.0, Pusia LOOOZ0, Pusin LOOOLL (ices) 
10.255. fio L8/ 32 AIEEE A Om OO OT 247s MaDe lp localioret OO; trom 
10,255. 71,15 
INS) joeiielag If 


> Wile SO=-2/1/0.0, Busin 100021, Pusin LOOOLI (ices) 
10,255 .245,245/32 “(PREP/LI0] OOsO8s3S, localermee 100 
MS. joeuclag 2 IL 
S tO 10.39,1.5 wie so-5/1/0.0 
10,255,245 246/32 “(OSE /1O]) OOSO7e24, imeierese il 
> Wie SO-7/3/1.0 
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| show ted database 


List of Syntax 
Syntax on page 2452 
Syntax (EX Series Switches) on page 2452 


Syntax 


show ted database 

<brief | detail | extensive> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 
<system-name> 

<topology-id topology bgp-ls-epe> 


Syntax (EX Series Switches) 


show ted database 
<brief | detail | extensive> 
<system-name> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 

instance instance-name option added in Junos OS Release 15.1. 

topology-id topology option added in Junos OS Release 17.4R1 for MX Series and PTX Series. 


Description 


Display the entries in the Multiprotocol Label Switching (MPLS) traffic engineering database. 


Options 


none—Display standard information about all entries in the traffic engineering database. 
brief | detail | extensive—(Optional) Display the specified level of output. 


instance instance-name—(Optional) Display routing instance information for the specified instance. If 
instance-name is omitted, information is displayed for the master instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


system-name—(Optional) Display traffic engineering database information for a particular system. 


topology-id topology— Display the topology information. By default, traffic engineering topology information 
is displayed. 


Required Privilege Level 


view 


List of Sample Output 

show ted database brief on page 2456 

show ted database detail on page 2457 

show ted database extensive on page 2458 

show ted database topology-id igp on page 2461 

show ted database topology-id bgp-Is-epe extensive on page 2462 


Output Fields 
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Table 72 on page 2453 describes the output fields for the show ted database command. Output fields are 
listed in the approximate order in which they appear. 


Table 72: show ted database Output Fields 


Field Name 


TED database 


NodelD 


Type 


Age(s) 


Lnkin 


LnkOut 


Protocol 


Field Description 


Number of nodes and pseudonodes participating in IS-IS and OSPF domain 


routing. 


Hostname and address of the node that the link is coming from. An address 
of .00 indicates that the node is the routing device itself. An address in 
the range 0.01 through 0.FF indicates that the node is a pseudonode. If 
the node contains a router ID, it is displayed in parentheses. 


Hostname and address of the node that the link is coming from. An address 
of .00 indicates that the node is the routing device itself. An address in 
the range 0.01 through 0.FF indicates that the node is a pseudonode. 
Type of node. It can be either Rtr (router) or Net (pseudonode). 

How long since the node was last refreshed, in seconds. 

Number of nodes pointing toward this node. 


Number of nodes to which this node points. 


Protocol that reported the node information: 


e 1S-IS(1)—IS-IS Level 1. 
e 1S-IS(2)—IS-IS Level 2. 
e OSPF (area-number)—OSPF from the specified area. 


Address on the far end of a link. 


Level of Output 


All levels 


brief 


extensive 


All levels 


All levels 


All levels 


All levels 


All levels 


detail extensive 


Table 72: show ted database Output Fields (continued) 


Field Name 


Local 


Remote 


Local interface 
index 


Remote interface 
index 


Metric 


IGP metric 


Static BW 


Reservable 
bandwidth 


Available BW 
[priority] 


Diffserv-TE BW 


Model 


Available BW 
[TE-class] 


Static BW 
[CT-class] 


Field Description 


Address of the local interface being used to reach the remote node. 


Address of the interface on the remote node. 


The interface indexes enable Junos OS to support unnumbered extensions 
for IS-IS, as described in RFC 4205. 


The interface indexes enable Junos OS to support unnumbered extensions 
for IS-IS, as described in RFC 4205. 


Configured traffic engineering metric. 

Configured interior gateway protocol metric. 

Total interface bandwidth in bps. 

Subscription factor for the interface, which is the percentage of the link 
bandwidth that can be used for the RSVP reservation process. You 
configure this by including the subscription statement when configuring 
RSVP. 

(Must include diffserv-te statement when configuring LSPs) Amount of 
bandwidth actually reserved by RSVP for each priority level. The 
bandwidth shown is for the entire interface, not for each individual LSP. 
Bandwidth constraint model used by the LSPs. 

(Must include the diffserv-te statement when configuring LSPs) Amount 


of bandwidth actually reserved by RSVP for each traffic engineering class. 


Total interface bandwidth used by an MPLS traffic class, in bps. 
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Level of Output 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 


extensive 
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Table 72: show ted database Output Fields (continued) 


Field Name 


Interface 
Switching 
Capability 
Descriptor (n) 


Field Description Level of Output 


Information about the interface switching capability descriptor, whichis | extensive 


a subtype length value (TLV) of the link TLV. n is the index number. 


e Switching type—Type of switching to be performed ona particular link: 
e PSC-1—Packet switch-capable 1 
e PSC-2—Packet switch-capable 2 
e PSC-3—Packet switch-capable 3 
e PSC-4—Packet switch-capable 4 
e L2SC—Layer-2-switch-capable 
e TDM—Time-division-multiplexing-capable 
e LSC—Lambda switch-capable 
e FSC—Fiber switch-capable 


e Encoding type—Encoding of the LSP being requested: 
e Packet 
e Ethernet 
e ANSI/ETSI PDH 
e Reserved 
e SDH /SONET 
e Digital Wrapper 
e Lambda (photonic) 
e Fiber 
e FiberSDH/SONET 
e Maximum LSP BW [priority] bpbs—Maximum LSP bandwidth information. 


Amount of bandwidth actually reserved for each priority level. The 
bandwidth shown is for the entire interface. 


e [n]—Priority level. The range is from 0 (high) through 7 (low). 
e n Mbps—Amount of the maximum bandwidth. 

e Minimum LSP BW—Minimum LSP bandwidth in Mbps. Amount of 
bandwidth actually reserved for each priority level. The bandwidth 


shown is for the entire interface. Minimum LSP BW is displayed only 
when switching type is PSC-1 or TDM. 


e Interface MTU—Displayed only when switching type is TDM. 


e Interface supports standard SONET/SDH-—Displayed only when 
switching type is TDM. 


| Sample Output 


show ted database brief 


user@host> show ted database brief 


at 
I 


ED database: 


DZS rSenedes 





D 


Router-A.00 


Router-B.00 


Router-B.02 


Tos Router—A,0U0, Local: 
Local interface index: 
ioe Router—BU0U, Local: 
Local interface index: 
ID 
Router-C.00 
Router-C.02 
To: Router-B.0U, Local: 
Local interface index: 
io: Routler—C.00, Local: 
Local interface index: 
ID 
Router-D.00 
Router-D.02 
Toe Router-F.0U, Local: 
Local interface index: 
to: Rowter—-D.00, Local: 
Local interface index: 
ID 
Router-D.03 
tof Router=pD 00, Local: 
Local interface index: 
foc Router—C,00, hocal: 
Local interface index: 
ID 
Router-E.00 
Router-E.02 
toe Router-A.00, ocal: 
Local interface index: 
fo: Router—E.00; Gocal: 
Local interface index: 
























































ID 


Router-F.00 


Router-F.02 


0 INET nodes 



































Type Age(s) LnkIn LnkOut 
ae SLT 2 
oS 3152 2 
Net 802 0 
0.0.0.0, Remote: 0.0.0.0 
0, Remote interface index: 
0.0.0.0, Remote: 0.0.0.0 
0, Remote interface index: 
Type Age(s) LnkIn LnkOut 
a S126 2 
Net 38 0 
0.0.0.0, Remote: 0.0.0.0 
0, Remote interface index: 
0.0.0.0, Remote: 0.0.0.0 
0, Remote interface index: 
Type Age(s) LnkIn LnkOut 
Ss 3144 z 
Net V23 0 
0.0.0.0, Remote: 0.0.0.0 
0, Remote interface index: 
0.0.0.0, Remote: 0.0.0.0 
0, Remote interface index: 
Type Age(s) LnkIn LnkOut 
Net 607 0 
0.0.0.0, Remotes 0.0.0.0 
0, Remote interface index: 
0.0.0.0, Remote: 0.0.0.0 
0, Remote interface index: 
Type Age(s) LnkIn LnkOut 
SSS SLs} 2 
Net Aa 0 
0.0.0.0, Remote: 0.0.0.0 
0, Remote interface index: 
0.0.0.0, Remote: 0.0.0.0 
0, Remote interface index: 
Type Age(s) LnkIn LnkOut 
SS SLOSS Zz 
Net 7169 0 
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PROCOCOL 

0 

0 

A IS=1S (2) 


0 


0 
EaOwocorls 

0 

2 ISLS (2) 


0 


0 
EROwocorls 

0 

2 LS=1S (2) 


0 


0 
PrOEoCcor 
2 LS=uS (2) 


0 


0 
PEOCOCOL 

0 

2 ESL (2) 


0 


0 
PEOCOCOL 

0 

2 TS=-1S8 (2) 
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oO: Router—-f.00, Local: 0.0.0.0, Remote: 0.0.0.0 








Local interface index: 0, Remote interface index: 0 


To! Router=F 00, Bocal: 0.0.0.0, Remotes 0.0.0.0 














Local interface index: 0, Remote interface index: 0 


show ted database detail 


TED database: 12 ISIS nodes 0 INET nodes 








aD) Type Age(s) LnkIn LnkOut Protocol 
Router-A.00 SSS ALS} 2 0 
Router-B.00 = 2887 2 0 
Router-B.02 Net Swi 0 2 ISS (2) 


fo: Router=A.00, Local: 0.0.0.0, Remote: 0.0.0.0 
Local interface index: 0, Remote interface index: 0 


To: Rowter=—B..00, Locals 0.0.0.0, Remote: 0.0.0.0 














Local interface index: 0, Remote interface index: 0 


ID Type Age(s) LnkIn LnkOut Protocol 
Router-C.00 a= 2861 2 0 
Router-C.02 Net 57 0 2 IS 1S (2) 


To: Romter=-B,.00, Local: 0.0.0.0, Remotes 0.0.0.0 
Local interface index: 0, Remote interface index: 0 


toe Router—C.00, Gocal: 0.0.0.0, Remotes 0.0.0.0 














Local interface index: 0, Remote interface index: 0 





ID Type Age(s) LnkIn LnkOut Protocol 
Router-D.00 === 2879 2 0 
Router-D.02 Net 458 0 2 £S-1ot2 


to: Router=-F 00, Local: 0.0.0.0, Remotes 0.0.0.0 
Local interface index: 0, Remote interface index: 0 


fo: Rowter—-D,00, Local: 0.0.0.0, Remotes 0.0.0.0 











Local interface index: 0, Remote interface index: 0 





aD) Type Age(s) LnkIn LnkOut Protocol 
Router-D.03 Net 342 0 2 LSS (2) 
ios Router—D,00, Locals 0.0.0.0, Remote: 0.0.0.0 

Local interface index: 0, Remote interface index: 0 


io: Rowuter-—C.00, Local: 0.0.0.0, Remote: 0.0.0.0 














Local interface index: 0, Remote interface index: 0 





TD Type Age(s) LnkIn LnkOut Protocol 
Router-E.00 SSS AOL B 0 
Router-E.02 Net 640 0 2 TS-15 2) 





Tos Router-—A,00, Local: 0.0.0.0, Remote: 0.0.0.0 
Local interface index: 0, Remote interface index: 0 


fo: Router-E.00, Local: 0.0.0.0, Remote: 0.0.0.0 




















Local interface index: 0, Remote interface index: 0 





TD Type Age(s) LnkIn LnkOut Protocol 
Router-F.00 == 2888 2 0 
Router-F.02 Net 504 0 2 LSS (2) 


o- Router-E 00), Local: O10.0.00, Remotes 0.0.0.0 








Local interface index: 0, Remote interface index: 0 
io: Rowter-F.00, Local: 0.0.0.0, Remote: 0.0.0.0 














Local interface index: 0, Remote interface index: 0 





show ted database extensive 


user@host> show ted database extensive 


TED database: 12 ISIS nodes 0 INET nodes 























NodeID: Router-A.00 

ype: —=--, Age: S067 secs, Lankin: 27° LinkOut: 0 
NodeID: Router-B.00 

Type: ---, Age: 3041 secs, LinkIn: 2, LinkOut: 0 
NodeID: Router-B.02 

Type: Net, Age: 691 secs, LinkIn: 0, LinkOut: 2 

Protocol: fse—iS(7) 

Tos Router—A.0U, Local: 0.0.0.0, Remotes 0.0.0.0 
Local interface index: 0, Remote interface index: 0 
Metric: 0 
IGP metric: 10 
Interface Switching Capability Descriptor(1): 

Switching type: Packet 
Encoding type: Packet 
aximum LSP BW [priority] bps: 








[0] Obps {1] Obps [2] Obps [3] Obps 
[4] Obps [5] Obps [6] Obps [7] Obps 
ios Router—B. 00, Local: 0.0.0.0, Remote: 0.0.0.0 
Local interface index: 0, Remote interface index: 0 
Metric: 0 


GP em cite rssker 20) 


In 


terface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 


[0] Obps {1] Obps Pale Obps Poles 
[4] Obps [5] Obps [6] Obps [7] Obps 
NodeID: Router-C.00 
iyses ===, Weer SOIS sees, Initimkiing 2, Iniimkoules 0 
NodeID: Router-C.02 
Type: Net, Age: 751 secs, LinkIn: 0, LinkOut: 2 
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Prococol. To-Lai2) 
Tes Router-B.0U, Local: 0.0.0.0, Remote: 0.0.0.0 


Local interface index: 0, Remote interface index: 0 





Metric: 0 

IGP metric: 10 

Interface Switching Capability Descriptor(1): 
Switching type: Packet 

Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] Obps {1] Obps LZ] Olsyos Pole Olbps: 
[4] Obps [5] Obps [6] Obps [7] Obps 
Too Router—C,00, Local: 0.0.0.0, Remote: 0.0.0.0 





Local interface index: 0, Remote interface index: 0 


Mainieses (0) 


IGP metric: 10 Interface Switching Capability Descriptor(1): 
Switching type: Packet 


Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] Obps {1] Obps [2] Obps [3] Obps 


[4] Obps [5] Obps ole Olas: Alen Olloros) 
NodeID: Router-D.00 


ype: ---, Age: 3034 secs, LinkIn: 2, LinkOut: 0 
NodeID: Router-D.02 





Type: Net, Age: 613 secs, LinkIn: 0, LinkOut: 2 
Prococol: To-[Si2) 


ioe Router-F 00, Locals: 0.0.0.0, Remotes 0.0.0.0 





Local interface index: 0, Remote interface index: 0 
Metric: 0 

IGP metric: 10 

Interface Switching Capability Descriptor(1): 
Switching type: Packet 

Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] Obps {1] Obps le Olops: Pol Obps 
[4] Obps [5] Obps [6] Obps [7] Obps 
foo Router-D,00, Gocal: 0.0.0.0, Remote: 0.0.0.0 


Local interface index: 0, Remote interface index: 0 





Metric: 0 

IGP metric: 10 

Interface Switching Capability Descriptor(1): 
Switching type: Packet 

Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] Obps {1] Obps LZ] Olsyos LS] Olsyos 
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[4] Obps [5] Obps [6] Obps [7] Obps 
NodeID: Router-D.03 


Type: Net, Age: 497 secs, LinkIn: 0, LinkOut: 2 
Protocol: fe-is (7) 


too Router—-D. 00, Gocal: 0.0.0.0, Remote: 0.0.0.0 





Local interface index: 0, Remote interface index: 0 
Metric: 0 

IGP metric: 10 

Interface Switching Capability Descriptor(1): 
Switching type: Packet 

Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] Obps {1] Obps [2] Obps [3] Obps 
[4] Obps [5] Obps [6] Obps [7] Obps 
Tot Router=—C..00, Bocal: 0.0.0.0, Remotes 0.0.0.0 
Local interface index: 0, Remote interface index: 0 
Metric: 0 
IGP metric: 10 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] Obps {1] Obps [2] Obps [3] Obps 
[4] Obps [5] Obps [6] Obps [7] Obps 
NodeID: Router-E.00 


Wises --—=, Ages 2063 sees, ibimkiins 2, LimkOuies O 
NodeID: Router-E.02 








Type: Net, Age: 21 secs, LinkIn: 0, LinkOut: 2 
Prococoly fo—-£Si2) 
To: Router=A.00, Local: 0.0.0.0, Remote: 0.0.0.0 


Local interface index: 0, Remote interface index: 0 





Metric: 0 

Interface Switching Capability Descriptor(1): 
Switching type: Packet 

Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] Obps {1] Obps [2] Obps [3] Obps 
[4] Obps [5] Obps [6] Obps [7] Obps 
Tot Router=—.00, Gocal: 0.0.0.0, Remote: 0::0.0..0 





Local interface index: 0, Remote interface index: 0 

Metric: 0 

IGP metric: 10 

Interface Switching Capability Descriptor(1): 
Switching type: Packet 


Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] Obps {1] Obps al Obps 
[4] Obps [5] Obps [6] Obps 
NodeID: Router-F.00 


Wises ===, Meee SW4AS sees, Iams 2, IiiMkOulics 0 
NodeID: Router-F.02 





Type: Net, Age: 659 secs, LinkIn: 0, LinkOut: 2 
Provocol. fe-iS (7) 





To: Rowter=——).00, Local: 0.0.0.0, Remote? 0.0.0.0 





Local interface index: 0, Remote interface ind 
Metric: 0 

IGP metric: 10 

Interface Switching Capability Descriptor(1): 
Switching type: Packet 

Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] Obps {1] Obps [2] Obps 
[4] Obps [5] Obps [6] Obps 
Tot Router=F 00, Local: 0.0.0.0, Remote? 0.0.0.0 





Local interface index: 0, Remote interface ind 
Metric: 0 

IGP metric: 10 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] Obps {1] Obps ale Obps: 
[4] Obps [5] Obps [6] Obps 


show ted database topology-id igp 


user@host> show ted database topology-id igp 


TED database: 3 ISIS nodes 3 INET nodes 








ID Type Age(s) LnkIn LnkOu 
ROpESIE A OO CLAS .440)5 1152) Riera 193 B 


toe Router 2 -0U0tiz co. 2 Uo lo), Boca 2.5. Ure, 


LS] Olsyss) 

ale Olos: 
xe (0) 

[3] Obps 

[7] Obps 
se (0) 


Interface Switching Capability Descriptor(1): 


LS] Olas 
[7] Obps 


& PKOCOCOL 
2 WSS; (2) 
Remote 2.5. 0l 





Local interface index: 334, Remote interface in 


toe Router 2 OUgIizc. 220. oo), Bocals 2.55 tec, 











dex: 336 
Nemionces 2. Siz il, il 





Local interface index: 333, Remote interface in 
ID Type Age(s) LnkIn LnkOu 
Romer © .00 (23.220 , il, 52) Rtr 193) Z 


toe Router Buus. 220.16 195), hocal: 2.2.0.1, 


dex: 335 

EO wOCons 

2 IS=118 (2) 
Remote: 1.2.0.2 








Local interface index: 335, Remote interface in 


dex: 334 
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1o: Router B.00(126.2720.16.198), Locals Li2.tel, Remore: 1.2.1.2 





Local interface index: 334, Remote interface index: 333 
ID Type Age(s) LnkIn LnkOut Protocol 
ine@wicee 8) OO (I28. 220. 13.193) ites Los 4 ASSES S12) 
fo: Router A.OO(IZ6.220.,1.2), Local: 2.5.0.1, Remote: 2.3.0.2 





Local interface index: 336, Remote interface index: 334 

or Router A,O0I26.220.1.2), Local: 2.3,1.1, Remote: 2.2.1.2 
Local interface index: 335, Remote interface index: 333 

of Souler CL U0(I2s.220 1057), tocals 1.2,0.2, Remore: 1.2.0.1 








Local interface index: 334, Remote interface index: 335 


or Router ©.00U126,220, 1252), hocals L.2.1l.2, Bemoce: 1.2.1.4 






































Local interface index: 333, Remote interface index: 334 





show ted database topology-id bgp-Is-epe extensive 


user@host> show ted database topology-id bgp-ls-epe extensive 


TED database: 0 ISIS nodes 3 INET nodes 
Neder AA << DIU ieee eie—akl 








yj: Rtn, Age: 2 JO SeCs;lalnicin Oe lmk © sss 














Protocol: BGP-LS—-EPE (0) =< Protocol 
tos 5.5.5.5, wooals SO 1.1.1, Ramoces: SO,1,1,2 << Pesce mouleer—iiel aie! Iloe@ail aime! 


remote interface used for BGP session. 








Local interface index: 0, Remote interface index: 0 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 

Encoding type: Packet 





aximum LSP BW [priority] bps: 


[0] Obps {1] Obps [2] Obps LS] Oss 
[4] Obps [5] Obps [6] Obps [7] Obps 
BGP-Peer-SID: << BGP-Peer-SID Information 


SID: 1000007, Type: Node-SID Flags: 0x30, Weight: 0 << BGP-Node-SID 
SID: 1000002, Type: Set-SID Flags: 0x30, Weight: 0 << BGP-Set-—SID 
foo Jot. 2l, hocel= 4.4,4.4, RPemore: 7.7, 7.7 








Local interface index: 0, Remote interface index: 0 
Interface Switching Capability Descriptor(1): 
Switching type: Packet 

Encoding type: Packet 





aximum LSP BW [priority] bps: 
[0] Obps {1] Obps [2] Obps [3] Obps 
[4] Obps [5] Obps [6] Obps [7] Obps 
BERS Re crs Osi 
SID: 1000006, Type: Node-SID Flags: 0x30, Weight: 0 << BGP-Node-SID 
Toe fol.) i, Local: 4.4.4.4, Remoter 1.7). i. 
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Local interface index: 339, Remote interface index: 0 





Interface Switching Capability Descriptor(1): 
Switching type: Packet 
Encoding type: Packet 





aximum LSP BW [priority] bps: 

[0] Obps {1] Obps [2] Obps [3] Obps 

[4] Obps [5] Obps [6] Obps [7] Obps 

BEE Se crs onsbr 
SID: 1000005, Type: Adj-SID Flags: 0x30, Weight: 0 << BGP-ADj-SID 

NOCSIDS B.86558 

Iyees Rew, Neer 2/0 Sees, iainliins i, waimowies (0) 

Protocol: BGP-LS—-EPE (0) 
WoceIDe Wools 7 














Type: Rtr, Age: 270 secs, LinkIn: 2, LinkOut: 0 
Protocol: BGP-LS—-EPE (0) 
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| show ted link 


List of Syntax 
Syntax on page 2464 
Syntax (EX Series Switches) on page 2464 


Syntax 


show ted link 

<brief | detail> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


show ted link 
<brief | detail> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
instance instance-name option added in Junos OS Release 15.1. 


Description 


Display Multiprotocol Label Switching (MPLS) traffic engineering database link information. 


Options 


none—Display standard information about traffic engineering database link information. 
brief | detail—(Optional) Display the specified level of output. 


instance instance-name—(Optional) Display routing instance information for the specified instance. If 
instance-name is omitted, information is displayed for the master instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


List of Sample Output 

show ted link brief on page 2466 

show ted link detail on page 2466 

show ted link topology-id bgp-ls-epe detail on page 2467 


Output Fields 
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Table 73 on page 2465 describes the output fields for the show ted link command. Output fields are listed 


in the approximate order in which they appear. 


Table 73: show ted link Output Fields 


Field Name 


ID 


-->ID 


hostname 


hostname 


Local Path 


Metric 


IGP metric 


Local BW 


Local 


Remote 


Local interface 
index 


Remote interface 
index 


Field Description 

Hostname and address of the node that the link is coming from. An address 
of .00 indicates that the node is the routing device itself. An address in 
the range 0.01 through 0.FF indicates that the node is a pseudonode. 
Hostname and address of the node that the link is going to. An address 
of .00 indicates that the node is the routing device itself. An address in 
the range 0.01 through 0.FF indicates that the node is a pseudonode. 
Hostname and address of the node that the link is coming from. An address 
of .00 indicates that the node is the routing device itself. An address in 
the range 0.01 through 0.FF indicates that the node is a pseudonode. 
Hostname and address of the node that the link is going to. An address 
of .00 indicates that the node is the routing device itself. An address in 
the range 0.01 through O.FF indicates that the node is a pseudonode. 
Number of paths CSPF on the local routing device has placed on the link. 
Configured traffic engineering metric. 

Configured interior gateway protocol metric. 

Amount of bandwidth the local routing device has placed on the link. 
Address of the local interface being used to reach the remote node. 


Address of the interface on the remote node. 


The interface indexes enable Junos OS to support unnumbered extensions 
for IS-IS, as described in RFC 4205. 


The interface indexes enable Junos OS to support unnumbered extensions 
for IS-IS, as described in RFC 4205. 


Level of Output 


brief 


brief 


detail 


detail 


All levels 


extensive 


detail 


All levels 


detail extensive 


detail extensive 


detail 


detail 
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| Sample Output 


show ted link brief 


user@host> show ted link brief 








ID => ID) LocalPath LocalBW 

Router-B.02 Router-A.00 0 Obps 
Router-B.02 Router-B.00 0 Obps 
Router-C.02 Router-B.00 0 Obps 
Router-C.02 Router-C.00 0 Obps 
Router-D.02 Router-F.00 0 Obps 
Router-D.02 Router-D.00 0 Obps 
Router-D.03 Router-D.00 0 Obps 
Router-D.03 Router-C.00 0 Obps 
Router-E.02 Router-A.00 0 Obps 
Router-E.02 Router-E.00 0 Obps 
Router-F.02 Router-E.00 0 Obps 
Router-F.02 Router-F.00 0 Obps 




















show ted link detail 


user@host> show ted link detail 





Router-B.02->Router-A.00, Local: 0.0.0.0, Remote: 0.0.0.0 





Local interface index: 0, Remote interface index: 0 





LocalPath: 0, Metric: 0, IGP metric: 10 AvailBW: Obps 
localBW [0] Obps [EI NObps [2] Obps 3] Obps 
localBW [4] Obps [5] Obps [6] Obps 7] Obps 
Router-B.02->Router-B.00, Local: 0.0.0.0, Remote: 0.0.0.0 








Local interface index: 0, Remote interface index: 0 





LocalPath: 0, Metric: 0, IGP metric: 20 AvailBW: Obps 
localBW [0] Obps EI Obes [2] Obps 3] Obps 
localBW [4] Obps [5] Obps [6] Obps mObE Ss 
Router-C,.02=>Router-B.00, Local: 0.0.0.0, Remote: 0.0.0.0 





Local interface index: 0, Remote interface index: 0 








LocalPath: 0, Metric: 0, IGP metric: 40 AvailBW: Obps 
localBW [0] Obps [1] Obps [2] Obps Si 0bps 
localBW [4] Obps [5] Obps [6] Obps 7] Obps 
Router—C.02-sRouter-C.00, Local: 0.0.0.0, Remote: 0.0.0.0 





Local interface index: 0, Remote interface index: 0 








LocalPath: 0, Metric: 0, IGP metric: 10 AvailBW: Obps 
localBW [0] Obps [1] Obps [2] Obps 3] Obps 
localBW [4] Obps [5] Obps [6] Obps 7] Obps 











Router—D.02--Rovter—/.00, Local: 0.0.0. 





local 


local 


Local 


Local 


BW [0] Obps 
BW [4] Obps 





Router 





local 


local 


Local 


Local 


interface index: 


Path: 0, Metric: 


[1] 
[5] 


0, Remote int 


0, Remote: 0.0.0.0 


riace index: 0 





O, Ine jmeierailes 
Obps PZ Obes 
Obps [6] Obps 


D.02—sRoucer—D.00, Locals 020.0. 


BW [0] Obps 
BW [4] Obps 





Router 





local 


lkowanls 


LOCcaL 


Local 


interface index: 


Path: 0, Metric: 


[1] 
[5] 


0, Remote int 


10 AvailBW: Obps 
3] Obps 

7] Obps 

0, Remote: 0.0.0.0 


miteyer) slincles<s (0) 





OQ, INE jmeie rile? 
Obps PZ Obes 
Obps [6] Obps 


D.0S=sRoucer= D.00, Locals 0.0.0. 


BW [0] Obps 
BW [4] Obps 





Router 





local 


local 


Local 


Local 


interface index: 


Path 0, Metric: 


ea 
[5] 


60 AvailBW: Obps 
SieObes 

7] Obps 

0, Remote: 0.0.0.0 





0, Remote int 
0, IGP metric: 
Obps PZ Obps 
Obps folmObps: 


Di 03-SRouter-C.00, Locals 0.0.0. 


BW [0] Obps 
BW [4] Obps 





Router 





local 


local 


Local 


LOCaL 





BW [0] Obps 
BW [4] Obps 





Router 





local 


local 


Local 


Local 


E.02->Router 





BW [0] Obps 
BW [4] Obps 





Router 





local 


local 


Local 


Local 


F.02->Router 


BW [0] Obps 
BW [4] Obps 





Router 





Loca 


local 


Local 


interface index: 


Path: 0, Metric: 


[1] 
[5] 


interface index: 


Paula) mMe trea er 


[1] 
[5] 





interface index: 


Path: 0, Metric: 


[1] 
[5] 





interface index: 


Path: 0, Metric: 


[1] 
[5] 


0, Remote int 


rface index: 0 

10 AvailBW: Obps 
3] Obps 

7] Obps 

0, Remote: 0.0.0.0 


miter slincles<s 0) 





0, IGP metric: 
Obps Flops: 
Obps [6] Obps 


BE, 02—>Router—A.00, Locals 0.0.0. 


10 AvailBW: Obps 
3] Obps 

7] Obps 

0, Remote: 0.0.0.0 


0, Remote interface index: 0 


0, IGP metric: 
Obps FleOloes: 
Obps [6] Obps 


00, hocails O.0.0. 


60 AvailBW: Obps 
3] Obps 

7] Obps 

0, Remote: 0.0.0.0 


0, Remote interface index: 0 


0, IGP metric: 
Obps [2] Obps 
Obps [6] Obps 


1,00, locals O.0.0. 


20 AvailBW: Obps 
3] Obps 

7] Obps 

0, Remote: 0.0.0.0 


rface index: 0 





0, Remote int 
0, IGP metric: 
Obps [2] Obps 
Obps [6] Obps 


F.02-sRoucer-F.00, Local: 0.0.0. 


l\Path: 0, Metric: 


LBW [0] Obps 





local 


LBW [4] Obps 


interface index: 


[1] 
[5] 


0, Remote int 


10 AvailBW: Obps 
3] Obps 

7] Obps 

0, Remote: 0.0.0.0 


asia © Cumann) 





0, IGP metric: 
Obps [2] Obps 
Obps [6] Obps 


show ted link topology-id bgp-ls-epe detail 


user@host> show ted link topology-id 


40 AvailBW: Obps 
3] Obps 
7] Obps 





bgp-ls-epe detail 


2467 


AAA 4=25.5.525, Locals S0,1.1.1, Remote: SOQ... 





LocalPath: 0, AvailBW: Obps 


Local interface index: 0, Remote interface index: 0 


localBW [0] Obps LL] loyoxs: LZ Obes [3] Obps 
localBW [4] Obps [5] Obps [6] Obps iimO bps 


SID: 1000007 Type: Node-SID Flags: 
SID: 1000002 Type: Set-SID Flags: 





0x30 Weight: 
0x30 Weight: 


Ae A ASO leigilai, Bocal< 4,4,4.4, Bemote: Feist. 





LocalPath: 0, AvailBW: Obps 


Local interface index: 0, Remote interface index: 0 


localBW [0] Obps [1] Obps [2] Obps [3] Obps 
localBW [4] Obps [5] Obps [6] Obps iO s 


SID: 1000006 Type: Node-SID Flags: 


0x30 Weight: 0 











Aa Aeolian. i, Gocal: 4.4.4.4, Remote: 7.7.7.7 
Local interface index: 339, Remote interface index: 
LocalPath: 0, AvailBW: Obps 
localBW [0] Obps [1] Obps [2] Obps ISO bes 
localBW [4] Obps [5] Obps [6] Obps [7] Obps 


SID: 1000005 Type: Adj-SID Flags: 


0x30 Weight: 0 


0 
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| show ted protocol 


List of Syntax 
Syntax on page 2469 
Syntax (EX Series Switches) on page 2469 


Syntax 


show ted protocol 

<brief | detail> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


show ted protocol 
<brief | detail> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
instance instance-name option added in Junos OS Release 15.1. 


Description 
Display information about the protocols from which the Multiprotocol Label Switching (MPLS) traffic 
engineering database learned about its nodes. 


Options 
none—Display standard information about the protocols from which the traffic engineering database 
learned about its nodes. 


brief | detail—(Optional) Display the specified level of output. 


instance instance-name—(Optional) Display routing instance information for the specified instance. If 
instance-name is omitted, information is displayed for the master instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


List of Sample Output 
show ted protocol on page 2470 
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Output Fields 
Table 74 on page 2470 describes the output fields for the show ted protocol command. Output fields are 
listed in the approximate order in which they appear. 


Table 74: show ted protocol Output Fields 


Field Name Field Description 


Protocol name Protocol that reported the node information: 


e 1IS-1S(1)—IS-IS Level 1. 
e 1S-IS(2)—IS-IS Level 2. 
e OSPF (area-number)—OSPF from the specified area. 


Credibility If the protocols provide conflicting information about a node, the protocol 
with the highest credibility value is the one that the traffic engineering 


database uses. 


Self node Address the protocol uses as the local address. 


| Sample Output 


show ted protocol 


user@host> show ted protocol 


Protocol name Credibility Self node 
iS-fs (2) 2 (highest) corriedale.00(123.456.1.11) 
Myers (ls sf corriedale.00(123.456.1.11) 


user@host> show ted protocol topology-id bgp-ls-epe detail 


Protocol name Credibility Self node 
BGP-LS-EPE (0) 342 200.0.0.4 
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| traceroute mpls bgp 


Syntax 


traceroute mpls bgp fec 

<destination destination-address> 
<detail> 

<exp exp> 

<fanout fanout-number> 
<logical-system logical system-name> 
<no-resolve> 

<paths paths-number> 

<pipe-mode> 

<retries retries-number> 
<routing-instance routing-instance-name> 
<source source-address> 

<ttl value> 

<wait seconds> 


Release Information 
Command introduced in Junos OS Release 14.2. 


Description 

Trace route to a remote host for an MPLS label-switched path (LSP) signaled by the Border Gateway 
Protocol (BGP). Use traceroute mpls bgp as a debugging tool to locate MPLS BGP forwarding issues in a 
network. (Currently supported for IPv4 packets only.) 


To use the traceroute mpls bgp command, make sure you have BGP routes with MPLS labels. 


NOTE: The traceroute mpls bgp fec command only supports single paths. 


Options 
fec—Specify the IP address and optional prefix of the forwarding equivalence class (FEC). Suppose you are 
at PE1, use would want to use the IP address of PE2 to trace the BGP path to that router. 


destination destination-address—(Optional) Specify the destination address to use when sending probes. 
detail—(Optional) Display detailed output. 


exp exp—(Optional) Specify the class of service to use when sending probes. 
Range: O through 7 
Default: 7 
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fanout fanout-number—(Optional) Specify the maximum number of next hops to search per node. 
Range: 1 through 16 
Default: 16 


logical-system logical-system-name—(Optional) Specify the name of the logical system for the traceroute 
attempt. 


no-resolve—(Optional) Specify not to resolve the hostname that corresponds to the IP address. 


paths paths-number—(Optional) Specify the number of paths to search. 
Range: 1 through 255 
Default: 16 


pipe-mode—(Optional) Specify to trace only the outermost FEC. 


retries retries-number—(Optional) Specify the number of times to resend probe values. 
Range: 1 through 9 
Default: 3 


routing-instance routing-instance-name—(Optional) Specify the name of the routing instance for the trace 
route attempt. 


source source-address—(Optional) Specify the source address of the outgoing traceroute packets. 


ttl value—(Optional) Specify the maximum time-to-live value to include in the traceroute request, in seconds. 
Range: 1 through 125 
Default: 64 


wait seconds—(Optional) Specify the number of seconds to wait before resending a probe. 
Range: 5 though 15 
Default: 10 


Required Privilege Level 
network 


RELATED DOCUMENTATION 


ping mpls bgp | 2285 


List of Sample Output 
traceroute mpls bgp on page 2473 
traceroute mpls bgp detail on page 2474 


Output Fields 
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Table 75 on page 2473 describes the output fields for the traceroute mpls bgp fec command and the traceroute 
mpls bgp fec detail command. Output fields are listed in the approximate order in which they appear. 


Table 75: traceroute mpls bgp Output Fields 


Field Name Field Description Level of Output 
Probe options Probe options specified in the traceroute mpls bgp fec command. | All levels 

ttl Time to live value of the labeled packet. None 

Label Outgoing label used for forwarding the packet along the None 


label-switched paths. 


Protocol Signaling protocol used. For this command, it is BGP. None 

Address Address of the next hop. None 

Previous Hop Address of the previous hop. Previous hop address of the first hop | None 
is null. 

Probe status Forwarding status from the first hop to the last-hop label-switching | None 


router (egress point in the label-switched paths). 


Hop Address of the hops in the label-switched path from the first hop | detail 
to the last hop. Depth indicates the level of the hop. 


Parent Address of the previous hop. Parent value for the first hop is null. | detail 


Return Code Return code for reporting the result of processing the echo request | detail 
by the receiver. 


Response time Time for the echo request to reach the receiver. detail 


Multipath type Labels or addresses used by the specified multipath type. If detail 
multipaths are not used, the value is none. 


Label Stack Label stack used to forward the packet. detail 


| Sample Output 


traceroute mpls bgp 


user@host> traceroute mpls bgp fec 


Probe options: retries 3, exp 7 


ttl Label Protocol Address 


299824 LDP 
DONS 25)  INSNAZ 
299826 RSVP 
299826 LDP 
29907) ewe 
AEA I NGI 





NES MS (Ge) (Ge) [ef 


traceroute mpls bgp detail 


Sill. « 
slg 
Sil. 
Sil 
Silly. 
Sill. 6 


LeQod 


Za. 


- BW W 


36 


CoS 
OT Ol ws aS co 


Previous Hop Probe Status Fec-Stack-Sent 


(null) Success 
Sul oA ood SECIS 
Sil, 3 5355) Egress 
Hs gSia ! Success 
81.3.4.4 Egress 
Sls aeao4 Egress 





user@host> traceroute mpls bgp fec detail 


Probe options: retries 3, 


HOS 25251 68. Bey, Silie ase 


Parent: (null) 


TU: Unknown 





ultipath type: 


Sender timestamp: 


Receiver timestamp: 


Address Range 1: 


Label Stack: 





Fec-Stack-Sent: LDP, 


Fec-Change: 
Operation: PUSH 


Probe status: Success 


( 


exp 7 
Gig. 24) Deja i 


Return code: Label switched at stack-depth 1 
AQI3=-0S=22 OS3553l9 POL 822.99 msec 
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Fec—Chang 
IID2, eve 12) PUS HOR SVP 
ROVE; GD Pee BGe (null) 
INSWie, JIDI2, Ieii2’ Qe SINS? 
LDP, BGP (null) 
LDP, BGP IOI —ILDI2) 
BGP (null) 


2OLS-OS=—22 OS2S5el9 WOE BS6,05 mee 


Response time: 33.06 msec 


IP bitmask 
127 0.0.64 = 127 .0.0.127 


Label 1 Value 299824 Protocol LDP 
Label 2 Value 299276 Protocol BGP 
BGP 


Protocol RSVP 
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| transit (Chained Composite Next Hops) 


Syntax 


transit { 
(all | no-all); 
(I2vpn | no-I2vpn); 
(I3vpn | no-I3vpn); 
(labeled-bgp | no-labeled-bgp); 
(Idp | no-Idp); 
(Idp-p2mp | no-ldp-p2mp); 
Isp-statistics-from-route; 
(rsvp | no-rsvp); 
(rsvp-p2mp | no-rsvp-p2mp); 
(static | no-static); 


Hierarchy Level 


[edit logical-systems logical-system-name routing-options forwarding-table chained-composite-next-hop], 


[edit routing-options forwarding-table chained-composite-next-hop] 


NOTE: The [edit logical-systems] hierarchy level is not supported on the QFX10000 switches. 


Release Information 
Statement introduced in Junos OS Release 12.1. 
Statement introduced in Junos OS Release 15.1 for QFX10000 Series switches. 


Description 

Allows you to configure the chained composite next hops transit configuration options for devices handling 
transit traffic in the network. This statement and the associated functionality is available only on PTX 
Packet Transport Routers and QFX10000 switches. 


Default 


All of the transit statement options are enabled on PTX transport routers and QFX10000 switches. 
However, you can disable any of the statements with a no option. 


Starting in Junos OS Release 14.1, the transit IS3vpn statement is enabled by default on PTX Series Packet 
Transport Routers only. 


Options 
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all | no-all—Enable or disable chained composite next-hops for all of the possible packet transit protocols 
and applications. The all | no-all statements do not apply to the Isp-statistics-from-route statement. 


I2vpn | no-I2vpn—Enable or disable chained composite next-hops for Layer 2 VPNs. 

I3vpn | no-I3vpn—Enable or disable chained composite next-hops for Layer 3 VPNs. 
labeled-bgp | no-labeled-bgp—Enable or disable chained composite next-hops for labeled BGP. 
Idp | no-ldp—Enable or disable chained composite next-hops for LDP. 


Idp-p2mp | no-ldp-p2mp—Enable or disable chained composite next-hops for LDP-signaled P2MP LSPs. 


NOTE: The Idp-p2mp and rsvp-p2mp statements are not supported on MX series routers. 


Onan Mx series router with redundant Routing Engines and enhanced-ip mode configuration, 
enabling the Idp-p2mp and rsvp-p2mp statements under the [edit routing-options 
forwarding-table chained-composite-next-hop transit] hierarchy level causes ping from the 
current master logical system to fail at the time of a Routing Engine switchover. 


Isp-statistics-from-route—Enable LSP statistics collection from the route. 
rsvp | no-rsvp—Enable or disable chained composite next-hops for RSVP. 


rsvp-p2mp | no-rsvp-p2mp—Enable or disable chained composite next-hops for RSVP-signaled P2MP 
LSPs. 


NOTE: The Idp-p2mp and rsvp-p2mp statements are not supported on MX series routers. 


Onan Mx series router with redundant Routing Engines and enhanced-ip mode configuration, 
enabling the rsvp-p2mp and Idp-p2mp statements under the [edit routing-options 
forwarding-table chained-composite-next-hop transit] hierarchy level causes ping from the 
current master logical system to fail at the time of a Routing Engine switchover. 


static | no-static—Chained composite next hops are enabled for transit static LSPs by default. You can also 
disable this functionality for transit static LSPs. 


Required Privilege Level 
routing—To view this statement in the configuration. 
routing-control—To add this statement to the configuration. 
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RELATED DOCUMENTATION 


Accepting Route Updates with Unique Inner VPN Labels in Layer 3 VPNs 
chained-composite-next-hop | 2005 


CHAPTER 27 


RSVP Operational Commands 


IN THIS CHAPTER 


clear rsvp session | 2479 

clear rsvp statistics | 2481 

monitor label-switched-path | 2483 
ping mpls rsvp | 2487 

show rsvp interface | 2494 

show rsvp neighbor | 2502 

show rsvp route-session-id | 2508 
show rsvp pop-and-forward | 2510 
show rsvp session | 2513 

show rsvp session | 2528 

show rsvp statistics | 2534 

show rsvp version | 2542 


traceroute mpls rsvp | 2546 
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| clear rsvp session 


List of Syntax 
Syntax on page 2479 
Syntax (EX and QFX Series Switches) on page 2479 


Syntax 


clear rsvp session 

<all> 

<connection-destination address> 
<connection-source address> 

<gracefully> 

<logical-system (all | logical-system-name)> 
<lsp-id identifier> 

<name name> 

<optimize-fast-reroute> 

<tunnel-id identifier> 


Syntax (EX and QFX Series Switches) 


clear rsvp session 
<connection-destination address> 
<connection-source address> 
<gracefully> 

<lsp-id identifier> 

<name name> 
<optimize-fast-reroute> 
<tunnel-id identifier> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
Command introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 


Reset and restart Resource Reservation Protocol (RSVP) sessions. 


Options 


all—Clear all RSVP sessions for which this routing device is the ingress, transit, or egress routing device. 


connection-source address—(Optional) Source address for GMPLS and MPLS LSPs from the RSVP sender 
template. 
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connection-destination address—(Optional) Destination address for GMPLS and MPLS LSPs from the RSVP 
sender template. 


gracefully—(Optional) Gracefully reset an RSVP session for a nonpacket LSP in two passes. In the first 
pass, the Admin-Status object is signaled along the path to the other endpoint of the RSVP session. 
In the second pass, the path used by the RSVP session is torn down. This option can only be used on 
the ingress or egress routing device of the RSVP session and is only valid for nonpacket LSPs. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Isp-id identifier—(Optional) LSP identifier (source port) for the RSVP sender template. 
name name—(Optional) Reset and restart the specified RSVP session. 
optimize-fast-reroute—(Optional) Begin fast reroute optimization. 


tunnel-id identifier—(Optional) Tunnel identifier (destination port) for the RSVP session. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 


clear mpls Isp | 2263 


show rsvp session | 2513 


List of Sample Output 
clear rsvp session all on page 2480 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 


Sample Output 


clear rsvp session all 


user@host> Clear rsvp session all 
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| clear rsvp statistics 


List of Syntax 
Syntax on page 2481 
Syntax (EX Series Switches) on page 2481 


Syntax 


clear rsvp statistics 
<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


clear rsvp statistics 


Release Information 
Command introduced before Junos OS Release 7.4. 
Command introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Clear Resource Reservation Protocol (RSVP) packet and error statistics. 


Options 


none—Clear RSVP packet and error statistics. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 


show rsvp statistics | 2534 


List of Sample Output 
clear rsvp statistics on page 2482 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 
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Sample Output 


clear rsvp statistics 


user@host> Clear rsvp statistics 
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| monitor label-switched-path 


Syntax 


monitor label-switched-path Isp-name 
<logical-system (logical-system-name)> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Logical system support introduced in Junos OS Release 9.4. 

Command introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 
Display the real-time status of the specified RSVP label-switched path (LSP). You can also use this command 
to monitor LSPs configured within logical systems. 


Options 
logical-system ( logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Isp-name—Name of the LSP. 


Additional Information 


You can track the amount of traffic traversing an RSVP LSP and observe its essential parameters, such as 
uptime, ingress and egress addresses, labels, routes, and ports. Values are typically sampled every second. 
The display also allows you to scroll to other currently running LSPs. You cannot use this command to 
display information about static LSPs or LDP-signaled LSPs. 


The output of this command shows how much each field has changed since you started the command or 
since you cleared the counters by using the c key. To control the output of the monitor label-switched-path 
command while it is running, use the keys listed in Table 76 on page 2483. The keys are not case-sensitive. 


Table 76: Output Control Keys for the monitor label-switched-path Command 


Key Action 
Cc Clears the screen and refreshes the display for this LSP. 
f Freezes the display, preventing new information from being displayed. 


Monitors a different LSP. After you type I, you can type the new LSP name. 


n Displays information about the next LSP (whose name is alphabetically higher than the current 
LSP name) configured on the router. 
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Table 76: Output Control Keys for the monitor label-switched-path Command (continued) 


Key Action 


p Goes to the previous LSP (whose name is alphabetically lower than the current LSP name) 
configured on the router. 


q or Esc Quits the command and returns to the command prompt. 


t Thaws, or restarts, the data display for this LSP. 


Required Privilege Level 
trace 


List of Sample Output 
monitor label-switched-path on page 2485 


Output Fields 
Table 77 on page 2484 describes the output fields for the monitor label-switched-path command. Output 
fields are listed in the approximate order in which they appear. 


Table 77: monitor label-switched-path Output Fields 


Field Name Field Description 


(1) Displays the following information: 


e hostname—Name of the router. 
e Seconds—Time elapsed since this display was started. 
e Time—Current local time. 
(2) Delay—Length of the time delay, in milliseconds, required to obtain the information in the 
monitor display. The first number shows the current sampling delay. The second number shows 


the shortest delay recorded to date. The third number shows the worst delay recorded to 


date. This delay can vary substantially depending on the system load. 


(3) Displays the following: 


e To—Destination address of the LSP. 
e From—Originating address of the LSP. 
e State—Current state of the LSP: Up or Down. 


(4) Displays the following: 


e LSPName—Name of the LSP. 
e Type—Type of LSP: Ingress, Egress, or Transit. 
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Table 77: monitor label-switched-path Output Fields (continued) 


Field Name 


(5) 


(6) 


(7/8) 


(9/10/11) 


(12) 


(13) 


Field Description 


Displays the following: 


e Label in—Incoming label of the LSP. 
e Label out—Outgoing label of the LSP. 


Port number—Port number for the sending router, the port number for the receiving router, 
and the protocol ID. For MPLS traffic engineering applications, the protocol ID is always 0. 


Record route—All intermediate and egress router addresses for this LSP. 


Displays traffic statistics: 


e Output packets—Number of packets that have traversed this LSP, and the change (delta) 
in the number since the last sample, typically 1 second ago. 

e Output bytes—Number of bytes that have traversed this LSP, and the change (delta) in the 
number since the last sample, typically 1 second ago. 


Displays any errors the router encountered while attempting to retrieve information on the 
LSP. 


Lists the keyboard commands you can use to navigate to other LSPs. For a description of the 
keyboard commands, see Table 76 on page 2483. 


| Sample Output 


monitor label-switched-path 


user@host> monitor label-switched-path 














iL) Inosic SeConesamlsile WagMSs Le S7 e272 
(2) Delay: 0/0/0 
5) Te LODO 10,16, ween LOO 10,17, Sicaicias Wo 

4) LSPname: k, type: Ingress 

(5) Label in: , Label out: 126000 

6) Port number: sender 1, receiver 45583, protocol 0 

(7) Record Route: <self> 192.168.224.196 

8) IZ 168, 224,202, 192168, 224) 17/2) 

(¢S}) Traffic statistics: Current delta 
(10) Output packets: 0 [0] 
(Gla) Output bytes: 0 [0] 
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| ping mpls rsvp 


Syntax 


ping mpls rsvp 

<Isp-name> 

<count count> 

<destination address> 
<detail> 

<dynamic-bypass> 

<egress egress-address> 

<exp forwarding-class> 
<interface interface-name> 
<logical-system (all | logical-system-name)> 
<manual-bypass> 
<multipoint> 

<size bytes> 

<source source-address> 
<standby standby-path-name> 


<sweep> 


Release Information 

Command introduced before Junos OS Release 7.4. 

The egress and multipoint options were introduced in Junos OS Release 9.2. 

The size and sweep options were introduced in Junos OS Release 9.6. 

The dynamic-bypass and manual-bypass options were introduced in Junos OS Release 10.2. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Check the operability of MPLS RSVP-signaled label-switched path (LSP) connections. Type Ctrl+c to 
interrupt a ping mpls command. 


Options 
count count—(Optional) Number of ping requests to send. If count is not specified, five ping requests are 
sent. The range of values is 1 through 1,000,000. The default value is 5. 


destination address—(Optional) Specify an address other than the default (127.0.0.1/32) for the ping echo 
requests. The address can be anything within the 127/8 subnet. 


detail—(Optional) Display detailed information about the echo requests sent and received. 
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NOTE: When using the detail option, the reported time is based on the system time configured 
on the local and remote routers. Differences in these system times can result in inaccurate one 
way ping trip times being reported. 


In practice, it is difficult to synchronize the system times of independent Juniper Networks 
routers with sufficient accuracy to provide a meaningful time value for the detail option (even 
when synchronized using NTP). 


dynamic-bypass—(Optional) Ping dynamically generated bypass LSPs, used for protecting other LSPs. 
egress egress-address—(Optional) Only the specified egress router or switch responds to the ping request. 
exp forwarding-class—(Optional) Value of the forwarding class for the MPLS ping packets. 


interface—(Optional) Specify the name of the interface protected by the manual bypass LSP. This option 
is only available when you have also used the manual-bypass option. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on 
the specified logical system. 


Isp-name—Ping an RSVP-signaled LSP using an LSP name. 


manual-bypass—(Optional) Ping manually configured bypass LSPs, used for protecting other LSPs. For this 
option, you must also specify the interface protected by the manual bypass LSP using the interface 
option. 


multipoint—(Optional) Send ping requests to each of the egress routers or switches participating in a 
point-to-multipoint LSP. You can also include the egress option to ping a specific egress router or 
switch participating in a point-to-multipoint LSP. 


size bytes—(Optional) Size of the LSP ping request packet (100 through 65468 bytes). Packets are 4-byte 
aligned. For example, if you enter a size of 101, 102, 103, or 104, the router or switch uses a size value 
of 104 bytes. If you enter a packet size that is smaller than the minimum size, an error message is 
displayed reminding you of the 100-byte minimum. 


source source-address—(Optional) IP address of the outgoing interface. This address is sent in the IP source 
address field of the ping request. If this option is not specified, the default address is usually the 
loopback interface. 


standby standby-path-name—(Optional) Name of the standby path. 
sweep —(Optional) Automatically determine the size of the maximum transmission unit (MTU). 


Additional Information 
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If the LSP changes, the label and interface information displayed when you issued the ping command 
continues to be used. You must configure MPLS at the [edit protocols mpls] hierarchy level on the remote 
router or switch to ping an LSP terminating there. You must configure MPLS even if you intend to ping 
only LDP forwarding equivalence classes (FECs). 


In asymmetric MTU scenarios, the echo response might be dropped. For example, if the MTU from System 
A to System B is 1000 bytes, the MTU from System B to System A is 500 bytes, and the ping request 
packet size is 1000 bytes, the echo response is dropped because the PAD TLV is included in the echo 
response, making it too large. 


NOTE: Ina Juniper-Cisco interoperation network scenario, a point-to-multipoint LSP ping echo 
reply message from a Cisco device in a different IGP area is dropped on the Juniper device when 
the source address of the reply message is an interface address other than the loopback address 
or router ID. Starting in Junos OS Release 13.3X8, 14.2R6, 15.1R4, 15.1F6, 15.1F5-S8, 16.1R1, 
and later releases, such point-to-multipoint LSP ping echo reply messages are accepted by the 
Juniper device and the messages get logged as uncorrelated responses. 


Required Privilege Level 
network 


List of Sample Output 

ping mpls rsvp (Echo Reply Received) on page 2489 

ping mpls rsvp (Echo Reply with Error Code) on page 2490 
ping mpls rsvp detail on page 2490 

ping mpls rsvp multipoint egress detail count on page 2490 
ping mpls rsvp multipoint detail count on page 2490 

ping mpls rsvp destination detail count size on page 2491 
ping mpls rsvp destination detail sweep size on page 2492 


Output Fields 

When you enter this command, you are provided feedback on the status of your request. An exclamation 
point (!) indicates that an echo reply was received. A period (.) indicates that an echo reply was not received 
within the timeout period. An x indicates that an echo reply was received with an error code. Packets with 
an error code are not counted in the received packets count. They are accounted for separately. 


Sample Output 


ping mpls rsvp (Echo Reply Received) 


user@host> ping mpls rsvp test1 


!!!!!—-- lsping statistics ---5 packets transmitted, 5 packets received, 0% packet 


loss 


ping mpls rsvp (Echo Reply with Error Code) 


user@host> ping mpls rsvp test2 


!!xxx--- lsping statistics ---5 packets transmitted, 2 packets received, 60% packet 


loss3 packets received with error status, not counted as received. 


ping mpls rsvp detail 


user@host> ping mpls rsvp to-green detail 


Request for seq 1, to interface 67, labels <100095, 0, O> 
Reply for seq 1, return code: Egress-—ok 


Request for seq 2, to interface 67, labels <100095, 0, O> 





Reply for seq 2, return code: Egress-—ok 


ping mpls rsvp multipoint egress detail count 


user@host>ping mpls rsvp sample-Isp multipoint egress 192.168.1.3 detail count 1 


Request for seq 1, to interface 70, label 299952 
Request for seq 1, to interface 70, no label stack. 


Request for seq 1, to interface 67, no label stack. 





Reply for seq 1, egress 192.168.1.3, return code: Egress-ok, time: 0.242 ms 
foYor- Bl amon ar bet) 1 (simone oa 11 7A OfoPG SOc hol al Bo nC AOE) 
Remote receive time: 1205310695s 215979us 





=== igoimg, egress 192 .168.1,.3 Statisties =—= 


1 packets transmitted, 1 packets received, 0% packet loss 


ping mpls rsvp multipoint detail count 


user@host>ping mpls rsvp sample-Isp multipoint detail count 1 


Request for seq 1, to interface 70, label 299952 
Request for seq 1, to interface 70, no label stack. 


Request for seq 1, to interface 67, no label stack. 
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Reply for seq 1, return code: Unknown TLV, 
1205310615s 347317us 
Remote receive time: 1205310615s 357194us 
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time: 9.877 m Local transmit time: 





Reply for seq 1, egress 192.168.1.3, return code: Egress-ok, time: 0.351 ms 


Local transmit time: 1205310615s 347262us 
Remote receive time: 1205310615s 347613us 








Reply for seq 1, egress 192.168.1.13, return code: Egress-ok, time: 0.301 ms 


Local transmit time: 1205310615s 347167us 
Remote receive time: 1205310615s 347468us 








Timeout for seq 1, egress 192.168.1.1 


Timeout for seq 1, egress 192.168.1.4 





Timeout for seq 1, egress 192.168.1.14 


=== ising, egress 192. ios i, Sitacisties === 


1 packets transmitted, 0 packets received, 


100% packet loss 


=== Ilgjoime, equess 192 1681.3 Staitisties === 


1 packets transmitted, 1 packets received, 


0% packet loss 


=== Isjoiling, egress 192,158.14 Sitaiisitaes == 


1 packets transmitted, 0 packets received, 


=—— ilgjoilme, ecqmess 192.168. 1.is siceieisiciles 


1 packets transmitted, 1 packets received, 


=== Igoe, Scmess 2 ios i te psiecieasicies 


1 packets transmitted, 0 packets received, 


ping mpls rsvp destination detail count size 


100% packet loss 


0% packet loss 


100% packet loss 


user@host>ping mpls rsvp chaser-access destination 192.168.0.1 detail count 1 size 4468 


Request for seq 1, to interface 88, label 299984, packet size 4468 





Reply for seq 1, return code: Egress-ok, time: 44.804 ms 


Local transmit time: 2009-03-30 22: 
Remoremnceccavicmelme eZ O09 [ss 0N22r 





=== Ilgjoimg statistics === 


1 packets transmitted, 1 packets received, 


05:02 CEST 408.629 ms 
0502 CEST 4537433 ms 





0% packet loss 


ping mpls rsvp destination detail sweep size 


user@router> ping mpls rsvp chaser-access destination 192.168.0.1 detail sweep size 4500 


Request for seq 1, to interface 86, 


no label stack., 


packet size 


Reply for seq 1, return code: 


Local transmit time: 





Egress-—ok, time: -—39 
2009-04-24 14:05:40 Cl 





Remote receive tim 


2009-04-24 14:05:40 Cl 


Request for seq 2, to interface 86, no label stack 


Reply for seq 2, return code: 


Local transmit time: 





Remote receive tim 





Egress-—ok, time: -—38 
ZAQVOD—O4=—24 iAecOSsdi Ci 
20)09> O52 ASAIO 574 ae! 





Request for seq 3, to interface 86, no label stack 


Timeout for seq 3 


Request for seq 4, to interface 86, no label stack 


Reply for seq 4, return code: 


Local transmit time: 





Remote receive tim 





Egress-—ok, time: -—37 
Z O09 Of 2A maRAR TO SiS ame! 
ZAQVOI-O4—2A iAcOSeds ei 





Request for seq 5, to interface 86, no label stack 


Reply for seq 5, return code: 


Local transmit time: 





Remote receive tim 





Egress-—ok, time: -—37 
ZO0O09-O4=24 Adso0ssade Ci 
ZO09 SOA > ZA ARO SrA oe! 





Request for seq 6, to interface 86, no label stack 


Reply for seq 6, return code: 


Local transmit time: 





Remote receive tim 





Egress-—ok, time: -—36 
AQVOIM—O4—2A id4eOSea7 Ci 
Z002-O4-24 AsoOssay Ci 





Request for seq 7, to interface 86, no label stack 


Reply for seq 7, return code: 


Local transmit time: 





Remote receive tim 





Egress-—ok, time: -—36 
2009-04-24 14:05:48 Cl 
AQVOIM—O4—2Z4 iAcOSede Ci 





Request for seq 8, to interface 86, no label stack 


Reply for seq 8, return code: 


Local transmit time: 





Remote receive time: 





Egress-—ok, time: -—36 
Z009—O4-24 IAsOssae Ci 
Z2QVOI—O4=—24 4 sOS3a® Ci 


.264 ms 
asl Sal ales) ams 
asi 502,159 ims 





., packet size 
od 7S) sans; 

EST 544.240 ms 
EST 506.061 ms 





., packet size 


-, packet size 
.545 ms 

EST 549.953 ms 
EST 512.408 ms 





., packet size 
oS saan} 

AS S55. Sieiil wns! 
as Sits, 70S wis 





., packet size 
-962 ms 

EST 561.809 ms 
EST 524.847 ms 





-, packet size 
S22 iis) 

EST 568.738 ms 
Gor SSL.SL6 ms 





., packet size 
ADS) TS) 

EST 575.669 ms 
EST 538.814 ms 





Request for seq 9, to interface 86, 
Timeout for seq 9 


Request for seq 10, to interface 86, 


no label stack., 


no label stack., 


packet size 


packet size 


Reply for seq 10, return code: 


Local transmit time: 





Remote receive tim 





2009-04-24 
2009-04-24 





Request for seq 11, to interface 86, no 


Timeout for seq 11 





Timeout for seq 12 





Request for seq 12, to interface 86, no 


Request for seq 13, to interface 86, no 


Egress—ok, 
ALS O5)8 
AAR OS ES 


label 


label 


label 


time: 


Some! 


= 0 Comms 


EST 584.382 ms 





Some! 


EST 547.476 ms 


stack., packet size 


stack., packet size 


stack., packet size 


100 


2300 


4500 


3400 


S252 


4228 


4368 


4440 


4476 


4460 


4480 


4472 


4468 
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Reply for seq 13, return code: Egress-—ok, 


Request 
Timeout 


Request 





Timeout 


=o= Isp 


Maximum 





Local transmit time: 2009-04-24 
Remote receive time: 2009-04-24 


for seq 14, to interface 86, no 


for seq 14 

for seq 15, to interface 86, no 
for seq 15 

ping sweep result-——-— 


Transmission Unit (MTU) is 4468 


14:06 
14:06 
label 


label 


bytes 
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time: -36.943 ms 


:00 CEST 594.884 ms 
SOO CaS S57, 940i ins 





stack., packet size 4476 


stack., packet size 4472 
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| show rsvp interface 


List of Syntax 
Syntax on page 2494 
Syntax (EX Series Switches) on page 2494 


Syntax 


show rsvp interface 

<brief | detail | extensive> 

<instance instance-name> 
<link-management> 

<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


show rsvp interface 
<brief | detail | extensive> 
<link-management> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
instance option added in Junos OS Release 15.1 for the MX Series. 


Description 

Display the status of Resource Reservation Protocol (RSVP)-enabled interfaces and packet statistics. The 
RSVP input/input module collects statistics for certain events on a per-interface basis. Most of these 
events were tracked on a routing-instance basis in Junos OS releases earlier than Release 17.2. The show 
rsvp interface detail command displays these event counters under the Events section of the output only 
when the values of these fields are higher than zero. These statistics are also maintained at the global level 
(per routing-instance) and are also displayed in the output of the show rsvp statistics command. 


Options 


none—Display standard information about the status of RSVP-enabled interfaces and packet statistics. 
brief | detail | extensive | link-management—(Optional) Display the specified level of output. 


instance instance-name—(Optional) Display RSVP status information for the specified instance. If 
instance-name is omitted, RSVP status information is displayed for the master instance. 


link-management—(Optional) Use the link-management option to display the control peers and 
corresponding TE-link information created by the Link Management Protocol (LMP). 
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logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 


particular logical system. 


Required Privilege Level 


view 


List of Sample Output 
show rsvp interface brief on page 2498 
show rsvp interface detail on page 2498 


show rsvp interface extensive on page 2499 


show rsvp interface link-management on page 2500 
show rsvp interface detail RSVP interface: 9 active on page 2500 


Output Fields 


Table 78 on page 2495 lists the output fields for the show rsvp interface command. Output fields are listed 
in the approximate order in which they appear. 


Table 78: show rsvp interface Output Fields 


Field Name 


RSVP interface 


Interface 


Index 


State 


NoAuthentication 


NoAggregate 


NoReliable 


NoLinkProtection 


Field Description 


Number of interfaces on which RSVP is active. Each interface has one 
line of output. 


Name of the interface. 


Index of the interface. 


State of the interface. 


Disabled—No traffic engineering information is displayed. 


e Down-—Interface is not operational. 


Enabled—Displays traffic engineering information. 


Up-—Interface is operational. 


Interface does not support RSVP authentication. 


Interface does not support refresh reduction. 


Interface does not support refresh reduction message ID extension. 


Interface does not support link protection. 


Level of Output 


All levels 


All levels 


detail 


All levels 


detail 


detail 


detail 


detail 


Table 78: show rsvp interface Output Fields (continued) 


Field Name 


Hellolnterval 


Address 


Active control 
channel 


TElink 


Active resv 


PreemptionCnt 


Update threshold 


Subscription 


Actual 


bc number 


ct number 


Static BW 


Available BW 


Reserved BW 


SoftPreemptionCnt 


Field Description 


Frequency at which RSVP hellos are sent on this interface (in seconds). 


Prior to Junos OS Release 18.2R2, when the no-interface-hello statement 
is configured under the [edit protocols rsvp] hierarchy, and there is no 
interface-specific configuration for the hello interval, the Hellolnteval 
output field displayed the default hello interval time of 9 seconds. Starting 
in Junos OS Release 18.2R2, with a similar configuration, the HelloInterval 
output field displays O as the hello interval. 

IP address of the local interface. 

Next-hop link address to transmit messages. 

Traffic-engineered links that are managed by the peer they are associated 


with. 


Number of reservations that are actively reserving bandwidth on the 
interface. 


Number of times an RSVP session was preempted on this interface. 


Percentage change in reserved bandwidth to trigger an IGP update. 


User-configured subscription factor. 


Available RSVP bandwidth that is recalculated after considering SPRING 
bandwidth utilization. 


Bandwidth allocated for the specified bandwidth constraint. 


Bandwidth allocated for the specified class type. 


Total interface bandwidth, in bps. 


Amount of bandwidth that RSVP is allowed to reserve, in bps. It is equal 
to (static bandwidth * subscription factor). 


Currently reserved bandwidth, in bps. 


Number of times a soft preemption occurred on this interface. This number 
is not included in the PreemptionCnt value. 
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Level of Output 


detail 


detail 


None specified 


None specified 


All levels 


detail 


detail 


All levels 


extensive 


extensive 


extensive 


All levels 


al levels 


All levels 


detail 


Table 78: show rsvp interface Output Fields (continued) 


Field Name 


Overbooked BW 


Highwater mark 


PacketType 


Total Sent 


Total Received 


Last 5 seconds 
Sent 


Last 5 seconds 
Received 


Path 


PathErr 


PathTear 


Resv 


ResvErr 


ResvTear 


Hello 


Ack 


Field Description 


Currently overbooked bandwidth, in bps, by class type (ctO through ct3). 


Highest bandwidth that has ever been reserved on this interface, in bps. 


Type of RSVP packet. 


Total number of packets sent. 


Total number of packets received since RSVP was enabled. 


Number of packets sent in the last 5 seconds. 


Number of packets received in the last 5 seconds. 


Statistics about Path messages, which are sent from the RSVP sender 
along the data paths and store path state information in each node along 
the path. 


Statistics about PathErr messages, which are advisory messages that are 
sent upstream to the sender. 


Statistics about PathTear messages, which remove path states and 
dependent reservation states in any routers along a path. 


Statistics about Resv messages, which are sent from the RSVP receiver 
along the data paths and store reservation state information in each node 


along the path. 


Statistics about ResvErr messages, which are advisory messages that are 
sent when an attempt to establish a reservation fails. 


Statistics about ResvTear messages, which remove reservation states 
along a path. 


Number of RSVP hello packets that have been sent to and received from 
the neighbor. 


Acknowledge message for refresh reductions. 


Level of Output 


detail 


brief 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 
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Table 78: show rsvp interface Output Fields (continued) 


Field Name Field Description 
Srefresh Summary refresh messages. 


EndtoEnd RSVP _ Statistics for the number of end-to-end RSVP messages sent. 


Queue CoS transmit queue number and its associated forwarding class 
designation. 
TxRate Configured bandwidth in Mbps and configured bandwidth as a percentage 


of the specified queue. 
Priority Weight of the queue relative to other configured queues, in percentage. 


queue-priority-value | Low, High, None, or Exact. None indicates no rate limiting. Exact indicates 
the queue transmits at the configured rate only. 


| Sample Output 


show rsvp interface brief 


user@host> show rsvp interface brief 


RSVP interface: 1 active 


Active Subscr- Static Available Reserved 
Interface State resv iption BW BW BW 
de0.0 Up dl 23% 10Mbps 989.992kbps 1.31Mbps 


show rsvp interface detail 
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Level of Output 


detail 


detail 


extensive 


extensive 


extensive 


extensive 


Highwater 
mark 
1.31Mbps 


Starting in Junos OS Release 15.2, this command also shows conditional PathTear statistics and Node 


Hellos. 


user@host> show rsvp interface detail 


so-0/1/1.0 Index 6, State: Ena/Up 








NoAuthentication, NoAggregate, NoReliable, NoLinkProtection 
HelloInterval 3(second) 
Melelasss 92,168,207 29, 10,255,245, 194 


ActiveResv 0, PreemptionCnt 0, SoftPreemptionCnt 0, Update threshold 10% 


Subscription 100%, 


























StaticBW 155.52Mbps, 
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AvailableBW 155.52Mbps 





ReservedBW [0] 155Mbps[1] Obps[2] Obps[3] Obps[4] Obps[5] Obps[6] Obps[7] Obps 

SoftPreemptionCntl 

OverbookedBW [0] Obps[1] Obps[2] Obps[3] Obps[4] 155Mbps[5] Obps[6] Obps[7] Obps 

PacketType Total Last 5 seconds 

Sent Received Sent Received 
Path 16 0 1 0 
PathErr 0 0 0 0 
PathTear it 0 0 0 
ReEsv 0 dal 0 al 
ResvErr 0 0 0 0 
ResvTear 0 0 0 0 
Hello 66 67 il i 
Ack 0 0 0 0 
Srefresh 0 0 0 0 
EndtoEnd RSVP 0 0 0 0 
Node Hello 100 100 0 0 
PathTear(Condl.) 0 . 0 0 
show rsvp interface extensive 
user@host> show rsvp interface extensive 

so-1/0/0.0 Index 72, State Ena/Up 

NoAuthentication, NoAggregate, NoReliable, NoLinkProtection 





HelloInterval 9(second) 
Melekeass 192.168.213.422, 






































SoftPreemptionCnt 0, 


ab 


Obps [3] 
leBW 366. 


ab 
2 


lab 


10, 455,240,175 


leBW 522. 


Obp 


Obps [3] 


leBW 311. 
Obps [3] 
lab 


Obp 





leBW 155. 
Obps [3] 


Obp 


Peaak@yisenteny 


ActiveResv 1, PreemptionCnt 0, 
Subscription 100%, Actual 60% 
beO = Vorvreeltou Aer 3), 
bel = tetltcr ters), 
be2 = (ct2+ct3), StaticBW 311.04Mbps 
bese mC lor mrcisciake DWeeo ones a Mises 
ct0O: StaticBW 155.52Mbps, Avail 
ReservedBW [0] Obps[1] Obps[2] 
Cel Star teBweloon \2Mibps Avail: 
ReservedBW [0] 100Mbps[1] Obps 
ct2: StaticBW 155.52Mbps, Avai 
ReservedBW [0] Obps[1] Obps[2] 
ct3: StaticBW 155.52Mbps, Avai 
ReservedBW [0] Obps[1] Obps[2] 
Queue TxRate 

0 155.52Mbps 


25% 


Update threshold 10% 


StaticBW 622.08Mbps 
StaticBW 466.56Mbps 


O8Mbps 

s[4] Obps[5] 
56Mbps 
Obps [4] 


04 


Obps[6] Obps[7] Obps 


Obps[5] Obps[6] Obps[7] Obps 
bps 
s[4] Obps[5] 
52Mbps 
s[4] Obps[5] 


Exact 


Obps[6] Obps[7] Obps 








Obps[6] Obps[7] Obps 





Low 


iL 155.52Mbps % Low 
155.52Mbps % Low 
155.52Mbps % Low 


show rsvp interface link-management 


user@host> show rsvp interface link-management 


RSVP interface: 2 active 


PEER-C State: Up 














Active Control Channel: 


4 





ActiveResv 0, Preempti 


n 








Whibsiokes Winilink<2, Ibalial< IL 


ActiveResv 1, Preempti 





n 





Lig) 





Ebb 





State: Up 





Active Control Channel: 


(Sj 





n 


eI 








wn 


so-0/1/'O) 


jmilalinles “wailing leil,, Ibabiale I0D)3 Syy/tsal ib 


onCnt 0 


taticBW 155.52Mbps, ReservedBW: Obps, AvailableBW: 


DesricOs 
onCnt 0 


taticBW 155.52Mbps, ReservedBW: Obps, AvailableBW: 


Om O/AORO 


Imibaliokes Gniadlioheveiyil, Ijin ILiDyS ILS} Shs} 
ActiveResv 0, PreemptionCnt 0 
taticBW 622.08Mbps, ReservedBW: Obps, AvailableBW: 


imibalipkes Ga LigherNEA Ibjskine ILIDIS ILS) S)7/ 
ActiveResv 0, PreemptionCnt 0 
taticBW 622.08Mbps, ReservedBW: Obps, AvailableBW: 


show rsvp interface detail RSVP interface: 9 active 


user@host> show rsvp interface detail RSVP interface: 9 active 


fxp0.0 Index 4, State Dis/Up 





Address 10.9.148.47 
Event 


bad packet length 





bad packet version 
authentication fail 


bad checksum 


ISSR o2Mbps 


iSSmo2Mbps 


622.08Mbps 


622.08Mbps 


NoAuthentication, Aggregate, Reliable, NoLinkProtection HelloInterval 9(second) 


2500 


bad packet format 

rev pkt disabled intf 
state timeout 

message out-of-order 
unknown ack 

unknown nack 

received nack 


send failure 


PacketType Total 


Sent Received 
Path 





PathErr 
PathTear 


Resv 





RESvErr 
Resviear 
ResvConf 
Bundle 
Hello 
Ack 





Srefresh 
Notify 
Unknown 
EndtoEnd RSVP 
Backup Path 














Cnd PathTear 


Sao 2 2 2e& c= & S&S =| = Sf fF S&S S&S S& 


Sent 


a oa a ae eo oa Ss SoS ec oe eo a S&S oc S&S 





Last 5 seconds 


Received 





SoS oS 2 2 2 2S > 2 2 SSS aS 6S 





oe, ~~ fe eS Te oe oe oe fe ea Se fe Se eS 
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| show rsvp neighbor 


List of Syntax 
Syntax on page 2502 
Syntax (EX Series Switches) on page 2502 


Syntax 


show rsvp neighbor 

<brief | detail | extensive> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


show rsvp neighbor 
<brief | detail> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
instance option added in Junos OS Release 15.1 for the MX Series. 


Description 
Display Resource Reservation Protocol (RSVP) neighbors that were discovered dynamically during the 
exchange of RSVP packets. 


Options 


none—Display standard information about RSVP neighbors. 
brief | detail—(Optional) Display the specified level of output. 


instance instance-name—(Optional) Display the RSVP neighbor information for the specified instance. If 
instance-name is omitted, RSVP neighbor information is displayed for the master instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


List of Sample Output 
show rsvp neighbor on page 2506 
show rsvp neighbor detail on page 2507 


Output Fields 
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Table 79 on page 2503 lists the output fields for the show rsvp neighbor command. Output fields are listed 


in the approximate order in which they appear. 


Table 79: show rsvp neighbor Output Fields 


Field Name 


RSVP neighbor 


via 


Address 


Idle 


Up/Dn 


Up cnt and Down 
cnt 


Field Description 


Number of neighbors that the routing device has learned of. Each neighbor 


has one line of output. 


Name of the interface where the neighbor has been detected. In the case 
of generalized MPLS (GMPLS) LSPs, the name of the peer where the 
neighbor has been detected. 


Address of a learned neighbor. 


Length of time the neighbor has been idle, in seconds. 


NOTE: Until Junos OS Release 15.1, in the output of the show rsvp 
neighbor command, the value under the Idle field immediately reflects 
the changed idle time when a link in the neighboring router is brought 
down. Starting with Junos OS Release 15.2, a router does not declare a 
neighbor as idle when a hello adjacency exists and has not timed out. 
When an interface is brought down, RSVP brings down the neighbor 
because of the notification it receives from IGP. The reason for considering 
the IGP-down notification is to support BFD-triggered fast reroute (FRR) 
and RSVP-TE is not directly a client for BFD notifications. When RSVP 
brings down the neighbor, the input/output process is not impacted. As 
a result, the idle time in the output of the show command is not 
immediately updated. 


Number of neighbor up or down transitions detected by RSVP hello 
packets. If the up count is 1 greater than the down count, the neighbor 
is currently up. Otherwise, the neighbor is down. Neighbors that do not 
support RSVP hello packets, such as routers running Junos OS Release 3.2 
or earlier, are not reported as up or down. 


Number of neighbor up or down transitions detected by RSVP hello 
packets. If the up count is 1 greater than the down count, the neighbor 
is currently up. Otherwise, the neighbor is down. Neighbors that do not 
support RSVP hello packets, such as routers running Junos OS Release 3.2 
or earlier, are not reported as up or down. 


Level of Output 


All levels 


detail 


All levels 


All levels 


All levels 


detail 


Table 79: show rsvp neighbor Output Fields (continued) 


Field Name 


status 


LastChange 


Last changed 


time 


Hellolnt 


HelloTx/Rx 


Hello 


Message 


received 


Remote Instance 


Local Instance 


Field Description 


State of the RSVP neighbor: 


e Up—Routing device can detect RSVP Hello messages from the neighbor. 
e Down—Routing device has received one of the following indications: 
e Communication failure from the neighbor. 
e Communication from IGP that the neighbor is unavailable. 
e Change in the sequence numbers in the RSVP Hello messages sent 


by the neighbor. 


e Restarting—RSVP neighbor is unavailable and might be restarting. The 
neighbor remains in this state until it has restarted or is declared dead. 
This state is possible only when graceful restart is enabled. 


e Restarted—RSVP neighbor has restarted and is undergoing state 
recovery (graceful restart) procedures. 


e Dead—Routing device has lost all communication with the RSVP 
neighbor. Any RSVP sessions with that neighbor are torn down. 


Time elapsed since the neighbor state changed either from up to down 
or from down to up. The format is hh:mm:ss. 


Time elapsed since the neighbor state changed either from up to down 
or from down to up. 


Frequency at which RSVP hellos are sent on this interface (in seconds). 


Number of hello packets sent to and received from the neighbor. 


Number of RSVP hello packets that have been sent to and received from 
the neighbor. 


Number of Path and Resv messages that this routing device has received 
from the neighbor. 


Identification provided by the remote routing device during Hello message 
exchange. 


Identification sent to the remote routing device during Hello message 
exchange. 
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Level of Output 


detail 


All levels 


detail 


All levels 


All levels 


detail 


detail 


detail 


detail 


Table 79: show rsvp neighbor Output Fields (continued) 


Field Name 


Refresh 
reduction 


Remote end 


Pop label 


Ack-extension 


Link protection 


LSP name 


Field Description 


Measure of processing overhead requests of refresh messages. Refresh 
reduction extensions improve routing device performance by reducing 
the process overhead, thus increasing the number of LSPs a routing device 
can support. Refresh reduction can have the following values: 


e operational—All four RSVP refresh reduction extensions—message ack, 
bundling, summary refresh, and staged refresh timer—are functional 
between the two neighboring routing devices. For a detailed explanation 
of these extensions, see RFC 2961. 


e incomplete—Some RSVP refresh reduction extensions are functional 
between the two neighboring routing devices. 


e not operational—Either the refresh reduction feature has been turned 
off, or the remote routing device cannot support the refresh reduction 
extensions. 


Neighboring routing device’s status with regard to refresh reduction: 


e enabled—Remote routing device has requested refresh reduction during 
RSVP message exchanges. 


e disabled—Remote routing device does not require refresh reduction. 


Pop labels of the RSVP-TE pop-and-forward LSP tunnels. 


An RSVP refresh reduction extension: 


e enabled—Both local and remote routing devices support the 
ack-extension (RFC 2961). 
e disabled—Remote routing device does not support the ack-extension. 


Status of the MPLS fast reroute mechanism that protects traffic from link 
failure: 


e enabled—Link protection feature has been turned on, protecting the 
neighbor with a bypass LSP. 


e disabled—No link protection feature has been enabled for this neighbor. 


Name of the bypass LSP. 
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Level of Output 


detail 


detail 


detail 


detail 


detail 


detail 
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Table 79: show rsvp neighbor Output Fields (continued) 


Field Name 


Bypass LSP 


Backup routes 


Backup LSPs 


Bypass explicit 
route 


Restart time 


Recovery time 


Field Description Level of Output 


Status of the bypass LSP. It can have the following values: detail 


e does not exist—Bypass LSP is not available. 


e connecting—Routing device is in the process of establishing a bypass 
LSP, and the LSP is not available for link protection at the moment. 


e operational—Bypass LSP is up and running. 


e down—Bypass LSP has gone down, with the most probable cause a 
node or a link failure on the bypass path. 


Number of user LSPs (or routes) that are being protected by abypass LSP detail 
(before link failure). 


Number of LSPs that have been temporarily established to maintain traffic detail 
by refreshing the downstream LSPs during link failure (not a one-to-one 


correspondence). 
Explicit route object's (ERO) path that is taken by the bypass LSP. detail 
Length of time a neighbor waits to receive a Hello from the restarting detail 


node before declaring the node dead and deleting the states (in 
milliseconds). 


Length of time during which the restarting node attempts to recover its _ detail 
lost states with help from its neighbors (in milliseconds). Recovery time 

is advertised by the restarting node to its neighbors, and applies to nodal 

faults. The restarting node considers its graceful restart complete after 

this time has elapsed. 


| Sample Output 


show rsvp neighbor 


user@host> show rsvp neighbor 


RSVP neighbor: 


Address 


2 learned 


Idle Up/Dn LastChange HelloInt HelloTx/Rx 


LY 5 LOS5 20 5 20S) © 3/2 13}3 OL 3 366/349 
12, LOS, 207 > 407 OnE A0 22:49 3) 448/448 


2507 


show rsvp neighbor detail 


Starting in Junos OS Release 16.1, this command also shows whether enhanced FRR procurers are enabled 
on the neighbor. Neighbors with Point of Local Repair (PLR) or Node Protecting Merge Point (NP-MP) 
also show the Hellos sent /received count. 


user@host> show rsvp neighbor detail 


RSVP neighbor: 2 learned 

Addwesis) LOZ Nes 2072038 via: ecstasyl status: Up 
Last changed time: 28:47, Idle: 0 sec, Up cnt: 3, Down cnt: 2 
Message received: 632 





Hello: sent 673, received 656, interval 3 sec 
Remote instance: 0x6432838a, Local instance: 0x74b72e36 
Refresh reduction: operational 


Remot nd: enabled, Ack-extension: enabled 








Enhanced FRR local protection: enabled 
SPs (cocal 15) k Pines W, Beineis WW, Nines Wo, NNiace 0) 
Pop Label: 299808 (unprotected) 299840 (link-protected) 
Link protection: enabled 
LSP name: Bypass_to_192.168.207.203 
Bypass LSP: operational, Backup routes: 1, Backup LSPs: 0 
Bypass) explicit route: 92 Ves 207 7207 VIZ es 207 322.4 





Restart time: 60000 msec, Recovery time: 0 msec 
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| show rsvp route-session-id 


Syntax 


show rsvp route-session-id 


Release Information 
Command introduced in Junos OS Release 16.1 for the MX Series. 


Description 
Display the session ID and the version information associated with the ingress route added by the Resource 
Reservation Protocol (RSVP) in the inet.3 table. 


Session ID is a pre-populated identifier used for indirect next hops in BGP Prefix Independent Convergence 
(PIC) enabled router. Session ID is used to identify the session or path. 


NOTE: protect core configuration is not required to display the route-session-id. 


Options 


none—Validate and display RSVP route session details. 


Required Privilege Level 


view 


List of Sample Output 
show rsvp route-session-id on page 2509 


Output Fields 
Table 80 on page 2508 describes the output fields for the show rsvp route-session-id command. Output 
fields are listed in the approximate order in which they appear. 


Table 80: show rsvp route-session-id Output Fields 


Field Name Field Description 
Ingress Route Destination (egress routing device) of the session. 
Destination 


Ingress Route Preference RSVP preference value of the ingress session. 


Ingress Route Metric 1 Metric 1 associated with the RSVP ingress route. 


Table 80: show rsvp route-session-id Output Fields (continued) 


Field Name 


Ingress Route Metric 2 


Ingress Route Session ID 


Version 


| Sample Output 


Field Description 


Metric 2 associated with the RSVP ingress route. 


Session ID associated with the RSVP ingress route. 


Version number associated with the RSVP ingress route. 


show rsvp route-session-id 


user@host> show rsvp route-session-id 


RSVP Ingress Route Session ID Database: 








ingress 
MING Ics} 
ING HRe ISIS, 


Ingress 


Route 
Boutce 
Rource 


Bouvce 


DAScimecieme It, 15/32 

Preference: 7 

Misiczese il 2 207 Me traitcuee am) 
Session ID: 0x146, Version: 0 
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| show rsvp pop-and-forward 


Syntax 


show rsvp pop-and-forward 
<brief | detail | extensive> 
<instance routing-instance-name> 
<label label> 


<logical-system (all | logical-system-name)> 


Release Information 
Command introduced in Junos OS Release 18.1R1 on MX Series routers, PTX Series routers, and VMX 
series routers. 


Description 

Display RSVP-TE pop-and-forward LSP tunnel information. This information includes the set of in-labels 
(one-hop pop label or a delegation label), the number of session using each label and the next segment-label 
(if there is another delegation hop downstream), and whether the in-label is used for unprotected or 
protected LSPs. 


Options 
none—Display the standard level of information for the RSVP-TE pop-and-forward LSP tunnels. 


brief | detail | extensive—(Optional) Display the desired level of output. The brief option is the default level 
of output. 


The detail option provides more information about the hops in a delegation segment (whether its 
one-hop or multi-hop). 


The extensive option lists the set of LSPs that are using a given pop or delegation label. 


instance routing-instance-name—(Optional) Display the RSVP-TE pop-and-forward LSP tunnel information 
for the specified routing instance. 


label label—(Optional) Display the RSVP-TE pop-and-forward LSP tunnel information for the specified 
label. 


logical-system (all | logical-system-name)—(Optional) Display the RSVP-TE pop-and-forward LSP tunnel 
information for all or the specified logical system. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 
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Pop-and-Forward LSP Configuration | 697 
pop-and-forward (Protocols RSVP) | 2046 
pop-and-forward (Protocols MPLS) | 1906 


List of Sample Output 

show rsvp pop-and-forward on page 2511 

show rsvp pop-and-forward extensive on page 2511 
show rsvp pop-and-forward label on page 2512 


Sample Output 


show rsvp pop-and-forward 


user@host> show rsvp pop-and-forward 


RSVP pop-and-forward: 2 shared labels 





Label-in Hop-count Next-segment- Protection Session- 
label count 

299840 5 299808 unprotected 100 

BNE 5 299824 unprotected 50) 


show rsvp pop-and-forward extensive 


user@host> show rsvp pop-and-forward extensive 


RSVP pop-and-forward: 2 shared labels 
299840 (shared-label) 
Next-segment—label: 299808, Hop-count: 3 








Protection: unprotected, Session-count: 2 
Segment-—id: 
Hop 1: 70.1.1.2 (label=299808) 
Hop 2: 92.1.1.1(label=299808) 
Eloy 32 YS, ,ls22 
Segment route: 
Pies TOcil,l,2, Owewtes Ge-0/0/2.0 





Lsp-session list (name, dest-ip, sender-ip, lsp-id): 
pool, IO.1O UO 1O, 2.2cBc2, 2 
peD2, IO. IOIO tO, Bs2c2s2, i 





299872 (shared-label) 
Next-segment-—label: 299824, Hop-count: 3 








Protection: unprotected, Session-count: 4 


Segment-—id: 
Hop 1: 70.1.1.2 (labe1=299808) 
Hop 2: 92.1.1.1(label=299808) 
Heys 32 S511, 2 
Segment route: 
Pieiwaays T0,l,1,2, Cmienes ce—-0/0/2.0 





Lsp-session list (name, dest-ip, sender-ip, lsp-id): 


OGL, QoVs9s9, SeFoGoap I 
(OOOLS, Qo 999, SokceSoay I 
DOS1ISO, Y595959, SaFeGoap I 
POSLAD, V.9,959, B2coScBcen i 


show rsvp pop-and-forward label 


user@host> show rsvp pop-and-forward label 299872 


RSVP pop-and-forward: 2 shared labels 





Label-in Hop-count Next-segment- Protection Session- 
label count 
299372 5 299824 unprotected 4 
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| show rsvp session 


List of Syntax 
Syntax on page 2513 
Syntax (EX and QFX Series Switches) on page 2513 


Syntax 


show rsvp session 

<brief | detail | extensive | terse> 
<bidirectional | unidirectional> 
<bypass> 

<down | up> 
<externally-provisioned> 
<instance instance-name> 
<interface interface-name> 
<logical-system (all | logical-system-name)> 
<Isp-type> 

<name session-name> 

<p2mp> 

<session-type> 

<statistics> 

<te-link te-link> 


Syntax (EX and QFX Series Switches) 


show rsvp session 

<brief | detail | extensive | terse> 
<bidirectional | unidirectional> 
<bypass> 

<down | up> 
<externally-provisioned> 
<interface interface-name> 
<Isp-type> 

<name session-name> 

<p2mp> 

<session-type> 

<statistics> 

<te-link te-link> 


Release Information 
Command introduced before Junos OS Release 7.4. 


Command introduced in Junos OS Release 9.5 for EX Series switches. 


externally-provisioned option added in Junos OS Release 13.3. 
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Command introduced in Junos OS Release 13.2X51-D15 for QFX Series. 
instance option added in Junos OS Release 15.1 for the MX Series. 


Description 


Display information about RSVP sessions. 


Options 


none—Display standard information about all RSVP sessions. 
brief | detail | extensive | terse—(Optional) Display the specified level of output. 


bidirectional | unidirectional—(Optional) Display information about bidirectional or unidirectional RSVP 
sessions only, respectively. 


bypass—(Optional) Display RSVP sessions for bypass LSPs. 
down | up—(Optional) Display only LSPs that are inactive or active, respectively. 


externally-provisioned—(Optional) Display the LSPs that are generated dynamically and provisioned by 
an external Path Computation Element (PCE). 


instance instance-name—(Optional) Display RSVP sessions for the specified instance. If instance-name is 
omitted, RSVP session information is displayed for the master instance. 


interface interface-name—(Optional) Display RSVP sessions for the specified interface only. 


RSVP reserves resources only for outgoing LSPs of an interface. Because resources are not reserved 
for incoming LSPs, the show rsvp sessions interface interface-name command output displays only 
those RSVP sessions whose next hops correspond to the specified interface. 


To identify the number of RSVP sessions formed over the uplink interface on the egress label-switching 
router (LSR), you can use the following command: 


user@host> showrsvp session egress extensive | match "PATH rcvfrom:" | match interface-name | count 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Isp-type—(Optional) Display information about RSVP sessions with regard to LSPs: 


e bypass—Sessions used for bypass LSPs. 
e Isp—Sessions used to set up LSPs. 


e nolsp—Sessions not used to set up LSPs. 


name session-name—(Optional) Display information about the named session. 


p2mp—(Optional) Display point-to-multipoint information. 
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session-type—(Optional) Display information about a particular session type: 


e egress—Sessions that terminate on this routing device. 


To identify the number of RSVP sessions formed over the uplink interface on the egress 
label-switching router (LSR), you can use the following command: 


user@host> showrsvp session egress extensive | match "PATH rcvfrom:" | match interface-name 


| count 


e ingress—Sessions that originate from this routing device. 


e transit—Sessions that transit through this routing device. 


statistics—(Optional) Display packet statistics. 


te-link te-link—(Optional) Display sessions with reservations on the specified TE link. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


clear rsvp session | 2479 


List of Sample Output 

show rsvp session on page 2520 

show rsvp session statistics on page 2521 

show rsvp session detail on page 2521 

show rsvp session detail (When Egress Protection Is in Standby Mode) on page 2522 
show rsvp session detail (When Egress Protection Is in Effect During a Local Repair) on page 2522 
show rsvp session detail (Path MTU Output Field) on page 2523 

show rsvp session detail (GMPLS) on page 2523 

show rsvp session extensive on page 2524 

show rsvp session extensive transit on page 2525 

show rsvp session p2mp (Ingress Router) on page 2526 

show rsvp session p2mp (Transit Router) on page 2526 


Output Fields 


Table 81 on page 2516 describes the output fields for the show rsvp session command. Output fields are 
listed in the approximate order in which they appear. 


Table 81: show rsvp session Output Fields 


Field Name 


Ingress RSVP 


Ingress RSVP 


Egress RSVP 


Transit RSVP 


P2MP name 


P2MP branch 
count 


To 


From 


State 


Address 


From 


LSPstate 


Rt 


Active Route 


LSPname 


Field Description 


Information about ingress RSVP sessions. 


Information about ingress RSVP sessions. Each session has one line of 
output. 


Information about egress RSVP sessions. 


Information about the transit RSVP sessions. 


(Appears only when the p2mp option is specified). Name of the 
point-to-multipoint LSP path. 


(Appears only when the p2mp option is specified). Number of LSPs 
receiving packets from the point-to-multipoint LSP. 


Destination (egress routing device) of the session. 


Source (ingress routing device) of the session. 


State of the path: Up, Down, or AdminDn. AdminDn indicates that the 
LSP is being taken down gracefully. 


Destination (egress routing device) of the LSP. 


Source (ingress routing device) of the session. 


State of the LSP that is being handled by this RSVP session. It can be 
either Up, Dn (down), or AdminDn. AdminDn indicates that the LSP is 
being taken down gracefully. 


Number of active routes (prefixes) that have been installed in the routing 
table. For ingress RSVP sessions, the routing table is the primary IPv4 
table (inet.0). For transit and egress RSVP sessions, the routing table is 
the primary MPLS table mpls.0). 


Number of active routes (prefixes) that have been installed in the 
forwarding table. For ingress RSVP sessions, the forwarding table is the 
primary IPv4 table (inet.0). For transit and egress RSVP sessions, the 
forwarding table is the primary MPLS table (mpls.0). 


Name of the LSP. 
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Level of Output 


detail 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


detail 


detail 


brief detail 


brief 


detail 


brief detail 


Table 81: show rsvp session Output Fields (continued) 


Field Name 


LSPpath 


Bypass 


Bidir 


Bidirectional 


Upstream label in 


Upstream label 


out 


Recovery label 
received 


Recovery label 
sent 


Suggested label 
received 


Suggested label 
sent 


Resv style or 


Style 


Label in 


Label out 


Time left 


Field Description 

Indicates whether the RSVP session is for the primary or secondary LSP 
path. LSPpath can be either primary or secondary and can be displayed 
on the ingress, egress, and transit routing devices. LSPpath can also 
indicate when a graceful LSP deletion has been triggered. 


(Egress routing device) Destination address for the bypass LSP. 


(When LSP is bidirectional) LSP will allow data to travel in both directions 
between GMPLS devices. 


(When LSP is bidirectional) LSP will allow data to travel both ways between 
GMPLS devices. 


(When LSP is bidirectional) Incoming label for reverse direction traffic for 
this LSP. 


(When LSP is bidirectional) Outgoing label for reverse direction traffic for 
this LSP. 


(When LSP is bidirectional) Label the upstream node suggests for use in 
the Resv message that is sent. 


(When LSP is bidirectional) Label the downstream node suggests for use 
in its Resv messages that is returned. 


(When LSP is bidirectional) Label the upstream node suggests for use in 
the Resv message that is sent. 


(When LSP is bidirectional) Label the downstream node suggests for use 
in its Resv message that is returned. 


RSVP reservation style. This field consists of two parts. The first is the 
number of active reservations. The second is the reservation style, which 
can be FF (fixed filter), SE (shared explicit), or WF (wildcard filter). 
Incoming label for this LSP. 


Outgoing label for this LSP. 


Number of seconds remaining in the lifetime of the reservation. 


Level of Output 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


brief detail 


brief detail 


brief detail 


brief detail 
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Table 81: show rsvp session Output Fields (continued) 


Field Name 


Since 


Tspec 


DiffServ info 


bandwidth 


Port number 


Attrib flags 


FastReroute 


desired 


Soft preemption 
desired 


FastReroute 
desired 


Link protection 
desired 


Node/Link 
protection 
desired 


Field Description 


Date and time when the RSVP session was initiated. 


Sender's traffic specification, which describes the sender's traffic 
parameters. 


Indicates whether the LSP is a multiclass LSP (multiclass diffServ-TE LSP) 
or a Differentiated-Services-aware traffic engineering LSP (diffServ-TE 
LSP). 

Bandwidth for each class type (ctO, ct1, ct2, or ct3). 


Protocol ID and sender/receiver port used in this RSVP session. 


Non-PHP indicates that ultimate hop popping has been requested by the 
LSP using this RSVP session 


Fast reroute has been requested by the ingress routing device. 


Soft preemption has been requested by the ingress routing device. 


(Data [not a bypass or backup] LSP when the protection scheme has been 
requested) Fast reroute (one-to-one backup) has been requested by the 
ingress routing device. 


(Data [not a bypass or backup] LSP when the protection scheme has been 
requested) Link protection (many-to-one backup) has been requested by 
the ingress routing device. 


(Data [not a bypass or backup] LSP when the protection scheme has been 
requested) Node and link protection (many-to-one backup) has been 
requested by the ingress routing device. 
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Level of Output 


detail 


detail 


detail 


detail 


detail 


extensive 


detail 


detail 


detail extensive 


detail extensive 


detail extensive 
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Table 81: show rsvp session Output Fields (continued) 


Field Name 


Type 


New bypass 


Link protection 
up, using 
bypass-name 


Creating backup 
LSP, link down 


Deleting backup 
LSP, protected 


LSP restored 


Path mtu 


Field Description Level of Output 


LSP type: detail extensive 


e Link protected LSP—LSP has been protected by link protection at the 
outgoing interface. The name of the bypass used is also listed here 
(extensive). 

e Node/Link protected LSP—LSP has been protected by node and link 
protection at the outgoing interface. The name of the bypass used is 
also listed here (extensive). 


e Protection down—LSP is not currently protected. 


e Bypass LSP—LSP that is used to protected one or more user LSPs in 
case of link failure. 


e Backup LSP at Point-of-Local-Repair (PLR)—LSP that has been 
temporarily established to protected a user LSP at the ingress of a failed 
link. 

e Backup LSP at Merge Point (MP)—LSP that has been temporarily 
established to protected a user LSP at the egress of a failed link. 


New bypass (the bypass name is also displayed) has been activated to extensive 
protect the LSP. 


Link protection (the bypass name is also displayed) has been activated for extensive 
the LSP. 


A link down event occurred, and traffic is being switched over to the extensive 


bypass LSP. 


Link has come back up and the LSP has been restored. Because the backup | extensive 
LSP is no longer needed, it is deleted. 


Displays the value of the path MTU received from the network (through _ detail 
signaling) and the value used for forwarding. This value is only displayed 

on ingress routing devices with the allow-fragmentation statement 

configured at the [edit protocols mpls path-mtu] hierarchy level. If there 

is a detour LSP, the path MTU for the detour is also displayed. 


Table 81: show rsvp session Output Fields (continued) 


Field Name 


Egress protection 
PLR as protector 


PATH rcvfrom 


Adspec 


PATH sentto 


Explct route 


Record route 


Field Description 


RSVP state on the Protector or the point-of-local-repair (PLR) routing 
device: 


e Active— Egress protection is available at the Protector or the PLR 
routing device. 


e In Use— Local repair has been completed. 


Address of the previous-hop (upstream) routing device or client, interface 
the neighbor used to reach this routing device, and number of packets 
received from the upstream neighbor. 


MTU signaled from the ingress routing device to the egress routing device 
by means of the adspec object. 


Address of the next-hop (downstream) routing device or client, interface 
used to reach this neighbor (or peer-name in the GMPLS LSP case), and 
number of packets sent to the downstream routing device. 


Explicit route for the session. Normally this value will be the same as that 
of record route. Differences indicate that path rerouting has occurred, 


typically during fast reroute. 


Recorded route for the session, taken from the record route object. 
Normally this value will be the same as that of explct route. Differences 
indicate that path rerouting has occurred, typically during fast reroute. 


| Sample Output 


show rsvp session 


user@host> show rsvp session 


LIMGiGSSS INSW2s 


TO 








To 


IG 2595245 .218 0 255,245.22 iNchimtiadia © iL me = BEADS 


HOEeSSs RSVPs 


1 sessions 
From State Rt Style Labelin Labelout 


Total 1 displayed, Up 1, Down 0 


2 sessions 
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Level of Output 


detail 


detail 


detail 


detail 


detail 


detail 


LSPname 





LSP Bidir 


From State Rt Style Labelin Labelout LSPname 


10.455.245.194 10,255.24 
IO .2S5 245.194 10. 255,24 
Total 2 displayed, Up 2, 


Transit RSVP: 1 sessions 
To From 
10.255 ,245 19%} 10 .255,24 


Total 1 displayed, Up 1, 





show rsvp session statistics 


5.195 Up 0 1FF 39811 
5.195 Up 0 1 FF 3 


— Gpro3-ba Bidir 
= DLOs—ba 


Down 0 


State Rt Style Labelin Labelout LSPname 





user@host> show rsvp session statistics 


Ingress RSVP: 2 sessions 


aie) From 
110), 25 5624S 6 2H! 10) 5255 624 
lOe25 oR 24524 10). 2535 624 


Total 2 displayed, Up 2, 





Egress RSVP: 2 sessions 


eis) From 
110) , 255-245) 522 10) .-2.595 24 
10) Zo 5 _24)5 22 10). 253 6 ae 


Total 2 displayed, Up 2, 
Transit RSVP: 0 sessions 


Total 0 displayed, Up 0, 





show rsvp session detail 


SLY? we 0 1 SE 100000 3 pro3-de 
Down 0 

State Packets Bytes LSPname 
Do BZ Up 0 0 pro3-bd 
Dea Up 44868 DSISASEG jorros—loel=2 
Down 0 

State Packets Bytes LSPname 
5.24 Up 0 0 pro3-db 
5.24 Up 0 @) pReES—Clo—zZ 
Down 0 
Down 0 


user@host> show rsvp session detail 


Ingress RSVP: 1 sessions 
Meg AL & Ales al 


From: 2.2.2.2, LSPstate: Up, ActiveRoute: 0 





LSPname: to-a, LSPpath: 


Primary 





Suggested label receiv 


d: -, Suggested label sent: 








Recovery label received: , Recovery label sent: 3 





Resv style: 1 FF, Label in: -, Label out: 3 


Time left: -, Since; 





Fri Mar 26 18:42:42 2004 


Tspec: rate 300kbps size 300kbps peak Infbps m 20 M 1500 


DiffServ info: diffServ-TE LSP, bandwidth: <ctl 300kbps> 





Port number: sender 1 receiver 15876 protocol 0 





PATH revfrom: localclient 
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Adspec: sent MTU 1500 
mI Semveos 192 168,37 ,16 (el-O/2/1,0)) 2 jolie 


show rsvp session detail (When Egress Protection Is in Standby Mode) 


user@host> show rsvp session detail 


Ingress RSVP: 1 sessions 

seeded 
From: 2.2.2.2, LSPstate: Up, ActiveRoute: 0 
LSPname: to-a, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 





Resv style: 1 FF, Label in: -, Label out: 3 
Wale: Ikeeie: ¢ =, Silineee wren Mare 26 Igsd@eeds ZOO 





Tspec: rate 300kbps size 300kbps peak Infbps m 20 M 1500 
Diiste tas Gira guisi Na @ celibate Sia sl Demis oF mule) ella GlWelkGlie ln mecertenlanes 10) Oj) Keloose= 





Port number: sender 1 receiver 15876 protocol 0 





Egress protection PLR as protector: Active 
PATH revfrom: localclient 

Adspec: sent MTU 1500 

PAW semcices LIY2.168.37,18 (el-O/2/1.0) 1 piece 


show rsvp session detail (When Egress Protection Is in Effect During a Local Repair) 


user@host> show rsvp session detail 


Ingress RSVP: 1 sessions 

Tell aul al 
From: 2.2.2.2, LSPstate: Down, ActiveRoute: 0 
LSPname: to-a, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 





Resv style: 1 FF, Label in: -, Label out: 3 
Time left: =, Silineee wie, Mere 26 lesa zeke Zoe 





Tspec: rate 300kbps size 300kbps peak Infbps m 20 M 1500 
DiffServ info: diffServ-TE LSP, bandwidth: <ctl 300kbps> 





Port number: sender 1 receiver 15876 protocol 0 





Egress protection PLR as protector: In Use 
PATH revfrom: localclient 
Adspec: sent MTU 1500 
PN SemiccOs LIZ .1S3. 57,16 (el-O/2/1.0)) 1 jle 
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show rsvp session detail (Path MTU Output Field) 


user@host> show rsvp session detail 


Ingress RSVP: 1 sessions 

10.255 4245 63 
From: 10.255.245.5, LSPstate: Up, ActiveRoute: 3 
LSPname: to-c, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 100432 





Resv style: 1 FF, Label in: -, Label out: 100432 
Time left: -, Since: Mon Aug 16 17:54:40 2006 





[spec: rate Obps size Obps peak Infbps m 20 M 9192 


Port number: sender 1 receiver 57843 protocol 0 





FastReroute desired 

PATH rcvfrom: localclient 

Adspec: sent MTU 4470 

Path mtu: received 4470, using 4458 for forwarding 
PAs SEMEEOS ID2.168.37.89 (so-O/2/3.0) Lil jlses 
NSW wewitwemes 192,153.57 .39 (so-0/2/3.0) 10 jokes 
ole weouires 192. 5s, 37 639) 

MaCOwe MouEes <SellirS 192. 1S8 S7o89) LOZ .LG8. 37 87 








Detour is Up 
Detour Tspec: rate Obps size Obps peak Infbps m 20 M 9192 
Detour adspec: sent MTU 1512 


Path mtu: received 1512, using 1500 for forwarding 


show rsvp session detail (GMPLS) 


user@host> show rsvp session detail 


Ingress RSVP: 1 sessions 
AG 5 AOE} 5 445 AL 
From: 192.168.1.1, LSPstate: Dn, ActiveRoute: 0 
LSPname: gmpls-rl-to-r3, LSPpath: Primary 
Bidirectional, Upstream label in: 21253, Upstream label out: — 
Suggested label received: -, Suggested label sent: 21253 








Recovery label received: , Recovery label sent: 





Resv style: 0 —, Label in: , Label out; — 
Time left: -, Since: Mon Aug 16 17:54:40 2006 
Tspec: rate Obps size Obps peak 155.52Mbps m 20 M 1500 








Port number: sender 2 receiver 46115 protocol 0 
PATH revfrom: localclient 


Adspec: sent MTU 1500 





PATH MTU: received 0 


PATE Ss ont teO m0 o> ene mm(s O— 01 27/.o01 0) mllenokates 
iolet iouices 100,100, 100,100 93.93.95. 93 
Record route: <self> 100.100.100.100 93.93.93.93 


Total 1 displayed, Up 0, Down 1 





Egress RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


show rsvp session extensive 


Starting in Junos OS Release 16.1, this command includes additional details for both the incoming and 
outgoing Path and Resv messages. The information includes the internal message handle and revision 
number, as well as the message ID included by the neighbor in the signaling message. 


user@host> show rsvp session extensive 


Ingress RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 





Egress RSVP: 0 sessions 


Total 0 displayed, Up 0, Down 0 


Transit RSVP: 1 sessions 





16.0 >50.5 
From: 16.0.0.1, LSPstate: Up, ActiveRoute: 0 
LSPname: 1to5, LSPpath: Primary 








Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 299856 
Resv style: 1 SE, Label in: 299776, Label out: 299856 
limes Lehue lS mG tnecrSOoteINOweZ on Ons Ol Sm 210se4 








[spec: rate Obps size Obps peak Infbps m 20 M 1500 





Port number: sender 1 receiver 52631 protocol 0 
PATH revirom: 16.1.2.1 (ge-0/0/0.0) 2 pkts 
incoming message handle: P-1/2, ID: Oxc82fd7/322 
Adspec: received MTU 1500 sent MTU 1500 

PATH sentto: 16.2.4.4 (ge-0/0/1.0) 1 pkts 








outgoing message state: refreshing, ID: Oxcacec0/22 

RiIGY wemrwoms 16 ,2,4,.4 (¢GSe-O/O/1L.O) i pies, Inmemoony ieloeils 
incoming message handle: R-2/1, ID: Oxc82f3e/217 

RESV 














outgoing message state: refreshing, ID: Oxcacec0/17 
usgolec mouices 16,.2,4.4 16.99.0.5 





tes 


2524 


2525 


iNexoloalel  sefoybherery AMG ak 2 ily <<isyepinee ISA) ee Roy SS) 10) 5) 
Total 1 displayed, Up 1, Down 0 


show rsvp session extensive transit 


Starting in Junos OS Release 16.1, this command also shows node-related details, including whether 
enhanced local protection is enabled for the LSP and whether the node is a merge point. If the latter is 
true, both the IP address of the Point of Local Repair (PLR) and the status (LP-MP, NP-MP, or Non-MP) 
are shown. 


user@host> show rsvp session extensive transit 


From: 81.1.1.1, LSPstate: Up, ActiveRoute: 0 





LSPname: A-D-1, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: -, Recovery label sent: 299776 
Resv style: 1 SE, Label in: 299776, Label out: 299776 
Time left: 117, Since: Tue May 6 08:39:44 2014 











[spec: rate 700Mbps size 700Mbps peak Infbps m 20 M 1500 


Port number: sender 1 receiver 24131 protocol 0 





Node/Link protection desired 

Type: Node/Link protected LSP, using Bypass—>81.2.3.3->81.3.4.4 
2 Mey © O8SSSeAy Woes SrOEScruGMm WS, Wsiing wYyoOass-Ssil.2,.3.3—-S81,3,4 4 
1 May 6 08:39:44 New bypass Bypass-—>81.2.3.3->81.3.4.4 

Enhanced local Protection: Enabled, LP-MP for 81.2.2.2, NP-MP for 81.1.1.1 

yrs wewarwoms Bil oh Zoi (ite-O0/2/0.201) Savi jokics 

Adspec: received MTU 1500 sent MTU 1500 

PATHS Semicon mG lnAn on San Clke— 0/27/0203) esis 7/4 soles 

Ri secwareoms Gil ,2.3.38 (ke-0/2/0.203)) SS72 jalsics, limltcicjony ilelosile iNo 

Rexcoiae! icepheee Bil,L,2,1 <seiieS i,8.5.,.8 (mmece—iel) S1,2.38.3 Slot o4.4 Coecl—iel)) 

81.3.4.4 

Total 1 displayed, Up 1, Down 0 

















If enhanced FRR is not enabled (either because it is disabled on the router itself or one of the neighbors 
along the LSP path does not support it), either of the following lines might be displayed: 





Enhanced Local Protection: Disabled, Reason: User Config 





Enhanced Local Protection: Disabled, Reason: Backward Compatibility 


If enhanced FRR is not enabled and the router is not an MP, the following line is displayed: 


Enabled, Non-MP 








Enhanced Local Protection: 


show rsvp session p2mp (Ingress Router) 


user@host> show rsvp session p2mp 


IMC TEDSS INVA s 
P2MP name: te 


3 sessions 


st, P2MP branch count: 1 





























To From State Rt Style 
10.255. 10.95 10 .255.,10.,2 Up 0 i Siz 
P2MP name: test2, P2MP branch count: 2 
To From State Rt Style 
10,255 410,23 10,255 410.2 Up © id Se 
10.255 , 10, 16 10.255 ,10),2 Up 9 i Ste 
Total 3 displayed, Up 3, Down 0 
Egress RSVP: O sessions 
Total 0 displayed, Up 0, Down 0 
Transit RSVP: 0 sessions 
Total 0 displayed, Up 0, Down 0 

show rsvp session p2mp (Transit Router) 

user@host> show rsvp session p2mp 
Ingress RSVP: 1 sessions 
P2MP name: test, P2MP branch count: 1 
To From State Rt Style 
IM 255 10,23 19 255.410, 95 Up 0 i Se 
Total 1 displayed, Up 1, Down 0 
Egress RSVP: 1 sessions 
P2MP name: test, P2MP branch count: 1 
To From State Rt Style 
10,255 ,10.,95 10.255 .,10,2 Up 0 id Se 


Total 1 displayed, Up 1, Down 0 





Transit RSVP: 2 sessions 





Labelin Labelout 
= 3 


Labelin Labelout 
= 299776 
= 299776 


Labelin Labelout 
= LOOP 


Labelin Labelout 
iS — 


LSPname 


to-pel 


LSPname 
to-pe3 
to-pe4 


LSPname 


to-pe2 


LSPname 


to-pel 
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P2MP name: test2, P2MP branch count: 


fe) From 
10) 255.610, 2S} 10) 255.610, 2 
10) 5215.5) 6 10h, 1G 10) 52155) - 1), 2 





Total 2 displayed, Up 2, Down 0 


State 


Up 
Up 


2 
Rt Style 
0 1 SE 
0 1 SE 





Labelin Labelout 


PNET TS) 
PRSNSHT) TS) 


299808 
ZOE S16 


LSPname 
to-pe3 
to-pe4 
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| show rsvp session 


Syntax 


show rsvp session 

<brief | detail | extensive | terse> 
<bidirectional | unidirectional> 
<down | up> 

<interface interface-name> 
<Isp-type> 

<name session-name> 
<session-type> 

<statistics> 

<te-link te-link> 


Release Information 
Command introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Display information about Resource Reservation Protocol (RSVP) sessions. 


Options 


none—Display standard information about all RSVP sessions. 
brief | detail | extensive | terse—(Optional) Display the specified level of output. 


bidirectional | unidirectional—(Optional) Display information about bidirectional or unidirectional RSVP 
sessions only, respectively. 


down | up—(Optional) Display only LSPs that are inactive or active, respectively. 
interface interface-name—(Optional) Display RSVP sessions for the specified interface only. 
Isp-type —(Optional) Display information about RSVP sessions with regard to LSPs: 


e bypass—Sessions used for bypass LSPs. 
e Isp—Sessions used to set up LSPs. 


e nolsp—Sessions not used to set up LSPs. 


name session-name—(Optional) Display information about the named session. 
session-type—(Optional) Display information about a particular session type: 


e egress—Sessions that terminate on this switch. 


e ingress—Sessions that originate from this switch. 
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e transit—Sessions that transit through this switch. 


statistics—(Optional) Display packet statistics. 


te-link te-link—(Optional) Display sessions with reservations on the specified traffic-engineered link name. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


Example: Configuring MPLS on EX8200 and EX4500 Switches | 42 

Configuring MPLS on Provider Edge EX8200 and EX4500 Switches Using Circuit Cross-Connect | 74 
Configuring MPLS on Provider Edge Switches Using IP-Over-MPLS | 68 

Configuring MPLS on EX8200 and EX4500 Provider Switches | 78 





List of Sample Output 

show rsvp session on page 2531 

show rsvp session statistics on page 2532 
show rsvp session detail on page 2532 
show rsvp session extensive on page 2533 


Output Fields 
Table 82 on page 2529 describes the output fields for the show rsvp session command. Output fields are 
listed in the approximate order in which they appear. 


Table 82: show rsvp session Output Fields 


Field Name Field Description Level of Output 
Ingress RSVP Information about ingress RSVP sessions. detail 
Ingress RSVP Information about ingress RSVP sessions. Each session has one line of All levels 
output. 
Egress RSVP Information about egress RSVP sessions. All levels 
Transit RSVP Information about the transit RSVP sessions. All levels 
To Destination (egress switch) of the session. All levels 


From Source (ingress switch) of the session. All levels 


Table 82: show rsvp session Output Fields (continued) 


Field Name 


State 


Address 


LSPstate 


Rt 


ActiveRoute 


LSPname 


LSPpath 


Recovery label 
received 


Recovery label 
sent 


Suggested label 
received 


Suggested label 
sent 


Resv style or 
Style 


Field Description 


State of the path: Up, Down, or AdminDn. AdminDn indicates that the 
LSP is being taken down gracefully. 


Destination (egress switch) of the LSP. 


State of the LSP that is being handled by this RSVP session. It can be 
either Up, Dn (down), or AdminDn. AdminDn indicates that the LSP is 
being taken down gracefully. 


Number of active routes (prefixes) that have been installed in the routing 
table. For ingress RSVP sessions, the routing table is the primary IPv4 
table (inet.0). For transit and egress RSVP sessions, the routing table is 
the primary MPLS table mpls.0). 


Number of active routes (prefixes) that have been installed in the 
forwarding table. For ingress RSVP sessions, the forwarding table is the 
primary IPv4 table (inet.O). For transit and egress RSVP sessions, the 
forwarding table is the primary MPLS table (mpls.0). 


Name of the LSP. 


Indicates whether the RSVP session is for the primary or secondary LSP 
path. LSPpath can be either primary or secondary and can be displayed 
on the ingress, egress, and transit switches. LSPpath can also indicate 
when a graceful LSP deletion has been triggered. 


(When LSP is bidirectional) Label the upstream node suggests for use in 
the Resv message that is sent. 


(When LSP is bidirectional) Label the downstream node suggests for use 
in its Resv messages that is returned. 


(When LSP is bidirectional) Label the upstream node suggests for use in 
the Resv message that is sent. 


(When LSP is bidirectional) Label the downstream node suggests for use 
in its Resv message that is returned. 


RSVP reservation style. This field consists of two parts. The first is the 
number of active reservations. The second is the reservation style, which 
can be FF (fixed filter), SE (shared explicit), or WF (wildcard filter). 


2530 


Level of Output 


All levels 


detail 


brief, detail 


brief 


detail 


brief, detail 


detail 


detail 


detail 


detail 


detail 


brief detail 


Table 82: show rsvp session Output Fields (continued) 
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Field Name Field Description Level of Output 
Label in Incoming label for this LSP. brief, detail 
Label out Outgoing label for this LSP. brief, detail 
Time left Number of seconds remaining in the lifetime of the reservation. brief, detail 
Since Date and time when the RSVP session was initiated. detail 
Tspec Sender's traffic specification, which describes the sender's traffic detail 
parameters. 
Port number Protocol ID and sender/receiver port used in this RSVP session. detail 
Creating backup — A link down event occurred, and traffic is being switched over to the extensive 
LSP, link down bypass LSP. 
Deleting backup — Link has come back up and the LSP has been restored. Because the backup | extensive 
LSP, protected LSP is no longer needed, it is deleted. 
LSP restored 
PATH rcvfrom Address of the previous-hop (upstream) switch or client, interface the detail 
neighbor used to reach this switch, and number of packets received from 
the upstream neighbor. 
| Sample Output 
show rsvp session 
user@switch> show rsvp session 
Ingress RSVP: 1 sessions 
To From State Rt Style Labelin Labelout LSPname 
IO s,255 245 214 I0,255 245.212 ichiaimidi © il ie = Baa S\s) iis) jest elat ie 








Total 1 displayed, Up 1, Down 0 


2 sessions 





CieSss GWE 


To From State Rt Style Labelin Labelout LSPname 
10 255.245 ,194 10.255. 245.195 Ups @ i wir Se culell = (Gjowos—lozl leaucliie 
10-255 .245 194 I0.255.245.195 Us @ il ie 3 = prose 


Total 2 displayed, Up 2, Down 0 


Transit RSVP: 1 sessions 


LO 255 s24So193 IO 2555245197 Ue @ iS 100000 





dee | 





Total 1 displayed, Up 1, Down 0 


show rsvp session statistics 


user@switch> show rsvp session statistics 


Ingress RSVP: 2 sessions 


To From State Packets Bytes 
10 255,445.24 10 255,245.22 Up 0 0 
10) 255.245 .,a4 10) 2595-24522 Up 44868 BRISA 


Total 2 displayed, Up 2, Down 0 





Egress RSVP: 2 sessions 


To From State Packets Bytes 
10 25), 245 22 10-255 ,245 24 Up 0 0 
10,255,245 242 10,295,245 24 Up 0 0 


Total 2 displayed, Up 2, Down 0 


Transit RSVP: 0 sessions 





Total 0 displayed, Up 0, Down 0 


show rsvp session detail 


user@switch> show rsvp session detail 


Ingress RSVP: 1 sessions 
eles ale 
From: 2.2.2.2, LSPstate: Up, ActiveRoute: 0 





LSPname: to-a, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





Recovery label received: , Recovery label sent: 3 





Resv style: 1 FF, Label in: -, Label out: 3 

Time left: =, Silimeas wien Mee 2O IeedacdD ZOOL 

Tspec: rate 300kbps size 300kbps peak Infbps m 20 M 1500 
DiffServ info: diffServ-TE LSP, bandwidth: <ctl 300kbps> 








Port number: sender 1 receiver 15876 protocol 0 





PATH revfrom: localclient 
Adspec: sent MTU 1500 
PMNS SemrctOs II2 168 .S7.16 (iel-O/2/i.0) 1 jolkeic 





fe) From State Rt Style Labelin Labelout LSPname 


3 pro3-de 


LSPname 
[Die S—leyel 
(sieOS=loel=2 


LSPname 
pro3-db 
EOS —do—s 
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show rsvp session extensive 


user@switch> show rsvp session extensive 


8.8 


9 Bo 


From: 9.9.9.9, LSPstate: Up, ActiveRoute: 0 


LSPname: lsp_to_240, LSPpath: Primary 





Suggested label received: -, Suggested label sent: 





R 


covery label received: , Recovery label sent: 322832 





Resv style: 1 FF, Label in: -, Label out: 322832 








bakes ILE 3 =, Simeae Wom welo 26 Iloszacss) 2009) 
[Tspec: rate Obps size Obps peak Infbps m 20 M 1500 
Port number: sender 2 receiver 44542 protocol 0 
PATH rcevfrom: localclient 

Adspec: sent MTU 1500 

Path MTU: received 1500 

PATHMSenttOnmoms om (xe—O)/sle/ OO) me2eiceno kates 

R] 





HSM wehweromes S.5,5.2 (xE-0/1/0.0) 2394 jolkcs 


Ibo wows So 35sio2 “Go ewak 
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| show rsvp statistics 


List of Syntax 
Syntax on page 2534 
Syntax (EX Series Switches) on page 2534 


Syntax 


show rsvp statistics 
<instance instance-name> 


<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


show rsvp statistics 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.5 for EX Series switches. 
instance option added in Junos OS Release 15.1 for the MX Series. 


Description 

Display Resource Reservation Protocol (RSVP) packet and error statistics. The RSVP input/input module 
collects statistics for certain events on a per-interface basis. Most of these events were tracked ona 
routing-instance basis in Junos OS releases earlier than Release 17.2. The "show rsvp interface detail" 
command displays these event counters under the Events section of the output only when the values of 
these fields are higher than zero. These statistics are also maintained at the global level (per routing-instance) 
and are also displayed in the output of the "show rsvp statistics" command. 


Options 
none—Display RSVP packet and error statistics. 


instance instance-name—(Optional) Display RSVP packet and error statistics for the specified instance. If 
instance-name is omitted, RSVP statistics are displayed for the master instance. 


logical-system (all |logical-system-name)—(Optional) Perform this operation on all logical systems or on a 
particular logical system. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


clear rsvp statistics | 2481 


List of Sample Output 


show rsvp statistics on page 2538 
show rsvp statistics on page 2539 


Output Fields 


Table 83 on page 2535 describes the output fields for the show rsvp statistics command. Output fields are 


listed in the approximate order in which they appear. 


Table 83: show rsvp statistics Output Fields 


Field Name 


Packet Type 


Total Sent 


Total Received 


Last 5 seconds Sent 


Last 5 seconds 


Received 


Path 


PathErr 


PathTear 


Resv FF 


Resv WF 


Res SE 


ResvErr 


Field Description 


Statistics about different RSVP messages. 


Total number of packets sent since RSVP was enabled. 


Total number of packets received since RSVP was enabled. 


Total number of packets sent in the last 5 seconds. 


Number of packets received in the last 5 seconds. 


Statistics about Path messages, which are sent from the RSVP sender along the data paths 


and which store path state information in each node along the path. 


Statistics about PathErr messages, which are advisory messages that are sent upstream to the 


sender. 


Statistics about PathTear messages, which remove path states and dependent reservation 


states in any routing devices along a path. 


Statistics about fixed-filter reservation style messages, which consist of distinct reservations 


among explicit senders. 


Statistics about wildcard-filter reservation style messages, which consist of shared reservations 
among wildcard senders. 


Statistics about shared-explicit reservation style messages, which consist of shared reservations 
among explicit senders. 


Statistics about ResvErr messages, which are advisory messages that are sent when an attempt 
to establish a reservation fails. 
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Table 83: show rsvp statistics Output Fields (continued) 


Field Name 


ResvTear 


ResvConf 


Ack 


SRefresh 


Hello 


EndtoEnd RSVP 


Errors 


Rcv pkt bad length 


Rev pkt unknown 
type 


Rcv pkt bad version 


Rcv pkt auth fail 


Rcv pkt bad 
checksum 


Rcv pkt bad format 


Memory allocation 
fail 


No path information 


Resv style conflict 


Port conflict 


Resv no interface 


PathErr to client 


Field Description 


Statistics about ResvTear messages, which remove reservation states along a path. 


Statistics about ResvConfirm messages, which are responses to confirm a reservation request. 


Acknowledge message for refresh reductions. 


Summary refresh messages. 


Number of RSVP hello packets that have been sent to and received from the neighbor. 


Statistics for the number of End-to-end RSVP messages. 


Statistics about errored RSVP packets. 


The packet was not processed because its length is inappropriate. 


The packet is not one of the well-known RSVP types, as defined in RFC 2205, Resource 
ReSerVation Protocol (RSVP). 


The packet is not an RSVP version 1 packet. 


The packet failed authentication checks. 


The RSVP checksum check failed. 


General packet processing failed because the packet was badly formed. 


An internal resource failure occurred. 


A reservation was received, but no sender is active. 


The same session contains inconsistent reservation styles. 


There were inconsistent port numbers for the same session. 


An interface for the receive reservation packets cannot be located. 


Number of PathErr packets delivered to the local client. 
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Table 83: show rsvp statistics Output Fields (continued) 


Field Name 


ResvErr to client 


Path timeout 


Resv timeout 


Message 
out-of-order 


Unknown ack msg 


Recv nack 


Recv duplicated 
msg-id 


No TE-link to recv 
Hop 


Rcv pkt disabled 
interface 


Transmit buffer full 


Transmit failure 


Receive failure 


P2MP RESV 
discarded by appl 


Rate limit 


Err msg loop 
detected 


Field Description 


Number of ResvErr packets delivered to the local client. 


Number of times the sender timed out because the path was removed. 


Number of times the receiver timed out because the reservation was removed. 


Records the number of RSVP incoming messages that are considered out of order. This is 
detected from the message ID object’s sequence number. 


A neighboring routing device replies with an ACK object that contains an unknown message 
ID. This can indicate a message ID handshake problem. For example, a router receives an ACK 
for message IDs 1, 2, and 3. However, it only has state for message IDs 1 and 3. The router 
increments the unknown ack counter by 1. 

If a neighboring router receives an unknown message ID in an RSVP refresh message, the 
router sends a Resv nack message back to the sender. This can happen if that neighbor has 
been rebooted. For this case, the router sends a regular RSVP refresh message to recover the 


state and start the message-ID handshake process again. 


Number of times the same message ID is used by two different RSVP messages. This duplication 
is usually caused when a neighboring routing device restarts. 


Counter of packets discarded because a TE link was not found. 


Number of RSVP packets received on an interface that is not enabled for RSVP. 


Number of times the buffer for assembling an outgoing RSVP message was not large enough. 


Number of times the RSVP task failed to send out a packet. 


Number of times the RSVP task failed to read an incoming packet. 


Number of Resv messages discarded because the MPLS label is not valid for the P2MP LSP 
application. 


Number of RSVP packets dropped due to rate limiting. 


Number of RSVP error messages that have looped back to their originator. This is detected 
by checking the error node address in the ERROR_SPEC object. 


| Sample Output 


show rsvp statistics 


Starting in Junos OS Release 16.1, this command also shows conditional PathTear statistics and the number 
of times an LSP state has been retained because of Link Protecting Merge Point (LP-MP) or Node Protecting 


Merge Point (NP-MP) determination. 


user@host> show rsvp statistics 























PacketType 
Sent 

Path Soo) 
PathErr 2 
PathTear 101 
Resv FF 0 
Resv WF 0 
Rese oF 419 
ResvErr 0 
ResvTear 0 
ResvConft 0 
Bundle 455 
Ack 682 
SRefresh 395198 
Hello 578809 
EndtoEnd RSVP 0 
Ocle rel iLe 50 
PathTear (Condl.) 0 
[Dueie(O)1ers} 





Rev pkt bad length 


Rev pkt unknown type 


Rev pkt bad version 


INGA jolie. Eiunelm ifeiat IL 


Rev pkt bad checksum 





Rev pkt bad format 


Memory allocation fail 


No path information 


Resv 
Port 

Resv 
Pathli 





Resv 
Path 


Resv 


style conflict 
Crouse Ia ere 

no interface 
Err to client 
Hicie 16; GlaSinie 
timeout 


timeout 


Moveculk 
Received 
408 
13 
i138) 
0 
0 
225 
0 
13 
0 
378 
1414 
236030 
SIQ2I 
0 
50 
S 


Total 


iS 


ie) i 
= Cf Cc e SoS aS oe eS eS S&S S&S S&S & & 


Oo 


Sent 


Last 5 seconds 


eee eS S| eS eS S&S oe oS ec eS S&S & 


Received 


oS 





So oS) 2 2 GS ©) oS 2S oS aS | Sl SS 


eo ory es Ww oo oe & @& S&S & Se 2 2 


Last 5 seconds 
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Messag 


Unknown ack msg 


Recv nack 


out-of-order 


Recv duplicated msg-id 


No T 





F-link to recv Hop 


Rev pkt disabled interface 





Receive failure 


P2MP 
Rate 














AL aiiqnalie 


Transmit buffer full 


Transmit failure 


Err msg loop detected 


Fast refresh skipped 


RESV discarded by appl 


P Path LP-avail rcved 
P Path NP-avail rcved 
PLR bk RSB life ext 
P bk PSB life ext 


P bk Srefresh Nack rcved 


2918 
86 


Ww 
S 
SQ ee oS ce =& =| S& 


LP-MP state retained on failure 


P-MP state retained on failure 


RSB life extended for nh FRR 


show rsvp statistics 


user@host> show rsvp statistics 


PacketType 


Path 





Resv 








Hello 
Ack 


PathErr 


PathTear 


ResvErr 
ResvTear 
ResvConf 


Bundle 


Srefresh 


Notify 


Unknown 








Endto 


End RSVP 








Backup Path 


Backup Tear 


sent 


172814 
iit 

142 

0 


a 2a oo ©& 


u@itecll 


Received 


Sy ea hy Gr ie eG Ts S&S 


IZ 3102 


143 


eo Ee S&S 


Se Ee S| S&S =] ec ec Sj S&S 


Last 5 seconds 


Sent 





eo eres Se SS St Ss aS Se SS aS Ss S&S 


Received 


SS SS oS SS SS aS Sl SS 








8G GS ee a SS ae as -S 


a oOo oo eo ea ee & & & 
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Cnd PathTear 0 
Rmt PathTear 0 
Rmt Backup 0 
lniere overs} 


Rev pkt bad length 
Rev pkt unknown type 
Rev pkt bad version 
Rev pkt auth fail 
Rev pkt bad checksum 





Rev pkt bad format 





ssage out-of-order 
Unknown msg-id ack 
Unknown msg-id nack 
Rev msg-id nack 

Rev pkt disabled interface 
Transmit failure 

emory allocation fail 
ID allocation failed 
No path information 
Resv style conflict 
Pomc On tenets 

Resv no interface 


Peiclaiier ico) C@llaemiec 





ResvErr to client 
Path timeout 


Resv timeout 





No TE-link to recv Hop 
Transmit buffer full 

P2MP RESV discarded by app 
Rate limit 





Err msg loop detected 
MP Path LP-avail rcved 
MP Path NP-avail rcved 
PLR bk RSB life ext 

RSB life ext for nh FRR 
P pri PSB life ext LP 
Revd state rejected 

No matching senders 


Del from client 


Enhanced FRR Stats 
.iP—-MP LSPs retained 
NP-MP LSPs retained 











Teiwcedl 


oa eo Ss = e& S&F @& S& = 2 SF Ss @ Ss |& Sf ce S&S S&S SoS 2S &O oS S&S & S& 2S S&S & S&S & S& 


Total 


Last 5 seconds 
0 





So x) 3S oo oS GS SS eS aa Sa SSS aS Se ss - 


Last 5 seconds 
0 
0 
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Non-MP LSPs deleted 
LSPs deleted on Phop 





NP flag reset for Ph 


Upstr long refresh L 
Upstr short refresh 





Dnstr long refresh L 


Dnstr short refresh 





RRO change Remote Pa 


down 


LSPs deleted on PPhop down 
LP avail signaled LSPs 


NP avail signaled LSPs 


Op 


LSPs retained on Cnd tear 


SES 
LSPs 
SPs 
Ses 


PathTear ignored on MP 


thTear 





Primary down Rmt Pat 





hTear 


ees aS ey Ge ce S&S = S&S & ec S&S S&S 


Ss oa oe a fe Se oS oS 2 So Ss we S&S 


2541 


2542 


| show rsvp version 


List of Syntax 
Syntax on page 2542 
Syntax (EX Series Switches) on page 2542 


Syntax 


show rsvp version 
<logical-system (all | logical-system-name)> 


Syntax (EX Series Switches) 


show rsvp version 


Release Information 
Command introduced before Junos OS Release 7.4. 
Command introduced in Junos OS Release 9.5 for EX Series switches. 


Description 

Display information about the Resource Reservation Protocol (RSVP) protocol settings, such as the version 
of the RSVP software, the refresh timer and keep multiplier, and local RSVP graceful restart capabilities 
on a routing device. 


Options 
none—Display RSVP protocol settings. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


List of Sample Output 
show rsvp version on page 2545 


Output Fields 


Table 84 on page 2543 describes the output fields for the show rsvp version command. Output fields are 
listed in the approximate order in which they appear. 
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Table 84: show rsvp version Output Fields 


Field Name 
Resource 
ReSerVation 
Protocol, version 
RSVP protocol 
R(refresh timer) 
K(keep multiplier) 
Preemption 
Soft-preemption 


cleanup 


Graceful deleting 
timeout 


NSR Mode 


NSR State 


Setup protection 


Field Description 


RSVP software version. 


Status of RSVP: Enabled or Disabled. 


Configured time interval used to generate periodic RSVP messages. 


Number of RSVP messages that can be lost before an RSVP state is declared stale. 


Currently configured preemption capability: Aggressive, Disabled, or Normal. The default is 
Normal. 


Time, in seconds, that an LSP is kept after it has been soft preempted. This is a global property 
of the RSVP protocol. 


Currently configured value for the graceful-deletion-timeout statement. The router that 
initiates the graceful deletion procedure for an RSVP session waits for the graceful deletion 
timeout interval to ensure that all routers along the path (especially the ingress and egress 
routers) have prepared for the LSP to be taken down. 


Status of the nonstop active routing feature for RSVP on the restarting device: Disabled, 
Enabled/Master, or Enabled/Standby. 


State of the nonstop active routing feature for RSVP on the restarting device. 
Possible values are: 


e Idle 


e TE-link sync complete 


Neighbor sync complete 


Path state sync complete 


e Resv state sync complete 


Bypass sync complete 


e Init sync complete 


Status of point-to-point and point-to-multipoint LSP setup protection configuration on the 
device: Enabled or Disabled. 
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Table 84: show rsvp version Output Fields (continued) 


Field Name 


Route Session-ld 
count 


Graceful restart 


Restart helper mode 


Maximum helper 
restart time 


Maximum helper 
recovery time 


Restart time 


Recovery time 


P2p transit LSP 
nexthop mode 


P2mp transit LSP 
nexthop mode 


Field Description 


Total count of session IDs associated with the combination of all the RSVP ingress routes. 


NOTE: Starting in Junos OS Release 16.1, the show rsvp version command output displays 
the Route Session-Id count output field by default, irrespective of the presence of associated 
session IDs. 


When there are no session IDs associated with any RSVP ingress route, the Route Session-Id 


count value is zero (0). 


Status of the graceful restart feature for RSVP on the restarting routing device: Enabled or 
Disabled. 


Status of the helper mode feature: Enabled or Disabled. When this feature is enabled, the 
restarting routing device can help the neighbor with its RSVP restart procedures. 


Number of milliseconds (ms) configured for the maximum helper restart time. The maximum 
helper restart time is the length of time the routing device waits before declaring that an RSVP 
neighbor attempting to restart gracefully is down. 


Number of milliseconds configured for the maximum helper recovery time. The maximum 
helper recovery time is the amount of time the routing device maintains the state of an RSVP 
neighbor attempting to restart gracefully. 


Number of milliseconds that a neighbor waits to receive a Hello message from the restarting 
node before declaring the node dead and deleting the states. 


Number of milliseconds during which the restarting node attempts to recover its lost states 
with help from its neighbors. Recovery time is advertised by the restarting node to its neighbors, 
and applies to nodal faults. The restarting node considers its graceful restart complete after 
this time has elapsed. 


Point-to-point transit LSP next-hop mode on PTX Series devices. The possible values are 
Chained or Unchained. 


Point-to-multipoint transit LSP next-hop mode on PTX Series devices. The possible values are 
Chained or Unchained. 


| Sample Output 


show rsvp version 


Starting with Junos OS Release 16.1, this command also shows whether enhanced FRR procurers are 


enabled on the router. 


user@host> show rsvp version 


Resource ReSerVation Protocol, version 1. rfc2205 


RSVP pErOeOCOL: 

R(refresh timer): 

K(keep multiplier): 
Preemption: 
Soft-preemption cleanup: 
Graceful deletion timeout: 
NSR mode: 

NSReSir ae: 

Setup protection: 

Route Session-Id count: 
Graceful restart: 

Restart helper mode: 
Maximum helper restart time: 


Maximum helper recovery tim 





Restart time: 
P2p transit LSP nexthop mode: 
P2mp transit LSP nexthop mode: 





Enhanced FRR local protection: 


Enabled 





S0Nscconcds 

3 

Normal 

30 seconds 
SU—seconcds 
Enabled/Master 
Init sync complete 
Disabled 

i. 
Disabled 
Enabled 
20000 msec 
180000 msec 


O msec 





Unchained 
Unchained 


Enabled 
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| traceroute mpls rsvp 


Syntax 


traceroute mpls <rsvp> Isp-name 
<detail> 

<egress> 

<exp> 

<logical-system> 

<multipoint> 

<no-resolve> 

<retries> 

<source source-address> 

<ttl> 


Release Information 
Command introduced in Junos OS Release 9.2. 
egress, multipoint, and ttl options added in Junos OS Release 11.2. 


Description 

Trace route to a remote host for an MPLS LSP signaled by RSVP. Use traceroute mpls rsvp as a debugging 
tool to locate MPLS label-switched path (LSP) forwarding issues in a network. (Currently supported for 
IPv4 packets only.) 


Options 
Isp-name—Specify the name of the LSP to be traced. 


detail—(Optional) Display detailed output. 


egress—(Optional) Request that a specific point-to-multipoint egress node reply to the trace route. The 
trace route would follow the associated sub-LSP to the egress node. 


exp—(Optional) Specify the class of service to use when sending probes. The range of values is O through 
7. The default value is 7. 


logical-system—(Optional) Specify the name of the logical system for the traceroute attempt. 
multipoint—(Optional) Perform a trace route on a point-to-multipoint LSP. 
no-resolve—(Optional) Specify not to resolve the hostname that corresponds to the IP address. 


retries—(Optional) Specify the number of times to resend probe. The range of values is 1 through 9. The 
default value is 3. 


source source-address—(Optional) Specify the source address of the outgoing traceroute packets. 


ttl—(Optional) Specify the number of hops to follow before forcing the trace route to quit. 
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Required Privilege Level 
network 


List of Sample Output 

traceroute mpls rsvp on page 2548 

traceroute mpls rsvp detail on page 2548 

traceroute mpls rsvp multipoint (branch node for sub-LSPs) on page 2549 
traceroute mpls rsvp multipoint (single-hop sub-LSPs) on page 2550 


Output Fields 

Table 85 on page 2547 describes the output fields for the traceroute mpls rsvp Isp-name and traceroute 
mpls rsvp Isp-name detail commands. Output fields are listed in the approximate order in which they 
appear. 


Table 85: traceroute mpls rsvp Output Fields 


Field Name Field Description Level of Output 
Probe options Probe options specified in the traceroute mpls rsvp Isp-name all levels 
command. 
ttl Time-to-live value of the labeled packet. none specified 
Label MPLS label used to forward the packets along the LSP. none specified 
Protocol Signaling protocol used. For this command, it is RSVP-TE. none specified 
Address Address of the next hop. none specified 
Previous Hop Address of the previous hop. Previous hop address of the first hop | none specified 
is null. 
Probe status Forwarding status from the first hop to the last-hop label-switching | none specified 


router (egress point in the label-switched paths). Displays Success 
if the trace to a hop is successful or Egress if the trace has reached 
the last router on the path. 


Hop Address of the hops in the label-switched path from the first hop | detail 
to the last hop. Depth indicates the level of the hop. 


Parent Address of the previous hop. Parent value for the first hop is null. | detail 


Return Code Return code for reporting the result of processing the echo request | detail 
by the receiver. 


Table 85: traceroute mpls rsvp Output Fields (continued) 


Field Name 


Sender timestamp 
Receiver timestamp 
Response time 
MTU 

Multipath type 


Label stack 


Path 


| Sample Output 


traceroute mpls rsvp 


Field Description 


Displays the timestamp when the MPLS echo request is sent to 
the next hop. 


Timestamp when the echo request from the previous hop is 
received and acknowledged with an echo response by the next 
hop. 


Time for the echo request to reach the receiver. 


Size of the largest packet that includes the label stack forwarded 
to the next hop. 


Labels or addresses used by the specified multipath type. If 
multipaths are not used, the value is none. 


Label stack used to forward the packet. 


Displays the sub-Isp path number for this traceroute, the interface 
used, and the destination address. 


user@host> traceroute mpls rsvp Isp-chicago-atlanta 


Probe option 


ieie dL Label 
1 BOY T G2 
2 299803 
S 3 














s: retries 3, exp 7 
Rrowocor: Address Previous Hop 
RSVP-TE 192.168.1142 (null) 
RSVP-TE 192, 168,243 192 16S. 1.2 
RSVP-TE 192.168.3.4 192 5168.2.3 








Path 1 via ge-0/0/0.1 destination 127.0.0.64 


traceroute mpls rsvp detail 


user@host> traceroute mpls rsvp Isp-chicago-atlanta detail 


Level of Output 


detail 


detail 


detail 


detail 


detail 


detail 


all levels 


Probe Status 
Success 


Success 





Home ss 
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Probe options: retries 3, exp 7 


laioye) A Gis. 152 Dysyorcla 
Probe status: Success 


Parent: (null) 





Return code: Label-switched at stack-depth 1 
Sender timestamp: 2008-04-17 09:35:27 EDT 400.88 msec 
Receiver timestamp: 2008-04-17 09:35:27 EDT 427.87 msec 








Response time: 26.99 msec 
MTU: Unknown 
Multipath type: IP bitmask 
Address Range I: 127.7020.64 ~— 127-0.0.127 
ral oie Sieaeker 
Label 1 Value 299792 Protocol RSVP-TE 





Beye 12 16s. 253 Deja 2 
Probe status: Success 
Deuasine f IZ. oe) iL, 2 





Return code: Upstream interface index unknown label-switched at stack-depth 


Sender timestamp: 2008-04-17 09:35:27 EDT 522.13 msec 
Receiver timestamp: 2008-04-17 09:35:27 EDT 548.69 msec 








Response time: 26.55 msec 
Marie AL) iLe) 
Multipath type: IP bitmask 
AddressmRanges 1s 0m OR 645 EAP Or Ore 2 7, 
fabolesitack:: 
Label 1 Value 299803 Protocol RSVP-TE 





traceroute mpls rsvp multipoint (branch node for sub-LSPs) 


The following traceroute output is for a point-to-multipoint LSP where the penultimate node is a branch 
node for the sub-LSPs. 


user@host> traceroute mpls rsvp multipoint p2mplsp 


Probe options: retries 3, exp 7 














iciedl, Label Protocol Address Previous Hop Probe Status 
il SOCU0G Rove -Te rere yaad ERE (ani) Success 
ze AIYVHNSS IXSwiP=e Shes Sole) Sladl oe od Success 
5 BYOSS2  INSNWAP— "IIE 81.3.4.4 G1 2c 35S SuCee sis 
4 BYSVSV0) IRIS WIE I Sl A oe6 tol Sit! Egress 
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Reheis 1 wale! dhe=1/2/10), 102 Claciesiaciesloim 127 0,0) ,62! 


wes Label Protocol Address Previous Hop Probe Status 
4 25992 0 Rov wnn ted Be eye) till G Sra ee! Egress 








Patan mevetculee—0/27/(0P OAc citecomaiteneo mmc Vi OROR OA 


traceroute mpls rsvp multipoint (single-hop sub-LSPs) 


The following traceroute output is for a point-to-multipoint LSP with multiple single-hop sub-LSPs. 
user@host> traceroute mpls rsvp multipoint p2mplsp 
Probe options: retries 3, exp 7 


ieicl Label Protocol Address Previous Hop Probe Status 
ale O)  IRYSWAP "ALi, Gil, 2 2 (null) Egress 








Peicin i waiter he=1/2/'0. O2 clasicilnveicien 1270 .0.,62 


ieiel Label Protocol Address Previous Hop Probe Status 
at; OC RSVP-TE te lee eee: (null) Egress 








Path 2 via 1t-1/2/0.108 destination 127.0.0.64 


ee IL Label Protocol Address Previous Hop Probe Status 
it O- BSVP=TE oi, 1.9.9 (null) Egress 








Path 3 via 1lt-1/2/0.109 destination 127.0.0.64 


CHAPTER 28 


LDP Operational Commands 
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| clear Idp neighbor 


Syntax 


clear Idp neighbor 

<instance instance-name> 

<logical-system (all | logical-system-name)> 
<neighbor> 


Description 


Tear down Label Distribution Protocol (LDP) neighbor connections. 


Options 


none—Tear down connections with all LDP neighbors for all routing instances. 
instance instance name—(Optional) Clear the LDP session for the specified routing instance only. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


neighbor—(Optional) Clear an LDP session for the specified neighbor (IP address) only. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 


show Idp neighbor | 2587 


List of Sample Output 
clear Idp neighbor on page 2552 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 


| Sample Output 


clear Idp neighbor 


user@host> clear Idp neighbor 
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| clear Idp session 


Syntax 


clear Idp session 

<all> 

<destination> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Clear Label Distribution Protocol (LDP) sessions. 


Options 


all—Clear LDP sessions for all destinations for all routing instances. 
destination—(Optional) Clear an LDP session for the specified destination (IP address). 
instance instance-name—(Optional) Clear the LDP session for the specified routing instance only. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 


show Idp session | 2609 


List of Sample Output 
clear Idp session on page 2554 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 
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Sample Output 


clear Idp session 


user@host> Clear Idp session all 
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| clear ldp statistics 


Syntax 


clear Idp statistics 
<instance instance-name> 
<logical-system (all | logical-system-name)> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Set all Label Distribution Protocol (LDP) statistics to zero. 


Options 


none-—Set all LDP statistics to zero for all routing instances. 
instance instance-name—(Optional) Clear the LDP session for the specified routing instance only. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 


show Idp statistics | 2617 
show Idp traffic-statistics | 2623 


List of Sample Output 
clear Idp statistics on page 2555 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. 


| Sample Output 


clear Idp statistics 


user@host> Clear Idp statistics 
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| ping mpls Idp 


Syntax 


ping mpls Idp fec 

<count count> 

<destination address> 

<detail> 

<exp forwarding-class> 

<instance routing-instance-name> 
<logical-system (all | logical-system-name)> 
<p2mp root-addr ip-address Isp-id identifier> 
<size bytes> 

<source source-address> 
<stitched-protocol> 


<sweep> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Command introduced in Junos OS Release 9.0 for EX Series switches. 

size and sweep options introduced in Junos OS Release 9.6. 

instance option introduced in Junos OS Release 10.0. 

p2mp, root-address, and Isp-id options introduced in Junos OS Release 11.2. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Check the operability of MPLS LDP-signaled label-switched path (LSP) connections. Type Ctrl+c to interrupt 
a ping mpls command. 


Options 
count count—(Optional) Number of ping requests to send. If count is not specified, five ping requests are 
sent. The range of values is 1 through 1,000,000. The default value is 5. 


destination address—(Optional) Specify an address other than the default (127.0.0.1/32) for the ping echo 
requests. The address can be anything within the 127/8 subnet. 


detail—(Optional) Display detailed information about the echo requests sent and received. 
exp forwarding-class—(Optional) Value of the forwarding class for the MPLS ping packets. 
fec—Ping an LDP-signaled LSP using the forwarding equivalence class (FEC) prefix and length. 


instance routing-instance-name—(Optional) Allows you to ping a combination of the routing instance and 
forwarding equivalence class (FEC) associated with an LSP. 
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logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on 
the specified logical system. 


p2mp root-addr ip-address Isp-id identifier—(Optional) Ping the end points of a point-to-multipoint LSP. 
Enter the IP address of the point-to-multipoint LSP root and the ID number of the point-to-multipoint 
LSP. 


size bytes—(Optional) Size of the LSP ping request packet (88 through 65468 bytes). Packets are 4-byte 
aligned. For example, If you enter a size of 89, 90, 91, or 92, the router or switch uses a size value of 
92 bytes. If you enter a packet size that is smaller than the minimum size, an error message is displayed 
reminding you of the 88-byte minimum. 


source source-address—(Optional) IP address of the outgoing interface. This address is sent in the IP source 
address field of the ping request. If this option is not specified, the default address is usually the 
loopback interface (lo.0). 


stitched-protocol—(Optional) Protocol stitched on intermediate node. 


sweep—(Optional) Automatically determine the size of the maximum transmission unit (MTU). 


Additional Information 

If the LSP changes, the label and interface information displayed when you issued the ping command 
continues to be used. You must configure MPLS at the [edit protocols mpls] hierarchy level on the remote 
router or switch to ping an LSP terminating there. You must configure MPLS even if you intend to ping 
only LDP forwarding equivalence classes (FECs). 


You can configure the ping interval for the ping mpls Idp command by specifying a new time in seconds 
using the Isp-ping-interval statement at the [edit protocols Idp oam] hierarchy level. For more information, 
see the MPLS Applications User Guide. 


In asymmetric MTU scenarios, the echo response may be dropped. For example, if the MTU from System 
A to System B is 1000 bytes, the MTU from System B to System A is 500 bytes, and the ping request 
packet size is 1000 bytes, the echo response is dropped because the PAD TLV is included in the echo 
response, making it too large. 


NOTE: Ina Juniper-Cisco interoperation network scenario, a point-to-multipoint LSP ping echo 
reply message from a Cisco device in a different IGP area is dropped on the Juniper device when 
the source address of the reply message is an interface address other than the loopback address 
or router ID. Starting in Junos OS Release 13.3X8, 14.2R6, 15.1R4, 15.1F6, 15.1F5-S8, 16.1R1, 
and later releases, such point-to-multipoint LSP ping echo reply messages are accepted by the 
Juniper device and the messages get logged as uncorrelated responses. 


Required Privilege Level 
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network 


List of Sample Output 
ping mpls Idp fec count on page 2558 
ping mpls Idp p2mp root-addr Isp-id on page 2558 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. An exclamation 
point (!) indicates that an echo reply was received. A period (.) indicates that an echo reply was not received 
within the timeout period. An x indicates that an echo reply was received with an error code. Packets with 
error codes are not counted in the received packets count. They are accounted for separately. 


Sample Output 
ping mpls Idp fec count 


user@host> ping mpls Idp 10.255.245.222 count 10 


ESS <a SS NGS siesm ll oAckCilsmeracin sinc pao M Od Cl<cie smae C Cunie cl mm Ol5 


packet loss 4 packets received with error status, not counted as received. 


ping mpls Idp p2mp root-addr Isp-id 
user@host>ping mpls Idp p2mp root-addr 10.1.1.1/32 Isp-id 1 count 1 


Request for seq 1, to interface 71, no label stack. 


Request for seq 1, to interface 70, label 299786 





Reply for seq 1, egress 10.1.1.3, return code: Egress-ok, time: 18.936 ms 
Local transmit time: 2009-01-12 03:50:03 PST 407.281 ms 
Remote receive time: 2009-01-12 03:50:03 PST 426.217 ms 








Reply for seq 1, egress 10.1.1.4, return code: Egress-ok, time: 18.936 ms 
local, transmit tame: 2009-01-12 037 50)08°PSr 407.231) ms 
Remote receive time: 2009-01-12 03:50:03 PST 426.217 ms 








Reply for seq 1, egress 10.1.1.5, return code: Egress-ok, time: 18.936 ms 
Locale transmit ime 200 9-0R—=1 2503S 50 0S PS e40i 22 38iims 
Remote receive time: 2009-01-12 03:50:03 PST 426.217 ms 
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| ping mpls segment routing ospf 
Syntax 


ping mpls segment routing ospf fec 
<count count> 

<destination address> 

<detail> 

<exp forwarding-class> 

<instance routing-instance-name> 
<logical-system (all | logical-system-name)> 
<p2mp root-addr ip-address Isp-id identifier> 
<size bytes> 

<source source-address> 
<stitched-protocol> 


<sweep> 


Release Information 
Command introduced in Junos OS Release 19.1R1 


Description 
Check the operability of MPLS segment routing label-switched path (LSP) connections added by ospf 
protocol. Type Ctrl+c to interrupt a ping mpls segment routing ospf command. 


Options 
count count—(Optional) Number of ping requests to send. If count is not specified, five ping requests are 
sent. The range of values is 1 through 1,000,000. The default value is 5. 


destination address—(Optional) Specify an address other than the default (127.0.0.1/32) for the ping echo 
requests. The address can be anything within the 127/8 subnet. 


detail—(Optional) Display detailed information about the echo requests sent and received. 
exp forwarding-class—(Optional) Value of the forwarding class for the MPLS ping packets. 
fec—Ping an LDP-signaled LSP using the forwarding equivalence class (FEC) prefix and length. 


instance routing-instance-name—(Optional) Allows you to ping a combination of the routing instance and 
forwarding equivalence class (FEC) associated with an LSP. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on 
the specified logical system. 


p2mp root-addr ip-address Isp-id identifier—(Optional) Ping the end points of a point-to-multipoint LSP. 
Enter the IP address of the point-to-multipoint LSP root and the ID number of the point-to-multipoint 
LSP. 
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size bytes—(Optional) Size of the LSP ping request packet (88 through 65468 bytes). Packets are 4-byte 
aligned. For example, If you enter a size of 89, 90, 91, or 92, the router or switch uses a size value of 
92 bytes. If you enter a packet size that is smaller than the minimum size, an error message is displayed 
reminding you of the 88-byte minimum. 


source source-address—(Optional) IP address of the outgoing interface. This address is sent in the IP source 
address field of the ping request. If this option is not specified, the default address is usually the 
loopback interface (lo.0). 


stitched-protocol—(Optional) Protocol stitched on intermediate node. 


sweep—(Optional) Automatically determine the size of the maximum transmission unit (MTU). 


Required Privilege Level 
network 


List of Sample Output 
ping mpls segment-routing ospf on page 2560 
ping mpls segment-routing isis on page 2560 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. An exclamation 
point (!) indicates that an echo reply was received. A period (.) indicates that an echo reply was not received 
within the timeout period. An x indicates that an echo reply was received with an error code. Packets with 
error codes are not counted in the received packets count. They are accounted for separately. 


Sample Output 
ping mpls segment-routing ospf 


user@host>ping mpls segment-routing ospf 6.6.6.6 


=== Ispilmg Stairisties === 


5 packets transmitted, 5 packets received, 0% packet loss 


ping mpls segment-routing isis 


user@host>ping mpls segment-routing ospf 6.6.6.6 detail 


Request for seq 1, to interface 333, label 22, packet size 80 





Reply for seq 1, return code: Egress-ok, time: -—7542.667 ms 
ineyeeull EMEINEIEE Teale ZOLI-O0S-OG iilsSaso0s tS 639.914 is 





Remote receive tim 
Request for seq 2, 
Reply for seq 2, return code: 


Local transmit time: 


to interface 333, 


2OLI—-O3—-06 lieSdes6 usa $7,247 a0 
label 22, packet size 80 
Egress-ok, time: -—7543.680 ms 


AOLI—-OS-O6 Lilesss@4 Sr 64.965 ims 








Remote receive tim 
Request for seq 3, 
Reply for seq 3, return code: 
Local transmit time: 
Remote receive time: 
Request for seq 4, 
Reply for seq 4, return code: 
Local transmit time: 
Remot 


receive tim 


to interface 333, 


to interface 333, 





2019-03-06 lisgsasa7 wr 83.285 a0 
label 22, packet size 80 
Egress-—ok, time: —7530.457 ms 
2OLG-OS-OG LigSs305 usw 639.923 ims 
ZOLIOS—-OG LieS4ss53 usw LOS ASG ims 


Tale 22, 








packet size 80 
Egress-—ok, time: —7540.548 ms 
2019-O3-06 LighssO6 usr 642.970 ms 
2019-03-06 Ligsdeso usr 102.322 ims 











Request for seq 5, 
Reply for seq 5, return code: 
Local transmit time: 
Remot 


receive tim 


to interface 333, 


label 22, packet size 80 


—POAO M12 iis} 





Egress-—ok, time: 








=== iIsjimg Staitisties === 


5 packets transmitted, 


ZOLG—OS=O6 LilsSSsO7 usu 646.870 ime 
2019-03-06 LlisSse0O use 106,193 me 
5 packets received, 0% packet loss 
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| ping mpls segment routing isis 
Syntax 


ping mpls segment routing isis fec 

<count count> 

<destination address> 

<detail> 

<exp forwarding-class> 

<instance routing-instance-name> 
<logical-system (all | logical-system-name)> 
<p2mp root-addr ip-address Isp-id identifier> 
<size bytes> 

<source source-address> 
<stitched-protocol> 


<sweep> 


Release Information 
Command introduced in Junos OS Release 19.1R1 


Description 
Check the operability of MPLS segment routing label-switched path (LSP) connections added by ISIS 
protocol. Type Ctrl+c to interrupt a ping mpls segment routing isis command. 


Options 
count count—(Optional) Number of ping requests to send. If count is not specified, five ping requests are 
sent. The range of values is 1 through 1,000,000. The default value is 5. 


destination address—(Optional) Specify an address other than the default (127.0.0.1/32) for the ping echo 
requests. The address can be anything within the 127/8 subnet. 


detail—(Optional) Display detailed information about the echo requests sent and received. 
exp forwarding-class—(Optional) Value of the forwarding class for the MPLS ping packets. 
fec—Ping an LDP-signaled LSP using the forwarding equivalence class (FEC) prefix and length. 


instance routing-instance-name—(Optional) Allows you to ping a combination of the routing instance and 
forwarding equivalence class (FEC) associated with an LSP. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on 
the specified logical system. 


p2mp root-addr ip-address Isp-id identifier—(Optional) Ping the end points of a point-to-multipoint LSP. 
Enter the IP address of the point-to-multipoint LSP root and the ID number of the point-to-multipoint 
LSP. 
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size bytes—(Optional) Size of the LSP ping request packet (88 through 65468 bytes). Packets are 4-byte 
aligned. For example, If you enter a size of 89, 90, 91, or 92, the router or switch uses a size value of 
92 bytes. If you enter a packet size that is smaller than the minimum size, an error message is displayed 
reminding you of the 88-byte minimum. 


source source-address—(Optional) IP address of the outgoing interface. This address is sent in the IP source 
address field of the ping request. If this option is not specified, the default address is usually the 
loopback interface (lo.0). 


stitched-protocol—(Optional) Protocol stitched on intermediate node. 


sweep—(Optional) Automatically determine the size of the maximum transmission unit (MTU). 


Required Privilege Level 
network 


List of Sample Output 
ping mpls segment-routing isis on page 2563 
ping mpls segment-routing isis on page 2563 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. An exclamation 
point (!) indicates that an echo reply was received. A period (.) indicates that an echo reply was not received 
within the timeout period. An x indicates that an echo reply was received with an error code. Packets with 
error codes are not counted in the received packets count. They are accounted for separately. 


Sample Output 
ping mpls segment-routing isis 


user@host>ping mpls segment-routing isis 6.6.6.6 


=== Ispilmg Stairisties === 


5 packets transmitted, 5 packets received, 0% packet loss 


ping mpls segment-routing isis 


user@host>ping mpls segment-routing isis 6.6.6.6 detail 


Request for seq 1, to interface 333, label 402006, packet size 80 





Reply for seq 1, return code: Egress-ok, time: -—7539.106 ms 
ineyeeul (EaeIMEIENE Tease ZOLIOS—-OH iiso4lsils wSw Ooo iss) is 





Remote receive tim 


AQOLI—O3-O6G iigSé4e@s} Se 427.777 wis 


Request for seq 2, to interface 333, label 402006, packet size 80 


Reply for seq 2, return code: 


Local transmit time: 





ZOLQ—-OS—-06G LieS4sil6 1S 
AGILI-OIS0K6 iLike Sts) Iss 





Remote receive tim 


Egress-—ok, time: -—7535.925 ms 


COV SOO ims 
[T 442.965 ms 





Request for seq 3, to interface 333, label 402006, packet size 80 


Reply for seq 3, return code: 
Local transmit time: 


Remote receive time: 





ZOLP-OS-06 Ligs4si7 1Si 
AOLI—-O3—O6G ie Sasi 191 


Egress-—ok, time: -—7526.134 ms 


U Q7Z.870 ime 
rT 446.736 ms 





Request for seq 4, to interface 333, label 402006, packet size 80 


Reply for seq 4, return code: 


Local transmit time: 





AGIOS =06 jLikg Baby ile) ISy1 
Z20ILI—OJ—06G iig Sagal 1S 





Remote receive tim 


Egress-—ok, time: —7539.500 ms 


[T 967.014 ms 
UAW Silay iss 





Request for seq 5, to interface 333, label 402006, packet size 80 


Reply for seq 5, return code: 


Local transmit time: 





AOLI—-O3S—O6G isSasig9 1S 
AGILI—O3=0i iLike SyalyilA Iss 





Remote receive tim 


=== iIsjimg Statisties === 


Egress-—ok, time: —7539.605 ms 


E Yor s93e ms 
[T 430.288 ms 





5 packets transmitted, 5 packets received, 0% packet loss 
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| ping mpls segment routing spring-te 
Syntax 


ping mpls segment-routing spring-te 

<egress-ip (active | color | count | detail | exp | instance | logical-system | secondary | segment-list | size | 
skip-fec-validation | source | sweep | tunnel-source) > 

<label-stack ( detail | egress | labels | logical-system | nexthop-address | nexthop-interface ) > 

<source-routing-path ( active | color | count | detail | egress-ip | exp | instance | logical-system | secondary | segment-list 
| size | skip-fec-validation | source | sweep | tunnel-source> 


Release Information 
Command introduced in Junos OS Release 20.2R1 for ACX Series, MX Series, PTX Series. 


Description 

Check the operability of MPLS segment routing label-switched path (LSP) connections added by segment 
routing traffic-engineered (SPRING-TE) protocol. Type Ctrl+c to interrupt a ping mpls segment routing 
spring-te command. 


Options 


egress-ip— Specify to ping to or install IP address to use when sending probes. 


active— Specify to use the forwarding path or nexthops from the RIB table. 


color— Specify the color identifier for the tunnel end-point. 
Range: 1 through 4294967295 


count count—(Optional) Number of ping requests to send. If count is not specified, five ping requests 
are sent. 


Range: 1 through 1000000 
Default: 5 


detail—(Optional) Display detailed output. 


exp exp—(Optional) Specify the class of service to use when sending probes. 
Range: O through 7 


instance routing-instance-name—(Optional) Allows you to ping a combination of the routing instance 
and forwarding equivalence class (FEC) associated with an LSP. 


logical-system logical-system-name—(Optional) Specify the name of the logical system. 
secondary— Specify to use configured secondary segment list for the given segment routing path. 


segment-list— Specify the segment list to use when sending probes. 


size bytes—(Optional) Size of the LSP ping request packet (88 through 65468 bytes). Packets are 4-byte 
aligned. For example, If you enter a size of 89, 90, 91, or 92, the router or switch uses a size value 
of 92 bytes. If you enter a packet size that is smaller than the minimum size, an error message is 
displayed reminding you of the 88-byte minimum. 


skip-fec-validation— Specify to skip forwarding equivalence class (FEC) validation or use NIL FEC. 


source source-address—(Optional) IP address of the outgoing interface. This address is sent in the IP 
source address field of the ping request. If this option is not specified, the default address is usually 
the loopback interface (lo.0). 


sweep—(Optional) Automatically determine the size of the maximum transmission unit (MTU). 
tunnel-source— Specify the source protocol used to create tunnel. 


label-stack— Specify label stack for ping packets. This option works only if you do a minimum configuration 
of source-packet-routing at the [edit protocols] hierarchy level. 


detail—(Optional) Display detailed output. 
egress— Specify the egress IP address. 


labels— Specify the labels in label stack. 
Range: 16 through 1048575 


logical-system logical-system-name—(Optional) Specify the name of the logical system. 
nexthop-address address— Specify the nexthop IP address for the ping packet. 
nexthop-interface interface— Specify the outgoing interface for the ping packet. 

source-routing-path— Specify ping source path routing to use when sending probes. 
active— Specify to use the forwarding path or nexthops from the RIB table. 


color— Specify the color identifier for the tunnel end-point. 
Range: 1 through 4294967295 


count count—(Optional) Number of ping requests to send. If count is not specified, five ping requests 
are sent. 


Range: 1 through 1000000 
Default: 5 


detail—(Optional) Display detailed output. 


egress-ip— 
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exp exp—(Optional) Specify the class of service to use when sending probes. 


Range: O through 7 


instance routing-instance-name—(Optional) Allows you to ping a combination of the routing instance 
and forwarding equivalence class (FEC) associated with an LSP. 


logical-system logical-system-name—(Optional) Specify the name of the logical system. 
secondary— Specify to use configured secondary segment list for the given segment routing path. 
segment-list— Specify the segment list to use when sending probes. 


size bytes—(Optional) Size of the LSP ping request packet (88 through 65468 bytes). Packets are 4-byte 
aligned. For example, If you enter a size of 89, 90, 91, or 92, the router or switch uses a size value 
of 92 bytes. If you enter a packet size that is smaller than the minimum size, an error message is 
displayed reminding you of the 88-byte minimum. 


skip-fec-validation— Specify to skip forwarding equivalence class (FEC) validation or use NIL FEC. 


source source-address—(Optional) IP address of the outgoing interface. This address is sent in the IP 
source address field of the ping request. If this option is not specified, the default address is usually 
the loopback interface (lo.0). 


sweep—(Optional) Automatically determine the size of the maximum transmission unit (MTU). 


tunnel-source— Specify the source protocol used to create tunnel. 


Additional Information 
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NOTE: With segment-list option, valid tunnel-source (source protocol used to create tunnel) is 
only static. 


NOTE: segment-list option is not present when tunnel-source is BGP SR-TE since BGP SR-TE 
does not have named segment list. 


NOTE: With source-routing-path name, valid tunnel-source are PCEP and static. 


NOTE: With tunnel-source as PCEP, secondary option is not valid as PCEP always sends one 
primary LSP. 


NOTE: FEC validation is performed for ping mpls segment-routing spring-te by default. 


NOTE: FEC validation is supported when segment-routing traffic-engineering (SR-TE) tunnel 
has IGP labels (OSPF and IS-IS) only. For all the other labels (for example, static, Idp, rsvp, etc.), 
you can use skip-fec-validation option. 


NOTE: For a combination of egress-ip and color options, valid tunnel-source are static and 
BGP-SR-TE. 


NOTE: ping mpls segment-routing spring-te command with label-stack option is supported in 
operational mode only. It is not supported in configuration mode. 


NOTE: Parallel SID, binding SID, LDP over SR-TE is not supported. 
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NOTE: ping mpls segment-routing spring-te for SR-TE tunnel is supported only on the ingress 
router of the SR-TE tunnel and not on the SR-TE tunnel in the transit path. 


NOTE: ping mpls segment-routing spring-te command with label-stack option adds explicit null 
label at the bottom of the label stack for interoperability. You can include NIL FEC for label “O” 
or “router alert label” per OAM standard. 


Required Privilege Level 
network 


List of Sample Output 

ping mpls segment-routing spring-te on page 2569 

ping mpls segment-routing spring-te (label-stack) on page 2569 

ping mpls segment-routing spring-te (source-routing-path) on page 2570 

ping mpls segment-routing spring-te (egress-ip) 5.5.5.5 color 6 skip-fec-validation detail on page 2571 


Output Fields 


When you enter this command, you are provided feedback on the status of your request. An exclamation 
point (!) indicates that an echo reply was received. A period (.) indicates that an echo reply was not received 
within the timeout period. An x indicates that an echo reply was received with an error code. Packets with 
error codes are not counted in the received packets count. They are accounted for separately. 


| Sample Output 


ping mpls segment-routing spring-te 


user@host> ping mpls segment-routing spring-te 


Possible completions: 
source-routing-path Source Path routing to use when sending probes 


egress-—ip To/Install IP address to use when sending probes 





label-stack Label stack for traceroute packets 


ping mpls segment-routing spring-te (label-stack) 
user@host>ping mpls segment-routing spring-te label-stack labels [10153 10152] nexthop-address 
23.0.1.2 nexthop-interface ge-0/0/0.0 egress 5.5.5.5 detail 
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Request for seq 1, to interface 333, labels <0, 10153, 10152>, packet size 88 





Reply for seq 1, return code: Egress-ok, time: 4.009 ms 








locals transmit stames 2020-02-06 012 0252505. 
Remomen sec civic tame me OO Oe Oe Zien 0 AirtS 2 ele Gule 


530.885 ms 
534.894 ms 


Request for seq 2, to interface 333, labels <0, 10153, 10152>, packet size 88 





Reply for seq 2, return code: Egress-ok, time: 4.117 ms 











hOGA Cease CMSs ZOZO-—O2Z=-06G 12902355) 1s 
Remote receive time: 2020-02-06 12:02:53 IST 


HIOs370 ws 
534.987 ms 


Request for seq 3, to interface 333, labels <0, 10153, 10152>, packet size 88 





Reply for seq 3, return code: Egress-ok, time: 4.121 ms 











Ie eens cesT: L2OAO-U2—06G L2s02354 isi 
Remote. secemve tame) 20Z0>02—06 1202154 ror 


S30, SiS) ais 
HI9sOS6 iis 


Request for seq 4, to interface 333, labels <0, 10153, 10152>, packet size 88 





Reply for seq 4, return code: Egress-ok, time: 3.979 ms 











hOGal PeaAMNSaMaLic cass ZO2O-O2-06 12s02355 1Ssw 
Remote receive time: 2020-02-06 12:02:55 IST 


Done comms 
535.848 ms 


Request for seq 5, to interface 333, labels <0, 10153, 10152>, packet size 88 





Reply for seq 5, return code: Egress-ok, time: 3.707 ms 











=== Igjimg Statisties === 


Local transmit times 2020-02-06 L202 :56 1ST 
Remote receive time: 2020-02-06 12:02:56 IST 


SAO. 960 is 
534.667 ms 


5 packets transmitted, 5 packets received, 0% packet loss 


ping mpls segment-routing spring-te (source-routing-path) 


user@host>ping mpls segment-routing spring-te source-routing-path path_1 egress-ip 5.5.5.5 color 6 


skip-fec-validation detail 


Request for seq 1, to interface 334, labels <900005, 





Reply for seq 1, return code: Egress-ok, time: -1207. 


heal Pisainsimabic tcames 2OLG-04-—O2 O©GsA9s55 usa 
Remote receive time: 2019-04-02 09:29:54 IS!1 
Request for seq 2, to interface 334, labels <900005, 











Reply for seq 2, return code: Egress-ok, time: -1161. 


Ine eiceisimiie tcaines 2OLI-O4-02 WSerIeae isi 
Remote receive time: 2019-04-02 09:29:55 IS1 
Request for seq 3, to interface 334, labels <900005, 














Reply for seq 3, return code: Egress-ok, time: -1206. 


Ica icieeuisimabic cames 2OIS- 04-027 OOsA9s57 1S 
Remote receive time: 2019-04-02 09:29:56 IS1 











900041>, packet size 76 
605 ms 

548.038 ms 

340.433 ms 

900041>, packet size 76 
DS Omens 

544.832 ms 

BIS .27 7 wis 

900041>, packet size 76 
463 ms 

542.845 ms 

336.382 ms 


Request for seq 4, 


Reply for seq 4, return code: 
Local transmit time: 


Remote receiv 











Request for seq 5, 


Reply for seq 5, return code: 


Local transmit time: 





Remote receiv 











=== Igjolmg Sitsiristies === 


5 packets transmitted, 


to interface 334, labels <900005, 
Egress—-ok, time: -1223. 

AQLS—O4=02 O8g29s5ea TSW 

tim ZOL9-W4-02 OOe29s57 sw 

to interface 334, labels <900005, 
Egress-—ok, time: -1025. 

AVL9—O4-02 Os 29359 WS 

feet) AQVLO=O4=02 O8g29358 1S 

5 packets received, 0% packet 
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900041>, packet size 76 
260 ms 

543.824 ms 

320.564 ms 

900041>, packet size 76 
098 ms 

548.127 ms 

523.029) ims 

losis 


ping mpls segment-routing spring-te (egress-ip) 5.5.5.5 color 6 skip-fec-validation detail 


user@host>ping mpls segment-routing spring-te egress-ip 5.5.5.5 color 6 skip-fec-validation detail 


Request for seq 1, 


Reply for seq 1, return code: 


Local transmit time: 


to interface 334, 


labels <900005, 
Egress—-ok, time: -1224. 
AQVLS=O4=02 O8eg43e3o 1S 











Remote receive tim 


Request for seq 2, 
Reply for seq 2, return code: 


Local transmit time: 





Remote receive time: 
Request for seq 3, 
Reply for seq 3, return code: 


Local transmit time: 


POutMEertacems oA 


Gomintictietacemss4, 


A0L9-04-02 O8esdsss4 ws 
labels <900005, 
Egress-ok, time: -1222 
2019-04-02 09:43:36 IST 
AQLS—O4=-02 O8e4sess 1SW 
labels <900005, 

Egress-—ok, time: -1091. 
2VI9-O4-02 O8stsgs7? TSW 

















Remote receive tim 


Request for seq 4, 
Reply for seq 4, return code: 


Local transmit time: 


to interface 334, 





AVLS—O4—02 O8e43g36 IS 
labels <900005, 

Egress-—ok, time: -1212. 
ZA0LS—O4=02 Ofe4seses LS 











Remote receive tim 


Request for seq 5, 
Reply for seq 5, return code: 


Local transmit time: 


EOutimuertacemssAr 





2OLI-O4-02 OPMg4sss7 usw 
labels <900005, 

Egress-—ok, time: -1199. 
2019-04-02 O8sasese wee 











Remote receive tim 
=== Igjoling SisiriLsties === 


5 packets transmitted, 


5 packets received, 





AOL -OA—0)2 O8gasasich ISA 


0% packet 


900041>, size 76 
444 ms 

618.804 ms 

394.360 ms 


900041>, 


packet 


packet size 76 


oles 


G7. 7S mis) 
SI5.532 ims 
900041>, 
469 ms 

Cay Poors 
526.428 ms 
900041>, 
647 ms 

SLI WIL 0s 
405.144 ms 
900041>, 
348 ms 

617.984 ms 
418.636 ms 


packet size 76 


packet size 76 


packet size 76 


loss 
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| show Idp database 


Syntax 


show lIdp database 

<brief | detail | extensive> 

<inet | |2circuit> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 
<p2mp> 

<session session> 


<summary> 


Release Information 
Command introduced before Junos OS Release 7.4. 
summary option introduced in Junos OS Release 14.2. 


Description 


Display entries in the LDP database. 


Options 
none—Display standard information about all entries in the LDP database for all routing instances. 


brief | detail | extensive—(Optional) Display the specified level of output. 
inet | I2circuit—(Optional) Display only IPv4 or Layer 2 circuit bindings. 
instance instance-name—(Optional) Display routing instance information for the specified instance only. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


p2mp—(Optional) Display point-to-multipoint binding information. 


session session—(Optional) Display database for the specified session only. session is the destination address 
of the LDP session. 


summary—(Optional)—Display summary output. This option displays the number of labels received and 
advertised for each LDP session. 


Required Privilege Level 


view 


List of Sample Output 
show Idp database (master) on page 2575 
show Idp database (standby) on page 2576 
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show Idp database I2circuit detail on page 2578 

show Idp database I2circuit extensive on page 2578 

show Idp database p2mp (master) on page 2579 

show Idp database p2mp (standby) on page 2579 

show Idp database session on page 2579 

show Idp database (Ingress Node with Multipoint LDP Inband Signaling for Point-to-Multipoint 
LSPs) on page 2580 

show Idp database (Egress Node with Multipoint LDP Inband Signaling for Point-to-Multipoint 
LSPs) on page 2581 

show Idp database summary on page 2582 


Output Fields 
Table 86 on page 2573 describes the output fields for the show Idp database command. Output fields are 
listed in the approximate order in which they appear. 


Table 86: show Idp database Output Fields 


Field Name Field Description Level of Output 
Input label Label received from the other router. All levels 
database 

Output label Label advertised to the other router. All levels 
database 

session-identifier | Session identifier, which includes the local and remote label space All levels 

identifiers. 
Labels received Number of labels received from the other router. All levels 
Labels advertised | Number of labels advertised to the other router. All levels. 


Label Label binding to a route prefix. All levels 


Table 86: show Idp database Output Fields (continued) 


Field Name 


Prefix 


MTU 


VCCV Control 
Channel types 


Field Description 


Route prefix. 
It can be one of the following values: 


e IP prefix. 


e Point-to-multipoint root address, multicast source address, and multicast 
group address when multipoint LDP (M-LDP) inband signaling is 
configured. 


e Layer 2 encapsulation type. 
Layer 2 encapsulation types are displayed in the format L2CKT control 


word status encapsulation-type vc-number, for example, L2CKT CtflWord 
FRAME RELAY VC 2 


e control-word-status—Displays whether the use of the control word has 
been negotiated for this virtual circuit: 


e NoCtrlWord 
e CtriWord 


e encapsulation-type—Encapsulation type: 
e FRAME RELAY 
e ATMAAL5 
e ATMCELL 
e VLAN 
e ETHERNET 
e CISCO_HDLC 
e PPP 


e VC number—Virtual circuit number. It can have any numeric value. 


e (Stale)—When you display the LDP database for the neighbor of a 
restarting router, the bindings leaned from the restarting neighbor are 
displayed as (Stale). Stale bindings are deleted if they are not refreshed 
within the recovery time. 


MTU of the Layer 2 circuit. MTU is displayed for all encapsulation types 
except ATM cell encapsulations. 


Virtual Circuit Connection Verification (VCCV) control channel types. 


e MPLS router alert label 
e MPLS PW label with TTL=1 


Level of Output 


All levels 


detail 


extensive 
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Table 86: show Idp database Output Fields (continued) 


Field Name Field Description Level of Output 
VCCV Control The only valid VCCV control verification type is LSP ping. extensive 
Verification 

types 

TDM payload Size of the Time Division Multiplex (TDM) payload. All levels 

size 

TDM bitrate Bit rate for the TDM traffic. All levels 
Requested VLAN = (VLANs) VLAN identifier of the Layer 2 circuit. detail 

ID 

Cell bundle size (ATM cell encapsulations) Maximum number of cells that the Layer 2 detail 


circuit can receive in a packet. 


State State of the label binding: detail 


e Active—Label binding has been installed and distributed appropriately. 
A label binding is almost always in this state. 


e New—New label that has not yet been distributed. 
e MapRcv—Waiting to receive a label mapping message. 
e MapSend—Waiting to send a label mapping message. 
e RelRcv—Waiting to receive a label release message. 


e RelRsnd—Waiting to receive a label release message before resending 
label mapping message. 


e RelSend—Waiting to send a label release message. 
e ReqSend—Waiting to send a label request message. 


e W/dSend—Waiting to send a label withdrawal message. 


Age Time elapsed since the binding was created. detail 


| Sample Output 


show Idp database (master) 


user@host> show ldp database extensive 


asic Ilelosil cleiceloase, 110.255.107.232 20—-10.255., 107 2351650 
Label Prefix 
299840 10.255. 107 .232/ 32 
State: Active 
Age: 9:35 





Entropy Label Capability: No 
3 LO 6255), 107 -236/ 32 

State: Active 

Age: 9:35 
Entropy Label Capability: No 
BQO TS L2CKT CtrlWord VLAN VC 100 





State: Active 
Age: 9:35 





Entropy Label Capability: No 
VCCV Control Channel types: 
PWE3 control word 
MPLS router alert label 
MPLS PW label with TTL=1 
VCCV Control Verification types: 
LSP ping 
BFD with PW-ACH-encapsulation for Fault Detection 





BFD with IP/UDP-encapsulation for Fault Detection 


Output label database, 10.255.107.232:0--10.255.107.236:0 
Label Prefix 
3 10,255 107 232/32 
State: Active 
Age: 9:35 





Entropy Label Capability: No 
ZIONS 10,255,107 236/352 

State: Active 

Age: 9:35 





Entropy Label Capability: No 


show Idp database (standby) 


user@host> show lIdp database extensive 


Input label database, 10.255.107.236:0—-10.255.107.234:0 
Label Prefix 
299808 10.255. 107 ,250/ 32 


TU: 1500 Requested VLAN ID: 600 Flow Label T Bit: 1 Flow Label R Bit: 
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Label 
SOLISE 


Label 


Label 
302480 


State: Active 

Age: 1d 2:46:36 

Standby binding state: 
Map messages: 1 


Release messages: 0 





Prefix 

LO 255,107 -232/ 32 
State: Active 
Age: 1d 2:46:36 
Standby binding state: 


Map messages: 1 





Release messages: 0 
Prefix 
10,255 107 234/32 
State: Active 
Age: 1d 2:46:36 
Standby binding state: 
Map messages: 1 


Release messages: 0 





Prefix 
10,255,107 .236/ 32 
State: Active 
Age: 1d 2:46:36 
Standby binding state: 
Map messages: 1 


Release messages: 0 


Output label database, 10.255.107.236:0--10.255.107.234:0 


Label 
299904 


BVNS) 3H6) 


SSS) A 


AYN) 2) 32 


Prefix 
10-255. 107 .<230/ 32 

State: Active 

Age: 1d 2:46:36 
10,255,107 232/32 
State: Active 

Age: 1d 2:46:36 
105255, 107 -234 /32 
State: Active 

Age: 1d 2:46:36 
10,255,107 .236/ 352 
State: Active 

Age: 1d 2:46:36 
PIMs coce-acele 10 .255.107.230, iIsj=-iel 16777217 
State: Active 

Age: 1d 2:46:36 
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show ldp database I2circuit detail 


user@host> show ldp database I2circuit detail 


Input label database, 10.255.245.44:0--10.255.245.45:0 

Label Prefix 

100176 L2CKT CtrlWord ATM CELL (VC Mode) VC 100 
Cell bundle size: 80 
State: Active 
Age: 9:48 

100256 L2CKT CtrlWord FRAME 
MTU: 4470 
State: Active 
Age: 9:48 








BELAY VC 101 





eS) 








Qutpue Habel database, M0V255.245. 44: 0-10), 255. 245). 45:0 

Label Prefix 

100048 L2CKT CtrlWord ATM CELL (VC Mode) VC 100 
Cell bundle size: 80 
State: Active 
Age: 9:48 

LOO ali L2CKT CtrlWord FRAME 
MTU: 4470 
State: Active 
Age: 9:48 








BELAY VC 101 





zs) 








show Idp database I2circuit extensive 


user@host> show ldp database 12circuit extensive 


Input label database, 10°255-245.198;0--102 255.245.1940 


Label Prefix 
PSSST 2 L2CKT CtrlWord PPP VC 100 
MTU: 4470 


VCCV Control Channel types: 
MPLS router alert label 
MPLS PW label with TTL=1 
VCCV Control Verification types: 





ISI joaLiavey 

Label Prefix 
State: Active 
Age: 19:23:08 
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show Idp database p2mp (master) 


user@host> show ldp database p2mp extensive 


iiggute lelosil ceicaloase, 110.255.107.232 80-10 .255,10 7 2356530 
Label Prefix 
569649 PAM ioot-acclie 10,455 107,254, Isjo-uel levy 2i17) 
State: Active 
Age: 2d 6:41:46 


Ou putea clcdatealbasicy ml Ome oo pm nO Mino) 7acs OR Ola oor mlAO e/a Onn0) 
inputelabeldavabasic ma lOm2 oS Ovi 2320 — OZ Soll Ome oiona0) 


Guibpuie lab clmicdatabas cy Ome mop ON/ i225: 0 Olea ore laO W/m ioas0) 
Label Prefix 
299888 PLP woect—accle 10.255 107.250, Isic e777 727 
State: Active 
Age: 2d 6:41:35 


show Idp database p2mp (standby) 


user@host> show ldp database p2mp extensive 


ligswe lelosil cleiceloase, 10.255 107 .23680—-10 255,107 23250 
Label Prefix 
299968 P2Me iwoct—eclche 10.255.107.230, lsjmicl 16777217) 
State: Active 
Age: 4d 22:21:57 
Standby binding state: 


Map messages: 1 





Release messages: 0 


OuEpui label databasic, OR So) OW 266 OO a Ses Oia si212 0 
Label Prefix 
3 PAMIP wooe—accle 10,255, 107.254, iIsjo=iel i 
State: Active 
Age: 4d) 22221: 57 


show Idp database session 


user@host> show lIdp database session 10.1.1.195 
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liggewte Ieloeil cetceloase, 10.0.0, 19420——10, 1.1 19530 















































Label Prefix 
100002 10.2539. 245 197/32 
100003 10,255,245), 196/32 
100004 NOL OO. 947/32 
S 1M lL ,1slO5/32 
100000 L2CKT NoCtrlWord FRAME RELAY VC 1 
100001 L2CKT CtrlWord FRAME RELAY VC 2 
Output label database, 10.0.0.194:0--10.1.1.195:0 
Label Prefix 
100003 10,255 24S) 6 LN / 32 
100004 OL, 1.95/32 
100002 10) - ABS 5 BAS) . 15/32 
3 10.0.0.194/32 
100000 L2CKT CtrlWord FRAME RELAY VC 2 
100001 L2CKT NoCtrlWord FRAME RELAY VC 1 




















show Idp database (Ingress Node with Multipoint LDP Inband Signaling for Point-to-Multipoint LSPs) 


user@host> show ldp database 


Mmjoure Melos ceicaloase, Lo ils,1. 280-1, ,l_Seo 


Label Prefix 
299808 Led. 2/ 32 
S Lele. S/S2 
ZOD YQ2 Lslol.6/32 
ZY TS 10) 255.52. 820 / 32 
299840 PAMIe sincere ol, .2, fee 2322.28.24, sees 1.25707 
299824 P2Mie imooe—ecclie Loil.,l,A, eee 282 ol ol.2, sees 192.168.219.141 


Ouiepuiee alo cumclateallyals Gilani 23210) ler ileenileeo a0) 


Label Prefix 
3 dei, lh. 2/32 
ZI 97 6 Lele 3/32 
299808 Lodo. 6/32 
ZO oe2. LO 5255525227 / 32 


liggute leloeil ceicaloase, i, il,1.,230——iL,l,1l.,~6s0 


Label Prefix 
299856 Lodo das 32 
Zoe 2. Lele S/32 
S doled. 6/32 
ZODT TS 10.255 .2.227 4 32 


299888 P2QMe iocr—eclclic 1,12, oie 232. 2.208, SES MaZo dol 


299808 
299824 
299840 
299872 


PQMe seocr—eclclc 1.1.12, ojos 232 .l.lei, ses 
RAMP sincere —eclche Ioil,1.,2, ieee 232 ,N1L.2, Sees 
P2Mie ioore—ecCie Loil,l.,2, epee 282.1 oils3, Secs 
PAMIP seovonre=—eclcle Ioi,i,2, Cees wesegeile2, Slee 





Oliicowie Mleloyeil cletceloeises, iL. i, 2x0——i1, 1.1. 630) 


Label 

S 
BQ T TW) 
299808 
ZOSY D2 


Prefix 
ele eas SZ 
tote l SS 
del, l 6/32 
10 .255..253227/ 32 
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192 LOS). BUY). LAL 
192, LOB. 209), 1a 
192,168,219, 14 
gloecle gile ees 7 


show Idp database (Egress Node with Multipoint LDP Inband Signaling for Point-to-Multipoint LSPs) 


user@host> show ldp database 


input label database, 0; 25on2. 227/20 ——ie. ie ts 0 


Label 
299808 

5 
ANDY D2 
2997 16 


Prefix 
Hh sll ay Shee 
dod ple S/S2 
dei. 6/32 
LO. 2552,227/ 32 


OuEBpui label database, LOR 2 S522 ZrO Sees) 


Label 
299856 
ZQDT TS 
Zoo I2 

S 


Prefix 
dei, ho 2/32 
Ig ple B/S 
doled. 6/32 
10. 255.2,227/ 32 


iigguie ieloxeil ceiceloase, I0.259,.2.22 /90——1 1.14630 


Label 
299856 
ZS OD. 

S 
ZOOS 


Prefix 
del, 2/32 
delle d/ 32 
Lote. 6/32 
105255 52.227/ 32 


@uispuielabciaidatabas cy uO m Zinio 22 2a) et0 terse ony 0) 


Label 
299856 
ZO9T7 6 
Zoo I2 

3 
299888 


Prefix 
dots lay ae 
doled. 3/32 
doled. 6/32 
10 5255 .2.227/ 32 


PQMe ieocr—eclclic I,1.,1,2, ois 2E2.2.208, SES 


hoo Tal 


299808 
299824 
299840 
299872 


P2MP 
P2MP 
P2MP 
P2MP 


root-addr 
root-addr 
root-addr 


root-addr 


show lIdp database summary 


user@host> show ldp database 


Session ID 


10.2455 60.18 0——-10,.255 0.480 
10 255605 Le O——-10.255.,0.580 


PR PR 


Loss Ap. Coe Boe ind 
Ilgil.2, @ijos 2a25ioi 
lslsap C98 2I2odolsd 
Lol, Cros ieSes 6 il 
summary 


Labels received 


See: 


Br wyieC 


PSGCE 
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192. LOS). 29) LA 
192, LOB. 219), 4, 
192,168,219, 14 
gloecls gile ees 7 


Labels advertised 


4 
4 
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| show Idp fec-filters 


Syntax 


show Idp fec-filters 
<fec> 
<instance instance-name> 


<logical-system (all | logical-system-name)> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Display information about configured Label Distribution Protocol (LDP) forwarding equivalence class (FEC) 
filters. 


Options 
fec—(Optional) Display FEC filter information for the specified FEC. 


instance instance-name—(Optional) Display FEC filter information for the specified instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 


view 


List of Sample Output 
show ldp fec-filters on page 2584 


Output Fields 


Table 87 on page 2583 lists the output fields for the show Idp fec-filters command. Output fields are listed 
in the approximate order in which they appear. 


Table 87: show Idp fec-filters Output Fields 


Field Name Field Description 
Ingress Names of the FEC filters on the ingress routers. 


Transit Names of the FEC filters on the transit routers. 
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| Sample Output 


show Idp fec-filters 


user@host> show ldp fec-filters 10/8 


10.2251 ,2)/ 32 
Imeieeses i100 ,22.1,2/32 (iincless 3) 


ibeenaysjabic, 2 ((iasellil)) ((altaveleys<p 10) 


2585 


| show Idp interface 


Syntax 


show Idp interface 

<brief | detail | extensive> 
<interface-name> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 


Display the status of Label Distribution Protocol (LDP)-enabled interfaces. 


Options 


none—Display standard status information about all LDP-enabled interface for all routing instances. 
interface-name—(Optional) Display information for the specified interface. 

brief | detail | extensive—(Optional) Display the specified level of output. 

instance instance-name—(Optional) Display information for the specified routing instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 


view 


List of Sample Output 
show Idp interface extensive on page 2586 


Output Fields 
Table 88 on page 2585 describes the output fields for the show Idp interface command. Output fields are 
listed in the approximate order in which they appear. 


Table 88: show Idp interface Output Fields 


Level of 
Field Name Field Description Output 


Interface Interface name. All levels 
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Table 88: show Idp interface Output Fields (continued) 


Level of 
Field Name Field Description Output 
Label space ID Label space identifier that the router is advertising on the All levels 
interface. 
Nbr count Number of neighbors on the interface. All levels 
Next hello How long until the next hello packet is sent on this interface, All levels 
in seconds. 
Hello interval One-third of the negotiated hold time (in seconds). If the detail 


user-configured value for the hello interval is smaller thanthe | extensive 
computed value, the user-configured value is used. 


Hold time Configured hold time, in seconds. detail 
extensive 
Transport address Address to which the neighbor wants the local route to extensive 


establish the LDP session. 


Local hello interval Locally configured hello interval. extensive 


| Sample Output 


show Idp interface extensive 


user@host> show ldp interface extensive 


Interface Label space ID Nbr count Next hello 
fe-0/0/3.0 10 52555245), os 2 0 
Hello interval: 1, Hold time: 15, Transport address: 10.255.245.6 
Local hello interval: 2, Index: 69 
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| show Idp neighbor 


Syntax 


show lIdp neighbor 

<brief | detail | extensive> 
<auto-targeted> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 
<neighbor-address> 


Release Information 

Command introduced before Junos OS Release 7.4. 

neighbor-address option added in Junos OS Release 8.5. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 
auto-targeted option added in Junos OS Release 14.2. 


Description 


Display Label Distribution Protocol (LDP) neighbor information. 


Options 


none—Display standard information about LDP neighbors for all routing instances. 
brief | detail | extensive—(Optional) Display the specified level of output. 


auto-targeted—(Optional) Display information about LDP neighbors that are automatically targeted using 
the loopback addresses. 


instance instance-name—(Optional) Display information for the specified routing instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on a 
particular logical system. 


neighbor-address—(Optional) Display information about the specified LDP neighbor. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


clear Idp neighbor | 2552 


List of Sample Output 
show Idp neighbor extensive on page 2588 


show Idp neighbor auto-targeted extensive on page 2589 


Output Fields 
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Table 89 on page 2588 describes the output fields for the show Idp neighbor command. Output fields are 
listed in the approximate order in which they appear. 


Table 89: show Idp neighbor Output Fields 


Field Name 


Address 


Interface 


Label space ID 


Hold time 


Transport address 


Configuration sequence 


Field Description 


IP address of the neighbor. 


Interface over which the neighbor was discovered. 


Label space identifier advertised by the neighbor. 


Remaining hold time before the neighbor expires, in seconds. 


Address to which the neighbor wants the local route to 
establish the LDP session. 


Counter that increments whenever the neighbor changes its 
configuration. 


Level of Output 


All levels 


All levels 


All levels 


All levels 


detail 


detail 


Up for Length of time the LDP neighbor has been in operation. detail extensive 
Reference count Reference count for the LDP neighbor. extensive 
Hold time Displays the neighbor's hold time. The hold time is the extensive 
proposed hold times for the local and peer routers. 
Proposed local/peer Hold time value proposed by the local router andthe peer — extensive 
router. 
| Sample Output 
show Idp neighbor extensive 
user@host> show ldp neighbor extensive 
Address Interface Label space ID Hold Time 
U2. LG. SI 423 so-1/0/0.0 10) 5 255) 5 245) 5390) 44 


Transport address: 10.255.245.5, Configuration sequence: 6 


ja ox OOZ0S3 37/ 
Reference count: 1 


Hold time: 45, Proposed local/peer: 15/45 


show Idp neighbor auto-targeted extensive 


user@host> show ldp neighbor auto-targeted extensive 


Address Interface Label space ID 
10,255,107 .236 MO ORO 10,255,107 ,23620 


Transport address: 10.255.107.236, Configuration sequence: 


US LOL OOS LOSSS 

Reference count: 2 

Hold time: 45, Proposed local/peer: 45/45 
Hello interval: 15 

Hello flags: targeted 





Neighbor types: Auto-targeted 


Hold time 


14 


41 
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| show Idp overview 


Syntax 


show Idp overview 
<instance instance-name> 
<logical-system (all | logical-system-name)> 


Syntax (EX Series Switch and QFX Series) 


show Idp overview 
<instance instance-name> 


Release Information 
Command introduced in Junos OS Release 11.2. 


Description 


Display LDP overview information. 


Options 


none— Display standard overview information about LDP for all routing instances. 
instance instance-name— (Optional) Display LDP overview information for the specified routing instance. 


logical-system (all | logical-system-name)— (Optional) Display LDP information from systems or a particular 
logical system on the devices. 


Required Privilege Level 
view 


List of Sample Output 
show Idp overview on page 2593 


Output Fields 


Table 90 on page 2590 lists the output fields for the show Idp overview command. Output fields are listed 
in the approximate order in which they appear. 


Table 90: show Idp overview Output Fields 


Field Name Field description Level of Output 
Instance LDP routing instance. All Levels 


Router ID Router ID of the routing device. All Levels 


Table 90: show Idp overview Output Fields (continued) 


Field Name 


Message ID 


Configuration 
sequence 


Deaggregate 


Explicit null 


IPvé tunneling 


Strict targeted hellos 


Loopback if added 


Route preference 


Unicast transit LSP 
chaining 


P2MP transit LSP 
chaining 


Transit LSP statistics 
based on route 
statistics 


Longest match 


Capabilities enabled 


Field description 


Unique identifier of message. 


Value of configuration sequence. 


Status of control forwarding equivalence class (FEC) deaggregation 


on the router. By default it is disabled on the router. 


Advertise label 0 to the egress routing device of an LSP. Explicit 
null: enabled or disabled. 


NOTE: If you do not include the explicit-null statement in the 
configuration, label 3 (implicit null) is advertised. 


Internet Protocol version 6 tunneling: enabled or disabled. 
Prevent LDP sessions from being established with remote neighbors 


that have not been specifically configured. Strict targeted hellos: 
enabled or disabled. 


NOTE: LDP peers will not respond to targeted hellos coming from 
a source that is not one of the configured remote neighbors. 


Loopback interface is added: yes or no. 
Default preference value (also known as an administrative distance) 
assigned to each route that the routing table receives. LDP 


preference is: 9 


Unicast transit LSP chaining: enabled or disabled. 


P2MP transit LSP chaining: enabled or disabled. 


Transit LSP statistics based on route statistics: enabled or disabled. 


Longest match for label mapping: enabled or disabled. 


Enabled capabilities: none 


Level of Output 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 


All Levels 
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Table 90: show Idp overview Output Fields (continued) 


Field Name 


Timers 


Graceful restart 


Traffic Engineering 


Field description Level of Output 


Keepalive interval: Keepalive interval value. All Levels 


Keepalive timeout: Time interval for which the neighbor LDP 
node waits before determining session failure. 


Link hello interval: Specify how often the router sends Link 
Management Protocol (LMP) hello packets. 


Link hello hold time: Time interval for which an LDP node waits 
for a hello message before declaring a neighbor is down. 


Targeted hello interval: Specify how often LDP sends targeted 
hello messages. 


Targeted hello hold time: Time interval for which a sending LSR 
maintains a record of targeted hello messages from the receiving 
LSR without receipt of another targeted hello message from that 
LSR. 


Label withdraw delay: Time interval for withdrawing labels to 
reduce router workload during IGP convergence. 


Graceful restart attributes. All Levels 


Restart- Graceful restart capability: enabled or disabled. 


Helper- Standard graceful restart helper capability: enabled or 
disabled. 


Restart in process- Graceful restart in process. 


Reconnect time- Period of time that a restarting LSR (label 
switched router) designates to LDP neighbors to wait until the 
former reestablishes the session after restarting. 

Max neighbor reconnect time- Maximum reconnect time. 
Recovery time- Period of time that an LSR preserves its state 


across the restart. 


Max neighbor recovery time- Maximum recovery time 
designated to LDP neighbors by a restarting LSR. 


Bgp igp- BGP and IGP destinations: enabled or disabled. When | All Levels 
enabled, IGPs use MPLS paths for forwarding traffic. 


Both ribs- BGP and IGP destinations with routes in both RIBs: 
enabled or disabled. 


Mpls forwarding- MPLS routes used for forwarding: enabled 
or disabled. 
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Table 90: show Idp overview Output Fields (continued) 


Field Name Field description Level of Output 


IGP e Tracking igp metric-Cause the IGP route metric to be used for | All Levels 
the LDP routes instead of the default LDP route metric (the 
default LDP route metric is 1). 


e Sync session up delay- Time interval to synchronize LDP session. 


Session protection e Session protection- Remote neighbor added to LDP All Levels 
configuration which enables protection for all sessions in the 
corresponding LDP instance: enabled or disabled. 


e Session protection timeout- Period of time until which the 
remote neighbor is connected to LSR in the absence of link 


neighbors. 
Interface addresses Advertises interface address. All Levels 
advertising 
Label allocation Label accounting information. All Levels 


e Current number of LDP labels allocated—Number of labels 
currently in use. 


e Total number of LDP labels allocated—Cumulative number of 
labels being allocated. 

e Total number of LDP labels freed—Cumulative number of labels 
being freed. 

e Total number of LDP label allocation failures—Cumulative 


number of failures for allocating a label. 


e Current number of labels allocated by all protocols—Number 
of labels currently being used by routing protocols. 


| Sample Output 


show Idp overview 


user@host> show ldp overview 


inisizane Ctaeinalsie ois 
Roweez Wg 192 1s .2 61 
Message id: 0 
Configuration sequence: 1 


Deaggregate: disabled 
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Explicit null: disabled 

IPv6 tunneling: disabled 

Strict targeted hellos: disabled 
Loopback if added: yes 

Route preference: 9 

Unicast transit LSP chaining: disabled 
P2MP transit LSP chaining: disabled 


Transit LSP statistics based on route statistics: disabled 





Longest Match: enabled 
Capabilities enabled: non 





Timers: 

Keepalive interval: 10, Keepalive timeout: 30 

Link hello interval: 5, Link hello hold time: 15 

Targeted hello interval: 15, Targeted hello hold time: 45 
Label withdraw delay: 60 

Craesiull wesiceiice ¢ 


Restart: enabled, Helper: enabled, Restart in process: false 





Reconnect time: 60000, Max neighbor reconnect time: 120000 





Recovery time: 160000, Max neighbor recovery time: 240000 





Traffic Engineering: 

Bgp igp: disabled 

Both ribs: disabled 

Mpls forwarding: disabled 
IGP: 

Tracking igp metric: disabled 

Sync session up delay: 10 
Session protection: 

Session protection: disabled 
Session protecton timeout: 0 
Interface addresses advertising: 

192168201 





Label allocation: 

Current number of LDP labels allocated: 3 
Total number of LDP labels allocated: 3 
Total number of LDP labels freed: 0 








Total number of LDP label allocation failure: 0 


Current number of labels allocated by all protocols: 3 
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| show Idp p2mp tunnel 


Syntax 


show Idp p2mp tunnel 

<brief | detail | extensive> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 


Release Information 
Command introduced in Junos OS Release 13.3. 


Description 


Display LDP point-to-multipoint tunnel table information. 


Options 


brief | detail | extensive—(Optional) Display the specified level of output. 
instance instance-name—(Optional) Display routing instance information for the specified instance only. 


logical-system (all | logical-system-name)—(Optional) Display LDP point-to-multipoint tunnel table information 
of all logical systems or a particular logical system. 


Required Privilege Level 
View 


| Sample Output 


show Idp p2mp tunnel 


user@host> show Idp p2mp tunnel extensive 


Instance Tunnel type Tunnel name 

0 Name 10), 254 1 4 ibe ils Ich 2inio auinyjorm ewer IL 
Bam iwoct—ecole 10.255, 107.232, spite 16777217 
Self id 805306372 


Reference count 2 
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| show Idp path 


Syntax 


show lIdp path 

<brief | detail | extensive> 

<destination> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Display Label Distribution Protocol (LDP) label-switched paths (LSPs). 


Options 


none—Display standard information about all LDP LSPs for all routing instances. 

brief | detail | extensive—(Optional) Display the specified level of output. 
destination—(Optional) Restrict the output to entries that match the specified destination prefix. 
instance instance-name—(Optional) Display information for the specified routing instance only. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 


view 


List of Sample Output 
show Idp path extensive on page 2597 


Output Fields 
Table 91 on page 2596 describes the output fields for the show Idp path command. Output fields are listed 
in the approximate order in which they appear. 


Table 91: show Idp path Output Fields 


Field Name Field Description 


Output Session Session ID and labels that this system has sent using LDP. These 
(label) correspond to MPLS packets received. 


Table 91: show Idp path Output Fields (continued) 


Field Name 


Input Session 
(label) 


route 


Attached route 


Ingress route 


Reference count 


Transit route 


Global label 


Field Description 


Session ID and labels that this system has received using LDP. These 
correspond to MPLS packets transmitted. 


MPLS route. 


Route corresponding to the LSP. 


The router acts as the ingress for the LSP. 


Reference count for the LDP neighbor. 


Names of the forwarding equivalence class (FEC) filters on the transit 
routers. 


MPLS label that is used globally. 


| Sample Output 


show Idp path extensive 


user@host> show lIdp path extensive 


Output Session (label) Input Session (label) 
10-255 . 14 .22030 (3) =) 
Attached route: 10.255.14.221/32 
Reference count: 3, Global label: 3 
10 259) 414). 220)3 ©) ( LOOOOO)) 10.255 .14, 220380 (3) 
Attached route: 10.255..14.220/32, Ingress route 


Reference count: 2, Transit route, Global label: 100000 
10-255 614), 2210310 (ALOOWO iL) 10-255 614), 221080 CLOOWO 1) 
Attached route: HOS255— VAP NA) 322 ingress route 





Reference count: 2, Transit route, Global label: 100001 
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| show Idp route 


Syntax 


show Idp route 

<brief | detail | extensive> 
<destination> 
<fec-and-route> 
<fec-only> 

<instance instance-name> 


<logical-system (all | logical-system-name)> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Display the entries in the Label Distribution Protocol (LDP) internal topology table. The internal topology 
table contains routes from inet.O and inet.3 and is used when binding a label to a forwarding equivalence 
class (FEC). 


Options 
none—Display standard information about all entries in the LDP internal topology table for all routing 
instances. 


brief | detail | extensive—(Optional) Display the specified level of output. 


destination—(Optional) Restrict the output to entries that are longer than the specified destination prefix 
and prefix length. 


fec-and-route—Display the show routes and the FECs. 
fec-only—Display only LDP FECs. 
instance instance-name—(Optional) Display entries for the specified routing instance only. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


List of Sample Output 

show Idp route detail on page 2599 

show Idp route extensive on page 2600 
show Idp route fec-and-route on page 2601 


2599 


show Idp route fec-and-route on page 2603 
show Idp route fec-only on page 2606 
show Idp route fec-only detail on page 2607 


Output Fields 


Table 92 on page 2599 describes the output fields for the show Idp route command. Output fields are listed 
in the approximate order in which they appear. 


Table 92: show Idp route Output Fields 


Field Name Field Description 

Destination Destination prefix. 

Next-hop intf/Isp/table Interface that is the next hop to the destination prefix. 

Next-hop address IP address of the next hop. 

Session ID LDP session ID. 

Route flags Information about the route. For example, the Ingress TTL propagate flag indicates 


that the time-to-live (TTL) value is being propagated with the route. 


Bound to outgoing label The route has been bound to LSPs with the label being distributed for that LSP. 
Topology entry The topology that the route is bound to. 

Ingress route status Status of the ingress route. For example, it could be Active or Inactive. 

Last modified The length of time since the ingress route status last changed. 

Last event(s) The last event that occurred. 


| Sample Output 


show Idp route detail 


user@host> show ldp route 10.255.8.5 detail 


Destination Next-hop intf/lsp Next-hop address 
LO 5255.48 55/32 tel 
Sessilom 1D 10,255,170 ,8430——10 255.170, 9280 
fe-0/0/0.0 192168. 100.2 


Sessalem Ib 10.255. 170.84 90-10). 255183. 580 
SOm 0) i2y a0 

SSsSatom I 10.255, 17/0 ,.8490—=10, 255 3.580 
SOm 0 i2y 210 

Session ID) 10.255. 170,.8430—-=10,255.8.380 


Bound to outgoing label 299776, Topology entry: 
BFD dest addr BFD state LSP-ping Next-hop addr 





127 -O oO. 64 up up 192,168. 100.2 
LAY «0. th, G4 up up 
OF 60) 62, Ge! up up 
W2y oO, So Ge! up up 


show Idp route extensive 


user@host> show ldp route extensive 


Destination Next-hop intf/lsp/table 
OOP OR Oy 230 ge-1/2/0.18 
SSsSakom 10) 12. WGs0 630-192. los .,0,5310 
Route flags: None 


Destination Next-hop intf/lsp/table 


10.0.0.4/30 


ge-1/2/0.18 


Session 1D 192,168,0.630-—192. 168.0. 5380 


Route flags: 


Destination 
ORO ORS 77310 


None 
Next-hop intf/lsp/table 
Gel / 2/1. 21. 


Sessilom 1D 192,168 .0 5630-192, 16s.0.430 


Route flags: 


Destination 
10.0 .0,12/ 30 


None 
Next-hop intf/lsp/table 
geHl/2/il. 21 


Sessitom WD) 192,168 ,0.630-—192. 168 ,.0.420 


Route flags: 


Destination 
LOR LOR ORE Gy23 0) 


Route flags: 


Destination 
10.0.0. 18 / S2 


Route flags: 


Destination 
OR OMOR 20/20 


Route flags: 


Destination 


None 
Next-hop intf/lsp/table 
Ge— l/ 2 70reks 

None 


Next-hop intf/lsp/table 


None 
Next-hop intf/lsp/table 
Gel / 2/21 

None 


Next-hop intf/lsp/table 


2600 


0x8c38a80 


Next-hop intf/lsp 
fe-0/0/0.0 

SOs 027 ele) 
sO-0/2/2 0 

ae AL 


Next-hop address 
LO 50.0.17 


Next-hop address 
1LO.0.0.17 


Next-hop address 
10.0.0 ,22 


Next-hop address 
10 .0.0.22 


Next-hop address 


Next-hop address 


Next-hop address 


Next-hop address 


2601 


LO 0,0 ,21/ 32 
Route flags: None 
Destination Next-hop intf/lsp/table Next-hop address 
IG? 1680.17 32 ge-1/2/0.18 LOO. O.17 
Sessatem ID) 192,168.0.630——192.168 0.5280 


Route flags: None 


Destination Next-hop intf/lsp/table Next-hop address 
192 ,168,0,2/32 GEHL /2/ il, Bi LO.0.0.22 
SSssSakom ID) 122. Wos0 630-192. os .0,4 30 
ge-1/2/0.18 LOsO 0.17 


Sessiom ID 192, 168.0.630-—-192 .168..0.530 
Route flags: None 
Destination Next-hop intf/lsp/table Next-hop address 
122 WS 0.3 3z SSL / 27 Bil 10.00.22 
Sessiom 1D 192, 168,0.630—-—192.,168.0.4380 
Route flags: None 
Destination Next-hop intf/lsp/table Next-hop address 
192. LSS, .O 4/32 ge-1/2/1.21 10.0.0,22 
Ssssitom 1D 192,168.0.630——192, 163,.0.480 
Bound to outgoing label 299808, Topology entry: 0x92a483c 
Ingress route status: Active, Last modified: 00:01:19 ago 
Route flags: Ingress TTL propagate, Transit TTL propagate 
Destination Next-hop intf/lsp/table Next-hop address 
LO? 168.0. 5/32 ge-1/2/0.18 10,0.0.,17 
Sessiiom ID 192.,168.0.630—-192 ,168..0.530 
Bound to outgoing label 299792, Topology entry: 0x92a47f8 
Ingress route status: Active, Last modified: 00:01:19 ago 
Route flags: Ingress TTL propagate, Transit TTL propagate 
Destination Next-hop intf/lsp/table Next-hop address 
192 LoS 0.6432 100.6 
Bound to outgoing label 3, Topology entry: 0x92a4a5c 


Ingress route status: Inactive 





Boute type: Eqress route 
Route flags: None 
Destination Next-hop intf/lsp/table Next-hop address 
10.10.20 1/32 fe-1/0/0.0 192,168,199 ,37) 
LS! WDP=S1L0 255.5107 .230 


show Idp route fec-and-route 


user@host> show lIdp route fec-and-route 


Destination Next-hop intf/lsp/table Next-hop address 
1054.0. 0/16 fxp0.0 10 592.31,254 


LO. 5505,0/ LG 


LO. 65,128 .0/ 17) 


ORE ORN Oy AKG 
LbOR, 
ALO), 
ALO) 5 
10. 
LO) 6 
ALO), 
OR 
ALO), 
ALO), 
AL(O) 5 
AL), 


10 


bOR, 
ALO); 
10. 
AL); 
OR 
EOE, 
10. 
AL) 5 
ALO); 
IL) 5 
ALO) 
LO), 
EOF, 
10. 
LOR, 
ALO); 
LO) 5 
ALO), 
LO) s 
IL), 
ALO), 
AL) ¢ 
bOR 
10. 
hOR 
10. 
ALO) 5 
ALO), 
10. 








OPO ONG 
13.4 ,.0/23 
13,10 .0/23 
82.00/15 
84.0.0/16 
85,12. 0/22 
9250 .0/ 16 

92 .15.0/20 
92.20.17 5/32 
94.0.0/16 
99.0 .0/ 16 
5102.0 .0/16 
SOR ORION AKG 
D5) .0 50/6 
157.64 0/19) 
160.0.0/16 
204.0.0/16 
ZU SriOrOy/ AG 
206.0.0/16 
207 sO 0/16 
209.0 50/16 
2125007 16 
ALS oO. 0/ 16 
214.0.0/16 
ZLB 50. 0/16 
ZIG 50 50/6 
PMs SO ae 
218.14.0/24 
Alig 160/20 
AILS 5 32.00/20 
Zia Or OV kG 
255), Wild 0/24 
255), 111 1/32 
255), ULI 2/32 
255) oil. 3/32 
ABS, Wild 4/32 
295) oll 4/32 
ADS), LID 1/32 
255,112, 1/32 
295), 112.2 32 
255), 112 2/32 


FxpO. 


xpd. 


FxpO. 


FxpO. 
FxpO. 
FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


Za CCS =| =| S| =f S&S Sf S&S 


FxpO. 
FxpO. 
FxpO. 
FxpO. 
FxpO. 
FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


FxpO. 


eas eS S| oe oS eS =| | S SS aS ss Ss S/S SS SS 


FxpO. 





FxpO0.0 


ge-0/0/2. 
ge-0/0/2. 
ge-0/0/2. 
ge-0/0/2. 
ge-0/0/2. 
ge-0/0/2. 


100.0 
HFCORLO 


ge-0/0/2. 
ge-0/0/2. 


eS aa = 2 & 


10 
1G 
10 
10 
10 
10 
10 
10 
10 
10 





10 
10 
10 
10 
10 
10 
10 
10 
10 
10 
10 
10 
10 
10 
10 
1G 
10 
10 
10 
10 
10 
1G 





tals alah a 
dha s dbl 6 


222 o 
5 92 o 
592 6 
5 2 o 
» 22 o 
oe 
5 22 6 
52 6 
522 o 
592 6 


22 o 
522 o 
592 6 
> 92 o 
3 2 a 
222 o 
5) a 
592 6 
5 2 o 
592 6 
ee 
eT 
522 o 
> 2 o 
592 6 
5 92 o 
5 a 
622 6 
5 Da 
5226 
522 o 
522 6 
IL. 
di. 
ii. 
il od 
dil. 
Aba eal 





FS Fe EE Es LSC) CE) OC) CO) COX) COX) TC) CO) C2) CO) COX) CO) CO) CC) C2) COX) COX) CO) CO) OCC) COC) 


PPP PP Pp 


1.254 
e254: 
1.254 
1.254 
P3204 
1.254 
[24904 
1.254 
1.254 
1.254 





(Go) (Gey (G9) Wa eer (eo) (er Ga) 


1.254 
1.254 
1.254 
1.254 
1.254 
1.254 
1.254 
1.254 
1.254 
Pi254 
1.254 
1.254 
aaa 
Pa 254 
1.254 
1.254 
1.254 
1.254 
1.254 
1.254 
[2.254 
1.254 











I [Ser TSO) IRS) IRS) 


Lis? 
i, 
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dal, 
dal 
128 
LS, 
ILS) 
AED 
IED, 
Zon 
24. 
Zoe 


128. 
128. 
IAS 6 
WAS 5 
128 
AIS 6 
LUZ 
WE 
LOZ, 
Ze 
ZiOWee 
AO « 


224 


Lil. 
di, 
Le 
LS, 
ILS) « 
Zoe 
Zee 
DS) 
24. 
2D) « 


o2% 
92 
o2e, 
DB 
DBs 
92% 


iL. 
alssit 
12 5 
155 
IBY 5 
Be 6 
22 
Zoe 
24. 
Zor 
al 


eal 


olf 32 


5 LY 32 


Z0r 
Bll 
BD) « 


BS) 
16.00/12 
168.0.0/16 
LOS, LOZ OV 2S 
IR USI6r) O24 
Ls W36, 12/32 
L7 5137 0/24 


0/24 


0/24 
0/24 
1/32 
0/24 


0/24 
0/24 
0/24 
sASy/ 32 
LID / 32 
186/32 
135/32 
o Sil / 32 
70/32 





60.0. 5/32 


ge-0/0/2.0 


ge-0/0/2.0 
ge-0/0/1.0 


ge-0/0/0.0 


ge-0/0/2. 
ge-0/0/2. 
ge-0/0/2. 
ge-0/0/2. 
100.0 
ge-0/0/2. 
ge-0/0/2. 
ge-0/0/2. 
ge-0/0/2. 
Fxp0.0 


ZZ a S&S S&S 


ese Se Se & 


FxpO. 
FxpO. 
FxpO. 
FxpO. 





ee oS & 


FxpO. 


show Idp route fec-and-route 


user@host> show ldp route fec-and-route 


Destination 


4.0.0/16 


AL), 
am) 
OR 
EOE 
EOF, 
AL) 5 
10. 
LO) 6 
ROR, 
ALO) 5 
AL) 5 
ALO), 
LOR, 
EOF, 
Ls 


0960 ,0/16 


6,128 .,0/17 
9,0.0/16 

LORI ORLOL/ A186 
13 4 .O/23 


Sh 
SZ. 
84. 
Sore 
oe 
SV 
O2e 


ILD) 5 
ORO 
0.0 
12 5 
0.0 
IS 5 
Zip 


0/23 
PALS 
/16 
0/22 
/16 
0/20 
IS) 32 


94.0.0/16 
99,0 0/16 


Next-hop intf/lsp/table 
fFxp0.0 

FxpO. 
FxpO. 
FxpO. 
FxpO. 
FxpO. 
FxpO. 
FxpO. 
FxpO. 
FxpO. 
FxpO. 


Es Sj oS aS | oS S| Sf Oo Ss 


FxpO. 


FxpO0.0 





FxpO0.0 


aval s 


duals 
vas 
dials 
tii 


it. i 
abs dt 
dale db 
dab, a 
3 a 
5220 
ee 
592 6 
> 2 o 
592 6 


10 
10 
10 
10 
10 
10 





Next-hop address 
e2o4 
1.254 
L254 
1.254 
L.254 
L.254 
ezio4 
L254 
L.254 
L254 
L.254 


LO. 
LO. 
10) - 
LO. 
LO 
LO. 
LO 
10) 
LO. 
LO). 
OR 


10. 
LO) « 


dike 


dis 
Wil, 
dike 





QZ 
QZ 
DMZ 
QZ o 
Qo 
QZ 
Qe 
OZ 
QZ 6 
V2 
QE 


MZ o 
DMZ o 


PP RPP 


iil. 


ii. 
ii. 
iil. 





(or (Ge) (Gs) GS) GS 





CS) (Ca Cn CO) 


Sid ¢ 
Sik g 


[oy SSP ASS) 18S) 


ISP [Soy IRs} 


1.254 
eae 
1.254 
1.254 
Pa 24 
1.254 


254 
254 
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ALO) 5 
ALO), 
ILO). 
LOR, 
ALO), 
10. 
10. 
LO), 
LbOR, 


10 


ALO) 5 
ALO), 
AL(O) 5 
ROR, 


10 


ALO), 
ALO); 
AL), 
ALO), 
LO). 
EOE, 


10 


Des 
10 


Des 
10 


Des 
10 














102 ,0 0/16 Exp0.0 LO. 92 631 
150.0.0/16 Exp0.0 10,92 031 
15550.0/ 16 Exp0.0 1.925311 
157 .64.0/19) Exp0.0 10, 92 631 
160.0.0/16 Exp0.0 LO. 92651 
204.0.0/16 Exp0.0 LO 292 631 
20S 50 50/16 Exp0.0 LO 592 651 
206.0.0/16 Exp0.0 1592631 
A070. 0/16 Exp0.0 10,920.31 
5409, 0.0/16 Exp0.0 10> 92631 
2IL250 0/16 Exp0.0 LO. 92 oS) 
ZILS 5050/16 Exp0.0 LO 92651 
214.0.0/16 Exp0.0 LO 292 631 
ZLB 5050/16 Exp0.0 10.92.31 
AIG. 0.0/6 Exp0.0 Ls 92631 
AILS 5130/24 Exp0.0 10,92 631 
218.14.0/24 Exp0.0 LO > 92651 
Ae}, 150/20) Exp0.0 LO. 2 oS 
ASE 207 20 Exp0.0 LO. 92651 
21 O.O/ 16 Exp0.0 105925311 
255) oil 0/24 ges 0/7 0/250 Hal dal oe 
Session WD 10,255,112, 130-10 ,255,112.230 
s2555 111 1/32 Ges U7 O/2a0 IL. tisil. 


Sessitom 1D 10,255,112, 1le0—--10.,.255,.112.280 

Bound to outgoing label 300192, Topology entry: Oxb5delb0 
Ingress route status: Active, Last modified: 09:57:49 ago 
Last event(s): Rebind 

Route flags: Transit TTL propagate, Allow longest match 
tination Next-hop intf/lsp/table Next—hop 


52554111 27 32 Gee UZ O/2a0 ay aL ell 


Sesgatom Ib) 10,255,112, Lg0——10,,.255,112.280 

Bound to outgoing label 300208, Topology entry: Oxb5delf8 
Ingress route status: Active, Last modified: 09:57:49 ago 
Last event(s): Rebind 

Route flags: Transit TTL propagate, Allow longest match 
tination Next-hop intf/lsp/table Next—hop 


52554111. 3/32 giSe—0/ 0/2. Sa be opel le 


Sessiom WD 10,255,112, 1s0--10 255, 112.290 

Bound to outgoing label 300224, Topology entry: Oxb5de240 
Ingress route status: Active, Last modified: 09:57:49 ago 
Last event(s): Rebind 

Route flags: Transit TTL propagate, Allow longest match 
tination Next-hop intf/lsp/table Next—hop 


62555111 .4/32 ge=0/ 0/2730 dibs dal 6 ili. 


1.254 
1.254 
1.254 
1.254 
1.254 
1.254 
1.254 
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Rezo 
254 
1.254 
1.254 
1.254 
L.254 
P2494 
1.254 
1.254 
1.254 
1.254 
1.254 
1.254 





address 
2 


address 
2 


address 
2 


Sessicm 1D) 10,255,112 .1s0-—10, 255.112.2380 
Bound to outgoing label 300112, 
Active, 

Updat 


NCES SicmerOUE Cuesta cieulon 








Last event(s): Evaluat 

ingress Ill propagate, 

Destination Next-hop intf/lsp/table 
LO 6255). WI A S52 ge-0/0/2.0 


Session ID 10,255,112, 130-10 ,.255, 112.230 


Route flags: 


Bound to outgoing label 300112, 
Active, 
Updat 
ingress TTL propagate, 
Next-hop intf/lsp/table 
100.0 


NCES SicmesOUle Cuesta cietl on 








Last event(s): Evaluat 
Route flags: 
Destination 
LO 255,112 1/32 
Bound to outgoing label 3, 


Ingress route status: Inactive 





Last event(s): Evaluate Update history 





ROUte Eype: Egress rouce 


Route flags: Allow longest match 
Next-hop intf/lsp/table 


100.0 


Destination 
LO 255,112 , 1/32 
Bound to outgoing label 3, 
Ingress route status: Inactive 


Last event(s): Evaluate Update history 





Route Lype: Egress rouce 

Allow longest match 
Destination Next-hop intf/lsp/table 
LO 255,112 2/32 ge-0/0/2.0 


Sessilom 1D 10,255,112, 1¢0—--10.,.255 112,230 


Route flags: 


Bound to outgoing label 300064, 
Ingress route status: Active, 
Last event(s): Update ingress route 
ingress ITLL propagete, 

Next-hop intf/lsp/table 


ge-0/0/2.0 


Route flags: 
Destination 
LO, 255.112, 2/32 


Sessiem WD 10 .255.1i12 e010 .,.255, 112 2°80 
Topology entry: 


Bound to outgoing label 300064, 
Ingress route status: Active, 
Last event(s): Update ingress route 
Route flags: Ingress TTL propagate, 

Next-hop intf/lsp/table 


ge-0/0/2.0 


Destination 
i ,til.lil,0/24 
is Li. bis ly s2 


12, 12.12,0/24 ge-0/0/2.0 


Topology entry: 
Last modified: 


Transit TTL propagate, 


Topology entry: 
Last modified: 


Transit TTL propagate, 


Topology entry: 


Topology entry: 


Topology entry: 


Last modified: 


Transit TTL propagate, 


Last modified: 


Transit TTL propagate, 
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Oxb5de708 
LOS LO S6 ago 


ingress route Update transit route 


Allow longest match 
Next-hop address 
i,t, dil. 2 


Oxb5de708 
LOS LORS 6 “ago 


ingress route Update transit route 


Allow longest match 
Next-hop address 


Oxb5de120 


Next-hop address 


Oxb5de120 


Next-hop address 
iba eakal sabi. 


Oxb5de630 
10:11:04 ago 


Allow longest match 
Next-hop address 


Hah Al Ah AlIl 


Oxb5de630 
LOE 04 ago 


Allow longest match 
Next-hop address 


digit... 2 


Sessalem Ip) 10,255. 112. 1gO0——1@,. 
15,15, 150/24 ge-0/0/1.0 
15.15 ,15,1/32 
DD DB OD Of DA ge-0/0/0.0 
DE GAD BE 3 Mf BP 
23 23-23 .0/ 24 ge-0/0/2.0 

Sesgatom ID) 10,255,112, Le0——-10, 
24.24.24.0/24 ge-0/0/2.0 

SSsSakorm 10) 10), 255, 12, 1eO@—-—-10), 
25,25 25.50/24 ge-0/0/2.0 

Sessalem ID) 10,255,112. 1eO0——1@., 
128, 92 17 AS 32 ge-0/0/2.0 

Sessilom ID 10,255,112 .1e0——10 
123, 92 5 20 LIS 32 100.0 
128,92 521 . 186/32 ge-0/0/2.0 

SSsSakom 10) 10). 255, Lil, le@-—-10, 
128,92 25-195 / 32 ge-0/0/2.0 

Sessaleim ID) 10,255,112 .1eO0——1@,, 
128. 92 27 . Gill 32 ge-0/0/2.0 

SSsSitom 10) 10,255, 117, 1eO0——10, 
WS 92 5 B83. WO 32 ge-0/0/2.0 

SSssatom 10) 10,255, 117, leO0——10, 
LIZ. LG .0.0/12 Fxp0.0 
LO? 168.0. 0/16 fxp0.0 
192. LSS 102 0/23 fxp0.0 
BON LF 5136, 0/24 fxp0.0 
2OT LI .ISG.192/S2 igo. 0 
207 517 137 0/24 fxp0.0 
2A 0.0 5 Sf 32 














show lIdp route fec-only 


user@host> show ldp route fec-only 


ZO ke 


BOND) ¢ 


BBS) 6 


Zo Ke 


Zor. 


BSS) 6 


Zor. 


2BS) 6 


ABS) 6 


MLZ 


LZ) 


WZ 


MLZ 


LZ 


WZ 


MLZ 


(eee 


WA 


user@host_re0> show ldp route fec-only 


Lf 32 
BY 32 


sot 32 


4/32 


pil fs 


Destination 
10.2555 111. 
LO. 255.5111, 
10.255, 101 
LO ,255., 111. 
LO 255 112 
LO 255.112 





cA 3B 


Next-hop intf/lsp/table 


ge-0/0/2.0 
ge-0/0/2.0 
ge-0/0/2.0 
ge-0/0/2.0 
100.0 

ge-0/0/2.0 





Ail. aL 


dibs de 


els 


ALL 5 al 


duals 


LAL. 


ial 


alae 


10 
10 
10 
10 
10 
10 








dis 


lag 


LiL 6 


Wil 


ee 
er 
222 o 
> 2 o 
592 6 
5 92 o 








(Coy (Gay feey ey (a) 


Next—hop 


dials 
dal « 
aval 
Lil. 


i. 


dike 
il, 


dl 


dik 


ii. 
iil. 


eelelae 
ALAR 


ILA s 


1.254 
1.254 
1.254 
1.254 
1.254 
1.254 





address 


oy (SS) 18S) 
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show Idp route fec-only detail 


user@host> show ldp route fec-only detail 


Destination Next-hop intf/lsp/table Next-hop address 
10.255. 011, 1/32 ge-0/0/2.0 IAL pdb al 5 Aa 2 
Sessicm 1D) 10,255,114, 1s0—--10,255 112.280 
Bound to outgoing label 300192, Topology entry: Oxb5delb0 
Ingress route status: Active, Last modified: 09:55:10 ago 
Last event(s): Rebind 
Route flags: Transit TTL propagate, Allow longest match 
Destination Next-hop intf/lsp/table Next-hop address 
LO 255, Ul1 2/32 ge-0/0/2.0 ANAL pdb Al 5 deal, 2 
SOSSiLem 1D) 10,255,114. leO0—--10, 255. 112.230 
Bound to outgoing label 300208, Topology entry: Oxb5delf8 
Ingress route status: Active, Last modified: 09:55:10 ago 
Last event(s): Rebind 
Route flags: Transit TTL propagate, Allow longest match 
Destination Next-hop intf/lsp/table Next-hop address 
10,2555 111 ,.3/32 ge-0/0/2.0 its hdl edd 
SSSS5iCm 1D) 10,255,114. 190—--10 255. 112.230 
Bound to outgoing label 300224, Topology entry: Oxb5de240 
Ingress route status: Active, Last modified: 09:55:10 ago 
Last event(s): Rebind 
Route flags: Transit TTL propagate, Allow longest match 
Destination Next-hop intf/lsp/table Next-hop address 
10.2555 111 4/32 ge-0/0/2.0 dito dioilil,2 
SSS5iLem 1D) 10,255,114. leO0—-10,255 112.230 
Bound to outgoing label 300112, Topology entry: Oxb5de708 


Ingress route status: Active, Last modified: 10:08:17 ago 





Last event(s): Evaluate Update ingress route Update transit route 





Route flags: Ingress TTL propagate, Transit TTL propagate, Allow longest match 
Destination Next-hop intf/lsp/table Next-hop address 
10,255,112 51/32 100.0 
Bound to outgoing label 3, Topology entry: Oxb5de120 


Ingress route status: Inactive 





Last event(s): Evaluate Update history 





Boute type: Eoress route 
Route flags: Allow longest match 
Destination Next-hop intf/lsp/table Next-hop address 
LO s255, 112 2 32 ge-0/0/2.0 Li. iti, dit. 2 
Sessicom UD 10,255.112,1s0--10 255,112 .230 
Bound to outgoing label 300064, Topology entry: Oxb5de630 


Ingress route status: Active, Last modified: 10:08:25 ago 
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Last event(s): Update ingress route 


Route flags: Ingress TTL propagate, Transit TTL propagate, Allow longest match 
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| show Idp session 


Syntax 


show Idp session 

<brief | detail | extensive> 
<auto-targeted> 

<destination> 

<instance instance-name> 

<logical-system (all | logical-system-name)> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 
auto-targeted option added in Junos OS Release 14.2. 


Description 


Display information about Label Distribution Protocol (LDP) sessions. 


Options 


none—Display standard information about all LDP sessions for all routing instances. 
brief | detail | extensive—(Optional) Display the specified level of output. 


auto-targeted—(Optional) Display information about LDP sessions that are automatically targeted using 
loopback addresses. 


destination—(Optional) Restrict LDP session display to the specified address. 


instance instance-name—(Optional) Display routing instance information for the specified instance. If 
instance-name is omitted, information is displayed for the master instance. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 


view 


RELATED DOCUMENTATION 


clear Idp session | 2553 


List of Sample Output 
show Idp session brief on page 2613 


show ldp session detail on page 2614 
show Idp session extensive on page 2614 
show Idp session auto-targeted detail on page 2615 


Output Fields 


Table 93 on page 2610 describes the output fields for the show Idp session command. Output fields are 
listed in the approximate order in which they appear. 


Table 93: show Idp session Output Fields 


Field Name 


Address 


State 


Connection 


Hold time 


Session ID 


Next keepalive 


Active 


Passive 


Maximum PDU 


Hold time 


Neighbor count 


Neighbor types 


Keepalive 
interval 


Field Description 

Transport address of the session. 

State of the session: Nonexistent, Connecting, Initialized, OpenRec, 
OpenSent, Operational, or Closing. The states correspond to the state 
diagram specified in Internet Draft LDP Specification 
draft-ietf-mpls-rfc3036bis-01.txt. 

TCP connection state: Closed, Opening, or Open. 

Time remaining until the session will be closed, in seconds. 

LDP identifiers of the peers of this session. 


Time until next keepalive is sent, in seconds. 


Whether the local router is playing the active role in the session and during 
session establishment. 


Whether the local router is playing the passive role in the session and 
during session establishment. 


Maximum protocol data unit (PDU) size (packet size) for the session. 
Time remaining until the session will be closed, in seconds. This value 
corresponds to the one configured using the keepalive-timeout statement 
configured at the [edit protocols Idp] hierarchy level. 

Number of neighbors that are contributing to the session. 


Category of LDP session: discovered or auto-targeted. 


Keepalive interval, in seconds. 


Level of Output 


any 


any 


any 


any 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


any 


detail extensive 


Table 93: show Idp session Output Fields (continued) 


Field Name 


Connect retry 
interval 


Local address 


Remote address 


Up for 


Last down 


Reason 


Number of 
session flaps 


Restarting 


Capabilities 
advertised 


Capabilities 
received 


Field Description 


TCP connection retry interval, in seconds. 


Local transport address. 


Remote transport address. 


Time that this session has been up. 


Time since the session last went down. 


Reason the session went down: 


e Aborted graceful restart 

e Authentication key was changed 

e Bad type length value (TLV) 

e Bad protocol data unit (PDU) packets 
e Command-line interface (CLI) command 
e Connect time expired 

e Connection error 

e Connection reset 

e Error during initialization 

e Hold time expired 

e No adjacency or all adjacencies down 
e Notification received 

e Received notification from peer 

e Unexpected End of File (EOF) 


e Unknown reason 


Number of times the session changes from up to down. 


LDP is in the process of gracefully restarting. 


LDP capabilities advertised to a peer. 


LDP capabilities received from a peer. 


Level of Output 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 
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Table 93: show Idp session Output Fields (continued) 


Field Name 


Protection 


restart complete 
in nnn msec 


Authentication 
type 


Local 


Remote 


Local maximum 
recovery time 


Next-hop 
addresses 
received 


Field Description 


Information about the status of MPLS LDP session protection. 


Amount of time (in milliseconds) remaining until graceful restart is declared 
complete. 


Shows the longest match MD5 authentication 


Information about graceful restart for the local end of an LDP session. 
Graceful restart and helper mode are independent. 


e Restart—Status of the grateful restart feature at the local end of the 
LDP session: enabled or disabled. 


e Helper mode—Status of the helper mode feature at the local end of 
the LDP session: enabled or disabled. When this feature is enabled, the 
local end of the LDP session can help the restarting router with its LDP 
restart procedures. 


e Reconnect time—Amount of time to wait from when a restart is initiated 
until the router can exchange LDP messages with its neighbors. The 
default is 60000 msec and is not configurable. (Reconnect timeout 
refers to "FT Reconnect timeout" in draft-ietf-mpls-ldp-restart-06, 
Internet Draft Graceful Restart Mechanism for LDP.) 


Information about graceful restart at the remote end of an LDP session. 
Graceful restart and helper mode are independent. 


e Restart—Status of the grateful restart feature at the remote end of the 
LDP session: enabled or disabled. 


e Helper mode—Status of the helper mode feature at the remote end of 
the LDP session: enabled or disabled. When this feature is enabled, the 
remote end of the LDP session can help the restarting router with its 
LDP restart procedures. 


e Reconnect time—Amount of time in milliseconds from when a restart 
is initiated until the remote router can exchange LDP messages with 
its neighbors. 


Amount of time during which the restarting node attempts to recover its 
lost states with help from its neighbors (in milliseconds). 


Next-hop addresses received on the session. 
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Level of Output 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


detail extensive 


Table 93: show Idp session Output Fields (continued) 


Field Name Field Description 
Queue depth Number of messages that are queued for sending to the peers in the 
group. 


Message type Type of message being sent: 


e e Initialization—Session initialization negotiation messages sent by an 
LSR to an LDP peer when the transport connection is established. 


e Keeaplive—Keepalive timer messages sent by an LSR to an LDP peer 
to keep the session active when there is no information or PDU 
exchanged between them. 


e Notification—Notification messages (such as state of the LDP session) 
or error information (such as bad PDU length) sent by an LSR to an 
LDP peer. 


e Address—Message sent by an LSR to an LDP peer to advertise 
interface addresses. 


e Address withdraw—Message sent by an LSR to an LDP peer to 


withdraw a previously advertised interface address. 


e Label mapping—Message sent by an LSR to an LDP peer to advertise 
label mapping for a forwarding equivalence class (FEC). 


e Label request—Message sent by an LSR to an LDP peer to request a 
label mapping for an FEC. 


e Label withdraw— Message sent by an LSR to an LDP peer to withdraw 
a previously advertised FEC-label mapping. 


e Label release—Message sent by an LSR to an LDP peer to notify the 


peer that a specific FEC-label mapping has been released. 


e Label abort—Message sent by an LSR to an LDP peer to abort a label 
request message. 


e Total—Messages sent and received during the lifetime of the session. 


e Last 5 seconds—Messages sent and received during the current session. 


| Sample Output 


show Idp session brief 


user@host> show ldp session brief 


Level of Output 
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Address State Connection Hold time 
10 -25'5)6 FA 5 oo) Operational Open 21 
UO 2D 6 125 16d Operational Open 20 
10.2555 7125172 Operational Open Bl 


show Idp session detail 


user@host> show ldp session detail 


Address: 192.168.0.3, State: Operational, Connection: Open, Hold time: 27 
Sessiem IDs 192, 168.0,.230——-192 . 1680.38 0 

Next keepalive in 7 seconds 

Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1 

Neighbor types: discovered 

Keepalive interval: 10, Connect retry interval: 1 

Local address: 192.168.0.2, Remote address: 192.168.0.3 

Uppy fon 002 00k 02 





Capabilities advertised: non 





Capabilities received: non 





Protection: disabled 


Local - Restart: enabled, Helper mode: enabled, Reconnect time: 60000 





Remote — Restart: enabled, Helper mode: enabled, Reconnect time: 60000 





Local maximum neighbor reconnect time: 120000 msec 


Local maximum neighbor recovery time: 240000 msec 





Local Label Advertisement mode: Downstream unsolicited 





Remote Label Advertisement mode: Downstream unsolicited 





Negotiated Label Advertisement mode: Downstream unsolicited 


Nonstop routing state: Not in sync 





Next-hop addresses received: 
ORTOP ORS 
MOPOR Ores S: 


show Idp session extensive 


user@host> show ldp session extensive 


Address: 192.168.0.3, State: Operational, Connection: Open, Hold time: 22 
SSssioi Wg (92 163.0 230-192, 16,0, 330) 
Next keepalive in 2 seconds 
Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1 
Neighbor types: discovered 
Keepalive interval: 10, Connect retry interval: 1 


Local address: 192.168.0.2, Remote address: 192.168.0.3 
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Us cor OOSWS3 37 


Capabilities advertised: non 








Capabilities received: non 


Protection: disabled 





Local - Restart: enabled, Helper mod 


nabled, Reconnect tim 60000 





Remote — Restart: enabled, Helper mod 


Local maximum neighbor recovery time: 





Local Label Advertisement mod 





Remote Label Advertisement mod 





Negotiated Label Advertisement mod 


Nonstop routing state: Not in sync 





Next-hop addresses received: 
OREO FaOprS 
OP OR Ores 
Queue depth: 0 

Message type Total 

Sent Receiv 

Initialization al 

Keepalive 33 

Notification 0 

Address 

Address withdraw 

Label mapping 

Label request 

Label withdraw 


Label release 


Se Fe) aS a S&S iS 





Label abort 


show Idp session auto-targeted detail 


Local maximum neighbor reconnect time: 


2 


nabled, Reconnect time: 60000 
120000 msec 
40000 msec 


Downstream unsolicited 


Downstream unsolicited 


Downstream unsolicited 


ed 
i 
ee 


aS @ = © Gi © 


Last 5 seconds 


Sent Received 


oS Cc S&S S&S Ec @G& ft © 
a fo 2 2 ec oS eo oo S&S 


user@host> show ldp session auto-generated detail 


Address: 192.168.1.5, State: Operational, 
Sessalom WDs 192, 168, i, 1s0——192, 168. 1.530 


Next keepalive in 5 seconds 





Oo mso ca OOM OOies 4 





Capabilities advertised: non 





Capabilities received: non 


Connection: Open, Hold time: 25 


Passive, Maximum PDU: 4096, Hold time: 30, Neighbor count: 1 
Neighbor types: discovered, Auto-targeted 
Keepalive interval: 10, Connect retry interval: 1 


Local address: 192.168.1.1, Remote address: 192.168.1.5 
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Protection: disabled 


Local —- Restart: disabled, Helper mod 


nabled 





Remote — Restart: disabled, Helper mod 


nabled 





Local maximum neighbor reconnect time: 
Local maximum neighbor recovery time: 


Local Label Advertisement mode: Downst 











Negotiated Label Advertisement mode: D 


Nonstop routing state: Not in sync 





Next-hop addresses received: 
192 168.142 
192,168,163 


120000 msec 
240000 msec 


ream unsolicited 


Remote Label Advertisement mode: Downstream unsolicited 


ownstream unsolicited 
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| show Idp statistics 


Syntax 


show Idp statistics 
<instance instance-name> 
<logical-system (all | logical-system-name)> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 
Display Label Distribution Protocol (LDP) statistics. 


Options 


none—Display LDP statistics for all routing instances. 
instance instance-name—(Optional) Display information for the specified routing instance only. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


clear Idp statistics | 2555 


List of Sample Output 
show ldp statistics on page 2621 


Output Fields 


Table 94 on page 2617 lists the output fields for the show Idp statistics command. Output fields are listed 
in the approximate order in which they appear. 


Table 94: show Idp statistics Output Fields 


Field Name Field Description 


Total Sent, Total number of each message type sent and received. 
Received 
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Table 94: show Idp statistics Output Fields (continued) 


Field Name 


Last 5 
seconds 
Sent, 
Received 


Message 
type 


Field Description 


Number of each message type sent and received in the last 5 seconds. 


LDP message types: 


e Hello—Messages that enable LDP nodes to discover one another and to detect the failure of a 
neighbor or of the link to the neighbor. 


e Initialization—Messages that indicate an LDP session has started. 

e Keepalive—Messages that ensure that the keepalive timeout is not exceeded. 
e Notification—Advisory information and signal error information. 

e Address—Messages with address information. 

e Address withdrawal—Messages regarding address withdrawal. 

e Label mapping—Messages with label mapping information. 

e Label request—Request for a label mapping from a neighboring router. 


e Label withdrawal—Withdrawal message sent by the downstream LSR to recall a label that it previously 
mapped. If an LSR that has received a label mapping subsequently determines that it no longer needs 
that label, it can send a label release message that frees the label for use. 


e Label release—Message sent by the downstream LSR to recall a label that it previously mapped. If 
an LSR that has received a label mapping subsequently determines that it no longer needs that label, 


it can send a label release message that frees the label for use. 
e Label abort—Messages about label interruptions. 
e All UDP—AIl hello messages sent by LSRs to the well-known UDP port, 646. 
e All TCP—All LDP session messages. 
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Table 94: show Idp statistics Output Fields (continued) 


Field Name | Field Description 


Event type 
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Table 94: show Idp statistics Output Fields (continued) 


Field Name 


Field Description 


LDP events and errors: 


e Sessions opened—Number of LDP sessions that have been opened. 

e Sessions closed—Number of LDP sessions that have been closed. 

e Topology changes—Number of changes to the known LDP topology. 

e Nointerface—Number of missing interface address messages. When a new LDP session is initialized 
and before sending label lapping or label request messages, the LSR advertises its interface addresses 
with one or more address messages. 

e Nosession—Number of missing session messages. Session messages are used to establish, maintain, 
and terminate sessions between LDP peers. 

e No adjacency—The exchange of hello adjacency messages results in the creation of an adjacency. 
The LDP identifier, together with the sender's LDP identifier in the PDU header, enables the receiver 
to match the initialization message with one of its hello adjacencies. If there is no matching hello 
adjacency, the LSR sends a session the initialization message is rejected. 

e Unknown version—The LDP protocol version is not supported by the receiver, or it is supported 
but is not the version negotiated for the session during session establishment. 

e Malformed PDU—An LDP PDU received on a TCP connection for an LDP session is malformed if 
the LDP identifier in the PDU header is unknown to the receiver, or if it is known but is not the LDP 
identifier associated by the receiver with the LDP peer for this LDP session. 

An LDP PDU is considered to be malformed if the LDP protocol version is not supported by the 
receiver, or it is supported but is not the version negotiated for the session during session 
establishment. 

An LDP PDU is considered malformed if the PDU length field is too small (less than 14) or too large 
(greater than maximum PDU length). 

e Malformed message—Malformed LDP messages that are part of the LDP discovery mechanism are 
handled by silently discarding them. 

An LDP message is malformed if the message type is unknown. If the message type is less than 
Ox8000 (high order bit = 0), it is an error signaled by the unknown message type status code. 

An LDP message is considered to be malformed If the message length is too large, meaning that the 
message extends beyond the end of the containing LDP PDU. 

The LDP message is considered to be malformed if the message length is too small, meaning that it 
is smaller than the smallest possible value component. 

The LDP message is considered to be malformed if the message is missing one or more mandatory 
parameters. 

e Unknown message type—If the message type is less than Ox8000 (high order bit = O) or greater 
than or equal to Ox8000 (high order bit = 1) it is considered to be an unknown message. 


e Inappropriate message—The message is not of the type that the receiver expects to receive. 


e Malformed TLV—The TLV ILength is too large or the receiver cannot decode the TLV value. This 
can indicate an issue in either the sending or receiving LSR. 
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Table 94: show Idp statistics Output Fields (continued) 


Field Name Field Description 


e Bad TLV value—The TLV Length is too large. 
e Missing TLV—The TLV is missing one or more mandatory parameters. 


e PDU too large—The PDF is greater than the maximum PDU length. Section "Initialization Message" 
in RFC 5036 describes how the maximum PDU length for a session is determined. 


Total Total number of each event or error. 
Last 5 Number of each event or error in the last 5 seconds. 
seconds 


Sample Output 


show lIdp statistics 


user@host> show ldp statistics 














essage type Total Last 5 seconds 

Sent Received Sent Received 
Hello 265 263 2 2 
Initialization 2 2 0 0 
Keepalive MAL A ALaL il 0 
Notification 0 0 0 0 
Address 2, 2 0 0 
Address withdraw 0 0 0 0 
Label mapping 7 6 0 0 
Label request 0 0 0 0 
Label withdraw 2 0 0 0 
Ibloel meeilseise 0 zz) 0 0 
Label abort 0 0 0 0 
All UDP 265 263 2 2 
All TCP 123 20 il 0 
Event type Total Last 5 seconds 
Sessions opened 2; 


Sessions closed 


Topology changes alae 0 


No interface 0 0 
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| show Idp traffic-statistics 


Syntax 


show lIdp traffic-statistics 

<instance instance-name> 

<logical-system (all | logical-system-name)> 
<p2mp> 


Release Information 

Command introduced before Junos OS Release 7.4. 

p2mp option added in Junos OS Release 11.2. 

Command introduced in Junos OS Release 13.2X51-D15 for the QFX Series. 


Description 
Display Label Distribution Protocol (LDP) traffic statistics. 


NOTE: If nonstop active routing features is configured, show Idp traffic-statistics command is 
not supported on backup Routing Engines. 


Options 


none—Display LDP traffic statistics for all routing instances. 
instance instance-name—(Optional) Display LDP traffic statistics for the specified routing instance only. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


p2mp—(Optional) Display only the data traffic statistics for a point-to-multipoint LSP. 


Additional Information 


To collect output from this command on a periodic basis, configure the traffic-statistics statement for the 
LDP protocol. For more information, see the Junos MPLS Applications Configuration Guide. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


clear Idp statistics | 2555 
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Example: Configuring Multicast-Only Fast Reroute in a Multipoint LDP Domain | 956 


Example: Configuring Multipoint LDP In-Band Signaling for Point-to-Multipoint LSPs | 1013 


List of Sample Output 


show ldp traffic-statistics on page 2625 

show Idp traffic-statistics p2mp (Ingress or transit router only, Multipoint LDP Inband Signaling for 
Point-to-Multipoint LSPs) on page 2626 

show Idp traffic-statistics p2mp (Multipoint LDP with Multicast-Only Fast Reroute) on page 2627 
show Idp traffic-statistics interface p2mp (Multipoint LDP Interfaces) on page 2627 


Output Fields 


Table 95 on page 2624 lists the output fields for the show Idp traffic-statistics command. Output fields are 
listed in the approximate order in which they appear. 


Table 95: show Idp traffic-statistics Output Fields 


Field Name 


Message type 


FEC 


Type 


Packets 


Bytes 


Shared 


Nexthop 


Field Description 
LDP message types. 


Forwarding equivalence class (FEC) for which LDP traffic statistics are collected. 
For P2MP LSPs, FEC appears as a combination of root address and the LSP ID (root_addr:Isp_id). 


For multipoint LDP P2MP LSPs, FEC appears as a combination of root address multicast source 
address, and multicast group address (root_addr:Isp_id/grp,src). 


Type of traffic originating from a router, either Ingress (originating from this router) or Transit 


(forwarded through this router). 

Number of packets passed by the FEC since its LSP came up. 

Number of bytes of data passed by the FEC since its LSP came up. 

Whether a label is shared by prefixes: Yes or No. A Yes value indicates that several prefixes 

are bound to the same label (for example, when several prefixes are advertised with an egress 
policy). The LDP traffic statistics for this case apply to all the prefixes and should be treated 


as such. 


The next hop address for P2MP LSPs. (This is the downstream LDP Session ID.) 


Table 95: show Idp traffic-statistics Output Fields (continued) 


Field Name 


Label 


Backup route 


Interface 


type 


| Sample Output 


Field Description 


For multipoint LDP with multicast-only fast reroute (MoFRR), the multipoint LDP node selects 
two separate upstream peers and sends two separate labels, one to each upstream peer. The 
same algorithm described in RFC 6388 is used to select the primary upstream path. The backup 
upstream path selection again uses the same algorithm but excludes the primary upstream 
LSR as a candidate. Two streams of MPLS traffic are sent to the egress node from the two 
different upstream peers. The MPLS traffic from only one of the upstream neighbors is selected 
as the primary path to accept the traffic, and the other becomes the backup path. The traffic 
on the backup path is dropped. When the primary upstream path fails, the traffic from the 
backup path is then accepted. The multipoint LDP node selects the two upstream paths based 
on the interior gateway protocol (IGP) root node next hop. 


Multiple MPLS labels are used to control MoFRR stream selection. Each label represents a 
separate route, but each references the same interface list check. Only the primary label is 
forwarded while all others are dropped. Multiple interfaces can receive packets using the same 
label. 

For multipoint LDP with MoFRR, the route that is used if the primary route becomes unavailable. 


Name of the point-to-multipoint interface for which statistics are displayed. 


Type of LDP traffic on the interface. 


show Idp traffic-statistics 


user@host> show ldp traffic-statistics 


MgC. 





10.35.5,0/3C 


IO. 35.10 .1/32 





Type Packets Bytes Shared 
Transit 0 0 Yes 
Ingress 0 0 No 
Transit 0 0 MoS 
Ingress 0 0 No 
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NO. 255.245.2047 32 


192.168.5379 . 36/30 


lal 





HG Gao oem cl Giaialstomeecls) 


Transit 


MMS IGS 


Transit 


Ingress 


Nexthop 


LO 42595 7Ao lOO loyyyaly We 5 Wes, 











INE EE Car Siectteesstesesr 





HEE 
105255. 107 230/32 








P2MP FEC Statistics: 





Shared 


L265 UNOS 


WE 5 MOS) 


Type 


Transit 


IMCS SSS 


HE Gite @oemccclrasulsomelcl/icitsorsuse) 


LiL 505 WSEAS 5 ID 50) ye LAL 5 NS}.5 10) 5 IL 





No 


LiL 6 99.05 7S8 A239 610.0547 Wil. 9850. Le 


11 OO Oa VSSASI LO. O5l, Ll, Vo 0.20 


Li 99506 VSS 2325 10 5 O54, Ii 5 9350520 


5 tii 


OW) 


user@host> show ldp traffic-statistics p2mp 


Nexthop 


Li, 950. 


11,9950. 





LA 99.0. 


1 99,0. A 


Lio YO oWed 


Ti Sos AL 


deal 


Packets 


ESA D6 


152056 


152056 


Packets 


30858 
20 


lay 


13) 


Ly 


7 





ay 


VS2 


Bytes 


14597376 


14597376 


14597376 


Bytes 


2022345 
5120 


Packets 


243408 


236286 


248800 


240759 


250286 


243741 


ZS 2) HO) 
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yes 


No 


Shared 


No 


No 


No 


Shared 


No 
No 


show Idp traffic-statistics p2mp (Ingress or transit router only, Multipoint LDP Inband Signaling for 
Point-to-Multipoint LSPs) 


Byes 


121217184 


117670428 


123902400 


LILI M2 


124642428 


121383018 


125979060 


show ldp traffic-statistics p2mp (Multipoint LDP with Multicast-Only Fast Reroute) 


11, 9950.13 


user@host> show ldp traffic-statistics p2mp 


P2MP FEC Statistics: 








Shared 


Lodo lols eseoloiloly 192,168,419), 


No 


No 


Loidol  lges2olsioly 1925168 .219), 


No 


No 


Melo ls lgAaeo silo ts L924. Os 5219). 


No 


Leds leAeo ds lot, Oe 5 WSS 5219) 5 


EE Gi(te@ oemeciclclratules omeltcly/icptatoresuae)) 


Nexthop 


Ingles SOUS 
LeSossd 


Ie erase 


iIngloeile SO1S84!, 
Lo Sobsd 


Le Sone 


Label: 301600 
LeSoss2 


Lo Sots2 


Label: 301616, 


245218 


Packets 


Backup route 
0 


Backup route 


show Idp traffic-statistics interface p2mp (Multipoint LDP Interfaces) 


user@host> show ldp traffic-statistics interface p2mp 


od 50 
ge-0/0/0.0 


Interface type 
p2mp 
p2mp 


TW erat ee 0 
Le Sotsz 0 
Receive Transmit 
Packets Bytes Packets 
0 0 0 

10 AAO) 0 


122118564 


Byes 
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| show security keychain 


Syntax 


show security keychain 
<brief | detail> 


Release Information 
Command introduced in Junos OS Release 11.2. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Display information about authentication keychains configured for the Border Gateway Protocol (BGP), 
the Label Distribution Protocol (LDP) routing protocols, the Bidirectional Forwarding Detection (BFD) 
protocol, and the Intermediate System-to-Intermediate System (IS-IS) protocol. 


Options 


none—Display information about authentication keychains. 


brief | detail—(Optional) Display the specified level of output. 


Required Privilege Level 
view 


List of Sample Output 
show security keychain brief on page 2631 
show security keychain detail on page 2631 


Output Fields 


Table 96 on page 2629 describes the output fields for the show security keychain command. Output fields 
are listed in the approximate order in which they appear. 


Table 96: show security keychain Output Fields 


Field Name Field Description Level of Output 
keychain The name of the keychain in operation. All levels 
Active-ID Send Number of routing protocols packets sent with the active key. All levels 
Active-ID Number of routing protocols packets received with the active key. All levels 

Receive 


Next-ID Send Number of routing protocols packets sent with the next key. All levels 


Table 96: show security keychain Output Fields (continued) 


Field Name 


Next-ID Receive 


Transition 


Tolerance 


Id 


Algorithm 


State 


Option 


Field Description 


Number of routing protocols packets received with the next key. 


Amount of time until the current key will be replaced with the 
next key in the keychain. 


Configured clock-skew tolerance, in seconds, for accepting keys 
for a key chain. 


Identification number configured for the current key. 


Authentication algorithm configured for the current key. 


State of the current key. 
The value can be: 


e receive 

e send 

e send-receive 

For the active key, the State can be send-receive, send, or receive. 


For keys that have a future start time, the State is inactive. 
Compare the State field to the Mode field. 


For IS-IS only, the option determines how Junos OS encodes the 
message authentication code in routing protocol packets. 


The values can be: 


e basic—Based on RFC 5304. 
e isis-enhanced—Based on RFC 5310. 


The default value is basic. When you configure the isis-enhanced 
option, Junos OS sends RFC 5310-encoded routing protocol 
packets and accepts both RFC 5304-encoded and RFC 
5310-encoded routing protocol packets that are received from 
other devices. 


When you configure basic (or do not include the options statement 
in the key configuration) Junos OS sends and receives RFC 
5304-encoded routing protocols packets, and drops 5310-encoded 
routing protocol packets that are received from other devices. 


Because this setting is for 1S-IS only, the TCP and the BFD protocol 
ignore the encoding option configured in the key. 
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Level of Output 


All levels 


All levels 


All levels 


detail 


detail 


detail 


detail 
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Table 96: show security keychain Output Fields (continued) 


Field Name Field Description Level of Output 
Start-time Time that the current key became active. detail 
Mode Mode of each key (Informational only.) detail 


The value can be 


e receive 

e send 

e send-receive 

The mode of the key is based on the configuration. Suppose you 
configure two keys, one with a start-time of today and the other 
with a start-time of next week. For both keys, the Mode can be 


send-receive, send, or receive, regardless of the configured 
start-time. Compare the Mode field to the State field. 


| Sample Output 


show security keychain brief 


user@host> show security keychain brief 





keychain Active-ID Next-ID Transition Tolerance 
Send Receiv Send Receiv 
hakr 3 3 1 il lg 23258 3600 


show security keychain detail 


user@host> show security keychain detail 





keychain Active-ID Next-—ID Transition Tolerance 
Send Receiv Send Receiv 
hakr 3 3 iL i lc, 235258 3600 





Id 3, Algorithm hmac-md5, State send-receive, Option basic 
Start-time Wed Aug 11 16:28:00 2010, Mode send-receiv 





Id 1, Algorithm hmac-md5, State inactive, Option basic 
Start-time Fri Aug 20 11:30:57 2010, Mode send-receiv 
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traceroute mpls Idp 


Syntax 


traceroute mpls <Idp> fec 
<destination ip-address> 

<detail> 

<exp exp> 

<fanout fanout-number> 
<logical-system logical-system-name> 
<no-resolve> 

<paths maximum-paths> 
<pipe-mode> 

<retries retries-number> 
<routing-instance routing-instance-name> 
<source ip-address> 

<ttl value> 

<update> 

<wait seconds> 


Release Information 
Command introduced in Junos OS Release 8.4. 
Statement introduced in Junos OS Release 12.3X50 for the QFX Series. 


Description 

Trace route to a remote host for an MPLS label-switched path signaled by the LDP. Use traceroute mpls 
Idp as a debugging tool to locate MPLS label-switched path forwarding issues in a network. (Currently 
supported for IPv4 packets only.) 


Options 


fec—Specify the IP address and optional prefix of the forwarding equivalence class (FEC). 


destination ip-address—(Optional) Specify the destination address to use when sending probes. 


Values: The destination IP address must be within the 127.0.0.0/8 IP address space for Operation, 
Administration, and Maintenance (OAM) packets. 


detail—(Optional) Display detailed output. 


exp exp—(Optional) Specify the class-of-service to use when sending probes. 
Range: O through 7 
Default: 7 
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fanout fanout-number—(Optional) Specify the maximum number of nexthops to search per node. 
Range: 1 through 16 
Default: 16 


logical-system—(Optional) Specify the name of the logical system for the traceroute attempt. 
no-resolve—(Optional) Specify not to resolve the hostname that corresponds to the IP address. 


paths maximum-paths—(Optional) Specify the maximum number of paths to search. 
Range: 1 through 255 
Default: 16 


pipe-mode—(Optional) Specify to trace only nodes that understand LDP FEC. 


In an interoperation with other vendor devices or devices running Junos OS Release that do not support 
tracing of hierarchical LSPs as described in RFC 6424, continuous non-complaint probe status is 
displayed in the traceroute mpls Idp command output. To avoid this LDP loop creation, use the 
pipe-mode option with the traceroute mpls Idp fec command. 


NOTE: Even after using the traceroute mpls Idp fec pipe-mode command, one or more 
intermediate transit nodes that do not understand LDP FEC can return non-complaint probe 
status in the command output. 


retries retries-number—(Optional) Specify the number of times to resend probe values. 
Range: 1 through 9 
Default: 3 


routing-instance routing-instance-name—(Optional) Specify the name of the routing instance for the 
traceroute attempt. 


source source-address—(Optional) Specify the source address of the outgoing traceroute packets. 


ttl value—(Optional) Specify the maximum time-to-live value to include in the traceroute request, in seconds. 
Range: 1 through 125 
Default: 64 


update—(Optional) Update database contents with traceroute results. 


wait seconds—(Optional) Specify the number of seconds to wait before resending a probe. 
Range: 5 through 15 
Default: 10 


Required Privilege Level 


network 


List of Sample Output 


traceroute mpls Idp on page 2635 
traceroute mpls Idp detail on page 2635 


Output Fields 


Table 75 on page 2473 describes the output fields for the traceroute mpls Idp fec command and the traceroute 
mpls Idp fec detail commands. Output fields are listed in the approximate order in which they appear. 


Table 97: traceroute mpls Idp Output Fields 


Field Name 


Probe options 


ttl 


Label 


Protocol 


Address 


Previous Hop 


Probe status 


Hop 


Parent 


Return Code 


Response time 


Multipath type 


Label Stack 


Field Description 


Probe options specified in the traceroute mpls Idp fec command. 


Time to live value of the labeled packet. 


Outgoing label used for forwarding the packet along the 
label-switched paths. 


Signaling protocol used. For this command, it is LDP. 


Address of the next hop. 


Address of the previous hop. Previous hop address of the first 
hop is null. 


Forwarding status from the first hop to the last-hop 
label-switching router (egress point in the label-switched paths). 


Address of the hops in the label-switched path from the first 
hop to the last hop. Depth indicates the level of the hop. 


Address of the previous hop. Parent value for the first hop is 
null. 


Return code for reporting the result of processing the echo 
request by the receiver. 


Time for the echo request to reach the receiver. 


Labels or addresses used by the specified multipath type. If 
multipaths are not used, the value is none. 


Label stack used to forward the packet. 


Level of Output 


all levels 


none specified 


none specified 


none specified 


none specified 


none specified 


none specified 


detail 


detail 


detail 


detail 


detail 


detail 
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| Sample Output 


traceroute mpls Idp 


user@router> traceroute mpls Idp 4.4.4.4 


Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16 








ciel Label Protocol Address Previous Hop Probe Status 
al 100016 LDP 24 .24,24 1 fan) Success 
er 100000 LDP 20 c2B0> 20.2 24.24.24.1 Success 
S 3 ID? ADD, AED Poy AD 20 620.2 Egress 


Path 1 via fe-0/3/3.101 destination 127.0.0.64 


traceroute mpls Idp detail 


user@router> traceroute mpls Idp 4.4.4.4 detail 


Probe Options: ttl 64, retries 3, wait 10, paths 3, exp 7 
Hop 24.24.24.1 Depth 1 

Parent (null) 

Return code: Label switched at stack-depth 1 

Response time 165.93 msec 

ultipath type: IP bitmask 

Neolcheass Reine is 127 -.0.0.0 ~ L27.0.3,.255 

Label Stack: 





Label 1 Value 100032 Protocol LDP 


HoprZ0m2Z0n20. 2 DepEeh 2 
Parent 24.24.24.1 





Return code: Upstream interface index unknown label-switched at stack-depth 1 


Response time 19.05 msec 

ultipath type: IP bitmask 

MCeSS Reinge 18 127,000.60 ~ 127.025.4255 
Label Stack: 

Label 1 Value 100000 Protocol LDP 





eye) ZAo22 22.4 Wesel 
Parent 20.20.20.2 





Return code: Egress-ok at stack-depth 1 


Response time 0.79 msec 
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traceroute mpls segment-routing ospf 


Syntax 


traceroute mpls segment-routing ospf<Idp> fec 
<destination ip-address> 

<detail> 

<exp exp> 

<fanout fanout-number> 

<logical-system logical-system-name> 
<no-resolve> 

<paths maximum-paths> 

<pipe-mode> 

<retries retries-number> 
<routing-instance routing-instance-name> 
<source ip-address> 

<ttl value> 

<update> 

<wait seconds> 


Release Information 
Command introduced in Junos OS Release 19.1R1. 


Description 

Trace route to a remote host for a segment routing label-switched path added by the ISIS protocol. Use 
traceroute mpls segment-routing isisp as a debugging tool to locate MPLS label-switched path forwarding 
issues in a network. (Currently supported for IPv4 packets only.) 


Options 


fec—Specify the IP address and optional prefix of the forwarding equivalence class (FEC). 


destination ip-address—(Optional) Specify the destination address to use when sending probes. 
Values: The destination IP address must be within the 127.0.0.0/8 IP address space for Operation, 
Administration, and Maintenance (OAM) packets. 


detail—(Optional) Display detailed output. 


exp exp—(Optional) Specify the class-of-service to use when sending probes. 
Range: O through 7 
Default: 7 


fanout fanout-number—(Optional) Specify the maximum number of nexthops to search per node. 
Range: 1 through 16 
Default: 16 


2638 


logical-system—(Optional) Specify the name of the logical system for the traceroute attempt. 
no-resolve—(Optional) Specify not to resolve the hostname that corresponds to the IP address. 


paths maximum-paths—(Optional) Specify the maximum number of paths to search. 
Range: 1 through 255 
Default: 16 


retries retries-number—(Optional) Specify the number of times to resend probe values. 
Range: 1 through 9 
Default: 3 


routing-instance routing-instance-name—(Optional) Specify the name of the routing instance for the 
traceroute attempt. 


source source-address—(Optional) Specify the source address of the outgoing traceroute packets. 


ttl value—(Optional) Specify the maximum time-to-live value to include in the traceroute request, in seconds. 
Range: 1 through 125 
Default: 64 


wait seconds—(Optional) Specify the number of seconds to wait before resending a probe. 
Range: 5 through 15 
Default: 10 


Required Privilege Level 
network 


List of Sample Output 
traceroute mpls segment-routing isis on page 2639 


Output Fields 

Table 75 on page 2473 describes the output fields for the traceroute mpls segment-routing isis fec command 
and the traceroute mpls segment-routing isis fec detail commands. Output fields are listed in the 
approximate order in which they appear. 


Table 98: traceroute mpls Idp Output Fields 


Field Name Field Description Level of Output 
Probe options Probe options specified in the traceroute mplsIdp fec command. _ all levels 

ttl Time to live value of the labeled packet. none specified 
Label Outgoing label used for forwarding the packet along the none specified 


label-switched paths. 


Table 98: traceroute mpls Idp Output Fields (continued) 


Field Name 


Protocol 


Address 


Previous Hop 


Probe status 


Hop 


Parent 


Return Code 


Response time 


Multipath type 


Label Stack 


Field Description 


Signaling protocol used. For this command, it is LDP. 


Address of the next hop. 


Address of the previous hop. Previous hop address of the first 
hop is null. 


Forwarding status from the first hop to the last-hop 
label-switching router (egress point in the label-switched paths). 


Address of the hops in the label-switched path from the first 
hop to the last hop. Depth indicates the level of the hop. 


Address of the previous hop. Parent value for the first hop is 
null. 


Return code for reporting the result of processing the echo 
request by the receiver. 


Time for the echo request to reach the receiver. 


Labels or addresses used by the specified multipath type. If 
multipaths are not used, the value is none. 


Label stack used to forward the packet. 


Sample Output 


traceroute mpls segment-routing isis 


user@router> traceroute mpls Idp 4.4.4.4 
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Level of Output 


none specified 


none specified 


none specified 


none specified 


detail 


detail 


detail 


detail 


detail 


detail 


Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16 


eee Label Protocol Address Previous Hop 
il 402006 ISIS IA ely il 2 (null) 

HRC [Suack sents, Sas 

ee L Label Protocol Address Previous Hop 





Probe Status 


Success 


Probe Status 


2 402006 ISIS 


iz 


EC-Stack-Sent: 


co 


ny 


EC-Stack-Sent: 


ISIS 


eal Label Protocol 
3 402006 ISIS 


ISIs 


eel Label Protocol 


ny 


EC-Stack-Sent: 


ct 





FEC-Stack-Sent: 


4 402006 ISIS 


ISIS 


eal Label Protocol 
5 3 isis 


ISIs 


sed oils & 


Address 
Bl ok od eA 


Address 
ANS Moyle 


Address 
Oeil. dl. 2 


Wea dl odo 


Previous 


ES oto dod 


Previous 


SS dh pda 


Previous 


ATS eyeliner 


Path 1 via ge-0/0/0.0 destination 127.0.0.64 


eical Label Protocol 


ny 


EC-Stack-Sent: 


ct 


iz 


EC-Stack-Sent: 


ct 





FEC-Stack-Sent: 


5 402006 ISIS 


ISIs 


eal Label Protocol 
4 402006 ISIS 


ISIS 


eal Label Protocol 
5 3 iSis 


ISIS 


Address 
BS ee thee 


Address 
Abe ele, 


Address 
Sociol. 2 


Previous 


ES otodiod 


Previous 


Sari lear 


Previous 


Ao is do 2 


Path 2 via ge-0/0/0.0 destination 127.0.0.65 


wick Label Protocol 


Hy 


EC-Stack-Sent: 


ct 


iz 


EC-Stack-Sent: 


5 402006 ISIS 


ISIs 


ial Label Protocol 
4 402006 ISIS 


ISIS 


tet Label Protocol 





FEC-Stack-Sent: 


5 3 WSLS 


ISIS 


Address 
Se Sin dF 


Address 
[Giro ollheaye 


Address 
Hoe. dh. 2 


Previous 


ES olodiod 


Previous 


SAM ile 


Previous 


WS 525 dak 


Path 3 via ge-0/0/0.0 destination 127.0.0.69 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Success 


Probe Status 


Success 


Probe Status 


Success 


Probe Status 





Egress 


Probe Status 


Success 


Probe Status 


Success 


Probe Status 





ReEesis 


Probe Status 


Success 


Probe Status 


Success 


Probe Status 





Egress 
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traceroute mpls segment-routing isis 


Syntax 


traceroute mpls segment-routing isis<ldp> fec 
<destination ip-address> 

<detail> 

<exp exp> 

<fanout fanout-number> 

<logical-system logical-system-name> 
<no-resolve> 

<paths maximum-paths> 

<pipe-mode> 

<retries retries-number> 
<routing-instance routing-instance-name> 
<source ip-address> 

<ttl value> 

<update> 

<wait seconds> 


Release Information 
Command introduced in Junos OS Release 19.1R1. 


Description 

Trace route to a remote host for a segment routing label-switched path added by the ISIS protocol. Use 
traceroute mpls segment-routing isisp as a debugging tool to locate MPLS label-switched path forwarding 
issues in a network. (Currently supported for IPv4 packets only.) 


Options 


fec—Specify the IP address and optional prefix of the forwarding equivalence class (FEC). 


destination ip-address—(Optional) Specify the destination address to use when sending probes. 
Values: The destination IP address must be within the 127.0.0.0/8 IP address space for Operation, 
Administration, and Maintenance (OAM) packets. 


detail—(Optional) Display detailed output. 


exp exp—(Optional) Specify the class-of-service to use when sending probes. 
Range: O through 7 
Default: 7 


fanout fanout-number—(Optional) Specify the maximum number of nexthops to search per node. 
Range: 1 through 16 
Default: 16 
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logical-system—(Optional) Specify the name of the logical system for the traceroute attempt. 
no-resolve—(Optional) Specify not to resolve the hostname that corresponds to the IP address. 


paths maximum-paths—(Optional) Specify the maximum number of paths to search. 
Range: 1 through 255 
Default: 16 


retries retries-number—(Optional) Specify the number of times to resend probe values. 
Range: 1 through 9 
Default: 3 


routing-instance routing-instance-name—(Optional) Specify the name of the routing instance for the 
traceroute attempt. 


source source-address—(Optional) Specify the source address of the outgoing traceroute packets. 


ttl value—(Optional) Specify the maximum time-to-live value to include in the traceroute request, in seconds. 
Range: 1 through 125 
Default: 64 


wait seconds—(Optional) Specify the number of seconds to wait before resending a probe. 
Range: 5 through 15 
Default: 10 


Required Privilege Level 
network 


List of Sample Output 
traceroute mpls segment-routing isis on page 2643 


Output Fields 

Table 75 on page 2473 describes the output fields for the traceroute mpls segment-routing isis fec command 
and the traceroute mpls segment-routing isis fec detail commands. Output fields are listed in the 
approximate order in which they appear. 


Table 99: traceroute mpls Idp Output Fields 


Field Name Field Description Level of Output 
Probe options Probe options specified in the traceroute mpls Idp fec command. all levels 

ttl Time to live value of the labeled packet. none specified 
Label Outgoing label used for forwarding the packet along the none specified 


label-switched paths. 


Table 99: traceroute mpls Idp Output Fields (continued) 


Field Name 


Protocol 


Address 


Previous Hop 


Probe status 


Hop 


Parent 


Return Code 


Response time 


Multipath type 


Label Stack 


Field Description 


Signaling protocol used. For this command, it is LDP. 


Address of the next hop. 


Address of the previous hop. Previous hop address of the first 
hop is null. 


Forwarding status from the first hop to the last-hop 
label-switching router (egress point in the label-switched paths). 


Address of the hops in the label-switched path from the first 
hop to the last hop. Depth indicates the level of the hop. 


Address of the previous hop. Parent value for the first hop is 
null. 


Return code for reporting the result of processing the echo 
request by the receiver. 


Time for the echo request to reach the receiver. 


Labels or addresses used by the specified multipath type. If 
multipaths are not used, the value is none. 


Label stack used to forward the packet. 


Sample Output 


traceroute mpls segment-routing isis 


user@router> traceroute mpls Idp 4.4.4.4 
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Level of Output 


none specified 


none specified 


none specified 


none specified 


detail 


detail 


detail 


detail 


detail 


detail 


Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16 


eee Label Protocol Address Previous Hop 
il 402006 ISIS IA ely il 2 (null) 

HRC [Suack sents, Sas 

ee L Label Protocol Address Previous Hop 





Probe Status 


Success 


Probe Status 


2 402006 ISIS 


iz 


EC-Stack-Sent: 


co 


ny 


EC-Stack-Sent: 


ISIS 


eal Label Protocol 
3 402006 ISIS 


ISIs 


eel Label Protocol 


ny 


EC-Stack-Sent: 


ct 





FEC-Stack-Sent: 


4 402006 ISIS 


ISIS 


eal Label Protocol 
5 3 isis 


ISIs 


sed oils & 


Address 
Bl ok od eA 


Address 
ANS Moyle 


Address 
Oeil. dl. 2 


Wea dl odo 


Previous 


ES oto dod 


Previous 


SS dh pda 


Previous 


ATS eyeliner 


Path 1 via ge-0/0/0.0 destination 127.0.0.64 


eical Label Protocol 


ny 


EC-Stack-Sent: 


ct 


iz 


EC-Stack-Sent: 


ct 





FEC-Stack-Sent: 


5 402006 ISIS 


ISIs 


eal Label Protocol 
4 402006 ISIS 


ISIS 


eal Label Protocol 
5 3 iSis 


ISIS 


Address 
BS ee thee 


Address 
Abe ele, 


Address 
Sociol. 2 


Previous 


ES otodiod 


Previous 


Sari lear 


Previous 


Ao is do 2 


Path 2 via ge-0/0/0.0 destination 127.0.0.65 


wick Label Protocol 


Hy 


EC-Stack-Sent: 


ct 


iz 


EC-Stack-Sent: 


5 402006 ISIS 


ISIs 


ial Label Protocol 
4 402006 ISIS 


ISIS 


tet Label Protocol 





FEC-Stack-Sent: 


5 3 WSLS 


ISIS 


Address 
Se Sin dF 


Address 
[Giro ollheaye 


Address 
Hoe. dh. 2 


Previous 


ES olodiod 


Previous 


SAM ile 


Previous 


WS 525 dak 


Path 3 via ge-0/0/0.0 destination 127.0.0.69 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Success 


Probe Status 


Success 


Probe Status 


Success 


Probe Status 





Egress 


Probe Status 


Success 


Probe Status 


Success 


Probe Status 





ReEesis 


Probe Status 


Success 


Probe Status 


Success 


Probe Status 





Egress 
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| traceroute mpls segment-routing spring-te 


Syntax 


traceroute mpls segment-routing spring-te 

<egress-ip (active | color | detail | exp | logical-system | no-resolve | retries | routing-instance | secondary | segment-list 
| skip-fec-validation | source | ttl | tunnel-source) > 

<label-stack ( detail | egress | labels | logical-system | nexthop-address | nexthop-interface | no-resolve) > 

<source-routing-path (Isp-name | active | color | detail | egress-ip | exp | logical-system | no-resolve | retries | 
routing-instance | secondary | segment-list | skip-fec-validation | source | tunnel-source> 


Release Information 
Command introduced in Junos OS Release 20.2R1 for ACX Series, MX Series, PTX Series. 


Description 

Trace route to a remote host for a segment routing label-switched path added by segment routing 
traffic-engineered (SPRING-TE) tunnel. Use traceroute mpls segment-routing spring-te as a debugging 
tool to locate MPLS label-switched path forwarding issues in a network. 


Options 


egress-ip— Specify to trace to or install IP address to use when sending probes. 


active— Specify to use the forwarding path or nexthops from the RIB table. 


color— Specify the color identifier for the tunnel end-point. 
Range: 1 through 4294967295 


detail—(Optional) Display detailed output. 


exp exp—(Optional) Specify the class of service to use when sending probes. 


Range: O through 7 


logical-system logical-system-name—(Optional) Specify the name of the logical system for the traceroute 
attempt. 


no-resolve—Specify not to attempt to print addresses symbolically. 


retries retries-number—(Optional) Specify the number of times to resend probe values. 


Range: 1 through 9 


routing-instance routing-instance-name—(Optional) Specify the name of the routing instance for the 
trace route attempt. 


secondary— Specify to use configured secondary segment list for the given segment routing path. 


segment-list— Specify the segment list to use when sending probes. 
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skip-fec-validation— Specify to skip forwarding equivalence class (FEC) validation or use NIL FEC. 
source source-address—(Optional) Specify the source address of the outgoing traceroute packets. 


ttl value—(Optional) Specify the maximum time-to-live value to include in the traceroute request, in 
seconds. 


Range: 1 through 255 
tunnel-source— Specify the source protocol used to create tunnel. 


label-stack— Specify the label stack for traceroute packets. This option works only if you do a minimum 
configuration of source-packet-routing at the [edit protocols] hierarchy level. 


detail—(Optional) Display detailed output. 
egress— Specify the egress IP address. 


labels— Specify the labels in label stack. 
Range: 16 through 1048575 


logical-system logical-system-name—(Optional) Specify the name of the logical system for the traceroute 
attempt. 


nexthop-address address— Specify the nexthop IP address for the traceroute packet. 
nexthop-interface interface— Specify the outgoing interface for the traceroute packet. 
no-resolve— Specify not to attempt to print addresses symbolically. 


source-routing-path— Specify the trace source path routing to use when sending probes. 


Isp-name— Specify the source path routing name. 
active— Specify to use the forwarding path or nexthops from the RIB table. 


color— Specify the color identifier for the tunnel end-point. 
Range: 1 through 4294967295 


detail—(Optional) Display detailed output. 
egress-ip— Specify to trace to or install IP address to use when sending probes. 


exp exp—(Optional) Specify the class of service to use when sending probes. 


Range: O through 7 


logical-system logical-system-name—(Optional) Specify the name of the logical system for the traceroute 
attempt. 


no-resolve— Specify not to attempt to print addresses symbolically. 
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retries retries-number—(Optional) Specify the number of times to resend probe values. 


Range: 1 through 9 
secondary— Specify to use configured secondary segment list for the given segment routing path. 
segment-list— Specify the segment list to use when sending probes. 
skip-fec-validation— Specify to skip forwarding equivalence class (FEC) validation or use NIL FEC. 
source source-address—(Optional) Specify the source address of the outgoing traceroute packets. 


ttl value—(Optional) Specify the maximum time-to-live value to include in the traceroute request, in 
seconds. 


Range: 1 through 255 


Additional Information 
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NOTE: With segment-list option, valid tunnel-source (source protocol used to create tunnel) is 
only static. 


NOTE: segment-list option is not present when tunnel-source is BGP-SR-TE since BGP-SR-TE 
does not have named segment list. 


NOTE: With source-routing-path name, valid tunnel-source are PCEP and static. 


NOTE: With tunnel-source as PCEP, secondary option is not valid as PCEP always sends one 
primary LSP. 


NOTE: FEC validation is performed for traceroute mpls segment-routing spring-te by default. 


NOTE: FEC validation is supported when segment-routing traffic-engineering (SR-TE) tunnel 
has IGP labels (OSPF and IS-IS) only. For all the other labels (for example, static, Idp, rsvp, etc.), 
you can use skip-fec-validation option. 


NOTE: For a combination of egress-ip and color options, valid tunnel-source are static and 
BGP-SR-TE. 


NOTE: traceroute mpls segment-routing spring-te command with label-stack option is supported 
in operational mode only. It is not supported in configuration mode. 


NOTE: Parallel SID, binding SID, LDP over SR-TE is not supported. 


2649 


NOTE: traceroute mpls segment-routing spring-te for SR-TE tunnel is supported only on the 
ingress router of the SR-TE tunnel and not on the SR-TE tunnel in the transit path. 


NOTE: In case of traceroute mpls segment-routing spring-te, the PFE supports only 16 ECMP 
paths. If there more than 16 ECMP paths to the SR-TE LSP, traceroute is done up to a maximum 
of 16 hops. 


Required Privilege Level 
network 


List of Sample Output 

traceroute mpls segment-routing spring-te on page 2650 

traceroute mpls segment-routing spring-te (source-routing-path) on page 2650 
traceroute mpls segment-routing spring-te (egress-ip) on page 2651 

traceroute mpls segment-routing spring-te (label-stack) on page 2652 

traceroute mpls segment-routing spring-te (without skip-fec-validation) on page 2652 


Output Fields 


Table 75 on page 2473 describes the output fields for the traceroute mpls segment-routing spring-te 
command. Output fields are listed in the approximate order in which they appear. 


Table 100: traceroute mpls spring-te Output Fields 


Field Name Field Description Level of Output 


Probe options Probe options specified in the traceroute mpls segment-routing all levels 
spring-te command. 


ttl Time to live value of the labeled packet. none specified 


Label Outgoing label used for forwarding the packet along the none specified 
label-switched paths. 


Protocol Signaling protocol used. For this command, it is LDP. none specified 
Address Address of the next hop. none specified 
Previous Hop Address of the previous hop. Previous hop address of the first | none specified 


hop is null. 
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Table 100: traceroute mpls spring-te Output Fields (continued) 


Field Name 


Probe status 


Hop 


Parent 


Return Code 


Response time 


Multipath type 


Label Stack 


Sample Output 


Field Description Level of Output 


Forwarding status from the first hop to the last-hop none specified 
label-switching router (egress point in the label-switched paths). 


Address of the hops in the label-switched path from the first detail 
hop to the last hop. Depth indicates the level of the hop. 


Address of the previous hop. Parent value for the first hop is detail 
null. 


Return code for reporting the result of processing the echo detail 
request by the receiver. 


Time for the echo request to reach the receiver. detail 


Labels or addresses used by the specified multipath type. If detail 
multipaths are not used, the value is none. 


Label stack used to forward the packet. detail 


traceroute mpls segment-routing spring-te 


user@host> traceroute mpls segment-routing spring-te 


Possible completions: 


source-routing-path Source Path routing to use when sending probes 


egress-ip 
label-stack 


To/Install IP address to use when sending probes 





Label stack for traceroute packets 


traceroute mpls segment-routing spring-te (source-routing-path) 


user@host> traceroute mpls segment-routing spring-te source-routing-path path_1 active 


skip-fec-validation 


Probe options: 
ieie dL Label 
al 900041 


retries 3, exp 7 
Protocol Address Previous Hop Probe Status 
Simaieae BS ols ik oo (null) Success 





Ey 





LE3| 


HUG] Svack— oCnic ww SOP ReENGS 
tee AL Label Protocol 

al 3 SeeicLe 
FEC-Stack-Sent: SPRING-T] 
eieall Label Protocol 

2 SE statnc 
FEC-Stack-Sent: SPRING-T] 








Ey 


Address 
SH eA g dhe 2 


Address 
AS ale le 


Previous 


239 edo k 


Previous 


Sarl eee, 


Path 1 via ge-0/0/1.0 destination 127.0.0.64 


ieieul Label Protocol 


HEHE Side oenhitn: 


900041 Static 
SPRING-TE 


eel Label Protocol 


FEC-Stack-Sent: 





3 Starve 
SPRING-TE 


feel Label Protocol 





FEC-Stack-Sent: 





2 3 Sitaicae 


SPRING-TI 











Ea} 


Address 
Sa eia dh a2 


Address 
Saale 


Address 
AS) AL ll 24 


Previous 


(and) 


Previous 


DS 5B dod 


Previous 


34 Ae 


Path 2 via ge-0/0/2.0 destination 127.0.1.64 


traceroute mpls segment-routing spring-te (egress-ip) 


user@host> traceroute mpls segment-routing spring-te egress-ip 5.5.5.5 color 6 skip-fec-validation 














Probe options: retries 3, exp 7 
ie Label Protocol Address 
900041 Static Bshe dhe db a2) 
FEC-Stack-Sent: SPRING-TE 
ie AL Label Protocol Address 
3 Sieeicae Sle hs he 
FEC-Stack-Sent: SPRING-TE 
eicall Label Protocol Address 
z Seolecicske AS vlan cez 
FEC-Stack-Sent: SPRING-TE 








Previous 


Garver a 


Previous 


O35 kode dk 


Previous 


Seal plays 


Path 1 via ge-0/0/1.0 destination 127.0.0.64 





feeul Label Protocol 

‘lL 900041 Static 
HRC old ck oC hic Ol ReENGS ab 
ie aL Label Protocol 

iL 3 SieeicLe 





EF] 


Address 
286 ode 2 


Address 
SO area 


Previous 


(ani) 


Previous 


DS) 9 Bodh ok 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Hop 


Probe Status 


Success 


Probe Status 





Egress 


Probe Status 


Success 


Probe Status 


Success 


Probe Status 





Egress 


Probe Status 


Success 


Probe Status 


Success 


Probe Status 





Egress 


Probe Status 


Success 


Probe Status 


Success 
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FEC-Stack-Sent: SPRING-TE 
ieiesl Label Protocol Address Previous Hop Probe Status 
2 3 Statue Nope AL es dhe Sar aa. Egress 








HEC Stack Sena mor RUNG Saul 





1E3| 


Path 2 via ge-0/0/2.0 destination 127.0.1.64 


traceroute mpls segment-routing spring-te (label-stack) 


user@host> traceroute mpls segment-routing spring-te label-stack labels 900006 labels 900041 
nexthop-address 12.1.1.2 nexthop-interface ge-0/0/0.0 egress 6.6.6.6 


Probe options: retries 3, exp 7 














ciel Label Protocol Address Previous Hop Probe Status 
il 900041 Static boa Ba Ra (and) Success 

FEC-Stack-Sent: SPRING-TE 

eel Label Protocol Address Previous Hop Probe Status 
2 OO C0 Sitecitesnc AS elk edb yA ve Abell oe Success 

FEC-Stack-Sent: SPRING-TE 

wie dl Label Protocol Address Previous Hop Probe Status 
i Seolecicse Sab lee oS pelle eee Success 

FEC-Stack-Sent: SPRING-TE 

wie sl Label Protocol Address Previous Hop Probe Status 
2 900006 Static AVG Me dll ci SH dod ok SuCee sis 

FEC-Stack-Sent: SPRING-TE 

ciel Label Protocol Address Previous Hop Probe Status 
3 3 Seacae BG, I th 2? AD elle) Egress 











FEC-Stack-—Sent: SPRING-T! 





Bd 


Path 1 via ge-0/0/0.0 destination 127.0.0.64 


traceroute mpls segment-routing spring-te (without skip-fec-validation) 


user@host> traceroute mpls segment-routing spring-te label-stack labels [700006 900041] 
nexthop-address 12.1.1.2 nexthop-interface ge-0/0/0.0 egress 6.6.6.6 detail 


Probe options: retries 3, exp 7 
Eig I. oit.2 Deysiela I 
PrRObem cece lSramollecess 
Parent: (null) 
Return code: Label switched at stack-depth 2 
Sender timestamp: 2020-02-07 15:58:01 IST -556533.27 msec 
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Receiver timestamp: 2020-02-07 15:58:01 IST —-416100.73 msec 
Response time: 140432.55 msec 
MTU: Unknown 
Multipath type: IP bitmask 
Address Range 1: 127.0.0.64 ~ 127.0.0.127 
Label Stack: 
Label 1 Value 900041 Protocol Static 
Label 2 Value 900006 Protocol Unknown 
FEC-Stack-Sent: SPRING-T] 








se | 





Hop a23-1-1-2.deploy.static.akamaitechnologies.com (23.1.1.2) Depth 2 
POD Cm slecdielic mses 
Pewemes I2ei.l.Z 
Return code: Label switched at stack-depth 2 
Sender timestamp: 2020-02-07 15:58:02 IST 1334768.46 msec 
Receiver timestamp: 2020-02-07 15:58:02 IST 1447352.44 msec 
Response time: 112583.98 msec 
rg Lia 
ultipath type: IP bitmask 
Address Range 1: 127.0.0.64 ~ 127.0.0.127 
Label Stack: 
Label 1 Value 900041 Protocol Static 
EER@—Gtack—-Ssene: SPRENGST 








eS 





Hop 34.1.1.2 Depth 1 
GOO Cmcleciauicn mm olulecccis 
Parent: a23-1-1-2.deploy.static.akamaitechnologies.com (23.1.1.2) 
Return code: Label switched at stack-depth 1 
Sender timestamp: 2020-02-07 15:58:03 IST 673412.22 msec 
Receiver timestamp: 2020-02-07 15:58:03 IST 812650.76 msec 
Response time: 139238.54 msec 
aig iia 
ultipath type: IP bitmask 

Addresism Ranges: 00m 64 Zr Or Ore 7, 
Label Stack; 

Label 1 Value 3 Protocol Static 
ER@—Gtack-sene: SPRENGST 








Les 





Hop 45.1.1.2 Depth 2 
PHOS Stacuss Success 
Resemes S44. 1.2 
Return code: Label switched at stack-depth 1 
Sender timestamp: 2020-02-07 15:58:03 IST -—553355.00 msec 
Receiver timestamp: 2020-02-07 15:58:03 IST -444464.69 msec 
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Response time: 108890.31 msec 
MTU: 1514 
Multipath type: IP bitmask 

AdGisesism Rang culmea 00h CAN el Zar OriO pelea, 
Label Stack: 

Label 1 Value 900006 Protocol Static 
FEC-Stack-Sent: SPRING-T] 





1) 





es HS toe Deja 3 


Probe status: Egress 





Pansies 45 elec 





Return code: Egress-ok at stack-depth 1 
Sender timestamp: 2020-02-07 15:58:12 IST -1863994.33 msec 
Receiver timestamp: 2020-02-07 15:58:12 IST -1807438.20 msec 
Response time: 56556.13 msec 
aw iil 
ultipath type: IP bitmask 
Address Range 1: 127.0.0.64 ~ 127.0.0.127 
Label Stack: 
Label 1 Value 3 Protocol Static 








ee | 


FEC-Stack-Sent: SPRING-TI 





Path 1 via ge-0/0/0.0 destination 127.0.0.64 
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CHAPTER 29 


CCC and TCC Operational Commands 


IN THIS CHAPTER 


@ ~showconnections | 2656 
@ show route ccc | 2660 
@ show route forwarding-table | 2662 
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| show connections 


List of Syntax 
Syntax on page 2656 
Syntax (EX Series Switches) on page 2656 


Syntax 


show connections 

<brief | extensive> 

<all | interface-switch | Isp-switch | p2mp-receive-switch | p2mp-transmit-switch | remote-interface-switch> 
<down | up | up-down> 

<history> 

<labels> 

<logical-system (all | logical-system-name)> 

<name> 


<status> 


Syntax (EX Series Switches) 


show connections 

<brief | extensive> 

<all | interface-switch | Isp-switch | p2mp-receive-switch | p2mp-transmit-switch | remote-interface-switch> 
<down | up | up-down> 

<history> 

<labels> 

<name> 


<status> 


Release Information 
Command introduced before Junos OS Release 7.4. 
Command introduced in Junos OS Release 9.5 for EX Series switches. 


Description 


Display information about the configured circuit cross-connect (CCC) connections. 


Options 


none—Display the standard level of output for all configured CCC connections. 
all—(Optional) Display all connections. 


brief | extensive—(Optional) Display the specified level of output. Use history to display information about 
connection history. Use labels to display labels used for transmit and receive LSPs. Use status to display 
information about the connection and interface status. 
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interface-switch—(Optional) Display interface switch connections only. 
Isp-switch—(Optional) Display LSP switch connections only. 


p2mp-receive-switch—(Optional) Display point-to-multipoint LSP to local interfaces switch connections 
only. 


p2mp-transmit-switch—(Optional) Display local interface to point-to-multipoint LSP switch connections 
only. 


remote-interface-switch—(Optional) Display remote interface switch connections only. 

down | up | up-down—(Optional) Display nonoperational, operational, or both kinds of connections. 
history—(Optional) Display information about connection history. 

labels—(Optional) Display labels used for transmit and receive. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on a 
particular logical system. 


name—(Optional) Display information about the specified connection only. 


status—(Optional) Display information about the connection and interface status. 


Required Privilege Level 
view 


Output Fields 


Table 39 on page 2305 describes the output fields for the show connections command. Output fields are 
listed in the approximate order in which they appear. 


Table 101: show connections Output Fields 


Field Name Field Description 


CCC and TCC Whether link monitoring is enabled: On or Off. 
connections [Link 

Monitoring On | 

Off] 


Legend for Status Connection or circuit status. See the output's legend for an explanation 
(St) of the status field values. 


Table 101: show connections Output Fields (continued) 


Field Name 


Legend for 
connection types 


Legend for circuit 
types 


Connection/Circuit 


Type 


St 


Time last up 


# Up trans 


Field Description 


Type of connection: 


e if-sw—Layer 2 switching cross-connect. 


e rmt-if—Remote interface switch. While graceful restart is in progress, 
rmt-if will display a state (St) of Restart. 


e Isp-sw—LSP stitching cross-connect. While graceful restart is in progress, 
Isp-sw will display a state (St) of Restart. 


Type of circuits: 


e intf—Interface circuit. 
e tlsp—Transmit LSP circuit. 


e rlsp—Receive LSP circuit. 


Name of the configured CCC connection. 


Type of connection. 


State of the connection. 


Time that the connection or circuit last transitioned to the Up (operational) 


state. 


Number of times that the connection or circuit has transitioned to the Up 


(operational) state. 


| Sample Output 


show connections 


user@switch> show connections 


CCC and TCC connections [Link Monitoring On] 








—- Only Joule bound conn si up 


Legend for status (St) 


DS —- disabled 


Dn —- down 


Legend for connection types 





UN -- uninitialized if-sw: interface switching 
NP -- not present rmt-if: remote interface switching 
WE -- wrong encapsulation lsp-sw: LSP switching 





Legend for circuit types 


jer ——= ALigheeuere Elie 
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| show route ccc 


Syntax 


show route ccc ccc 
<brief | detail | extensive | terse> 
<logical-system (all | logical-system-name)> 


Release Information 
Command introduced before Junos OS Release 7.4. 


Description 


Display circuit cross-connect (CCC) entries in the Multiprotocol Link Switching (MPLS) routing table. 


Options 


ccc—Name of an entry with a circuit cross-connect interface. 
brief | detail | extensive | terse—(Optional) Display the specified level of output. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or ona 
particular logical system. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


show connections | 2304 


List of Sample Output 
show route ccc extensive on page 2660 


Output Fields 


For information about output fields, see the output field tables for the show route command, the show 
route detail command, the show route extensive command, or the show route terse command. 


| Sample Output 


show route ccc extensive 


user@host> show route ccc fe-0/1/0.600 extensive 


mpls.0: 19 destinations, 19 routes (19 active, 0 holddown, 0 hidden) 
fe-0/1/2.600 (1 entry, 1 announced) 

WSLS 

KRT in-kernel fe-0/1/2.600.0 Pie => 14010 ,0.40)} 


ZeCCe Preference: 7 





Next-hop reference count: 2 
Next hop: via so-0/0/3.0 weight 0x1, selected 
Label operation: Push 101424 


State: <Active Int> 





OcaulayASis 100 
Age: 28:13 Metric: 3 
Task: MPLS 


Announcement bits (1): O-KRT 
AS@ path: 
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| show route forwarding-table 


List of Syntax 

Syntax on page 2662 

Syntax (MX Series Routers) on page 2662 

Syntax (TX Matrix and TX Matrix Plus Routers) on page 2662 


Syntax 


show route forwarding-table 
<detail | extensive | summary> 
<all> 

<ccc interface-name> 

<destination destination-prefix> 
<family family | matching matching> 
<interface-name interface-name> 
<label name> 

<matching matching> 

<multicast> 

<table (default | logical-system-name/routing-instance-name | routing-instance-name)> 
<vlan (all | vian-name)> 

<vpn vpn> 


Syntax (MX Series Routers) 


show route forwarding-table 

<detail | extensive | summary> 

<all> 

<bridge-domain (all | domain-name)> 
<ccc interface-name> 

<destination destination-prefix> 
<family family | matching matching> 
<interface-name interface-name> 
<label name> 

<learning-vlan-id learning-vlan-id> 
<matching matching> 

<multicast> 

<table (default | logical-system-name/routing-instance-name | routing-instance-name)> 
<vlan (all | vian-name)> 

<vpn vpn> 


Syntax (TX Matrix and TX Matrix Plus Routers) 
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show route forwarding-table 
<detail | extensive | summary> 
<all> 

<ccc interface-name> 
<destination destination-prefix> 
<family family | matching matching> 
<interface-name interface-name> 
<matching matching> 

<label name> 

<lcc number> 

<multicast> 

<table routing-instance-name> 


<vpn vpn> 


Release Information 

Command introduced before Junos OS Release 7.4. 

Option bridge-domain introduced in Junos OS Release 7.5 

Option learning-vlan-id introduced in Junos OS Release 8.4 

Options all and vlan introduced in Junos OS Release 9.6. 

Command introduced in Junos OS Release 11.3 for the QFX Series. 
Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series. 


Description 

Display the Routing Engine's forwarding table, including the network-layer prefixes and their next hops. 
This command is used to help verify that the routing protocol process has relayed the correction information 
to the forwarding table. The Routing Engine constructs and maintains one or more routing tables. From 
the routing tables, the Routing Engine derives a table of active routes, called the forwarding table. 


NOTE: The Routing Engine copies the forwarding table to the Packet Forwarding Engine, the 
part of the router that is responsible for forwarding packets. To display the entries in the Packet 
Forwarding Engine's forwarding table, use the show pfe route command. 


Options 
none—Display the routes in the forwarding tables. By default, the show route forwarding-table command 
does not display information about private, or internal, forwarding tables. 


detail | extensive | summary—(Optional) Display the specified level of output. 


all—(Optional) Display routing table entries for all forwarding tables, including private, or internal, tables. 
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bridge-domain (all | bridge-domain-name)—(MX Series routers only) (Optional) Display route entries for all 
bridge domains or the specified bridge domain. 


ccc interface-name—(Optional) Display route entries for the specified circuit cross-connect interface. 
destination destination-prefix—(Optional) Destination prefix. 


family family—(Optional) Display routing table entries for the specified family: bridge (ccc | destination | 
detail | extensive | interface-name | label | learning-vlan-id | matching | multicast | summary | table | 
vian | vpn), ethernet-switching, evpn, fibre-channel, fmembers, inet, inet6, iso, mcsnoop-inet, 
mcsnoop-inet6, mpls, satellite-inet, satellite-inet6, satellite-vpls, tnp, unix, vpls, or vlan-classification. 


interface-name interface-name—(Optional) Display routing table entries for the specified interface. 
label name—(Optional) Display route entries for the specified label. 


Icc number—(TX Matrix and TX matrix Plus routers only) (Optional) On a routing matrix composed of a TX 
Matrix router and T640 routers, display information for the specified T640 router (or line-card chassis) 
connected to the TX Matrix router. On a routing matrix composed of the TX Matrix Plus router and 
T1600 or T4000 routers, display information for the specified router (line-card chassis) connected to 
the TX Matrix Plus router. 


Replace number with the following values depending on the LCC configuration: 


e O through 3, when T640 routers are connected to a TX Matrix router in a routing matrix. 
e O through 3, when T1600 routers are connected to a TX Matrix Plus router in a routing matrix. 


e Othrough 7, when T1600 routers are connected to a TX Matrix Plus router with 3D SIBs in a routing 
matrix. 


e O, 2, 4, or 6, when T4000 routers are connected to a TX Matrix Plus router with 3D SIBs in a routing 
matrix. 


learning-vlan-id learning-vian-id—(MX Series routers only) (Optional) Display learned information for all 
VLANs or for the specified VLAN. 


matching matching—(Optional) Display routing table entries matching the specified prefix or prefix length. 
multicast—(Optional) Display routing table entries for multicast routes. 


table —(Optional) Display route entries for all the routing tables in the main routing instance or for the 
specified routing instance. If your device supports logical systems, you can also display route entries 
for the specified logical system and routing instance. To view the routing instances on your device, 
use the show route instance command. 


vian (all | vian-name)—(Optional) Display information for all VLANs or for the specified VLAN. 


vpn vpn—(Optional) Display routing table entries for a specified VPN. 


Required Privilege Level 


view 


RELATED DOCUMENTATION 


show route instance 


List of Sample Output 

show route forwarding-table on page 2670 

show route forwarding-table detail on page 2672 

show route forwarding-table extensive (RPF) on page 2673 


Output Fields 

Table 67 on page 2423 lists the output fields for the show route forwarding-table command. Output fields 
are listed in the approximate order in which they appear. Field names might be abbreviated (as shown in 
parentheses) when no level of output is specified, or when the detail keyword is used instead of the 
extensive keyword. 


Table 102: show route forwarding-table Output Fields 


Field Name Field Description Level of Output 
Logical system Name of the logical system. This field is displayed if you specify the table All levels 
logical-system-name/routing-instance-name option on a device that is 


configured for and supports logical systems. 


Routing table Name of the routing table (for example, inet, inet6, mpls). All levels 
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Table 102: show route forwarding-table Output Fields (continued) 


Field Name Field Description Level of Output 


Enabled All levels 
protocols 
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Table 102: show route forwarding-table Output Fields (continued) 


Field Name 


Field Description Level of Output 


The features and protocols that have been enabled for a given routing 
table. This field can contain the following values: 


e BUM hashing—BUM hashing is enabled. 

e MAC Stats—Mac Statistics is enabled. 

e Bridging—Routing instance is a normal layer 2 bridge. 

e No VLAN—No VLANs are associated with the bridge domain. 


e All VLANs—The vlan-id all statement has been enabled for this bridge 
domain. 


e Single VLAN—Single VLAN ID is associated with the bridge domain. 


e MAC action drop—New MACs will be dropped when the MAC address 
limit is reached. 


e Dual VLAN—Dual VLAN tags are associated with the bridge domain 


e No local switching—No local switching is enabled for this routing 
instance.. 


e Learning disabled—Layer 2 learning is disabled for this routing instance. 


e MAC limit reached—The maximum number of MAC addresses that was 


configured for this routing instance has been reached. 
e VPLS—The VPLS protocol is enabled. 
e No IRB I2-copy—The no-irb-layer-2-copy feature is enabled for this 


routing instance. 
e ACKed by all peers—All peers have acknowledged this routing instance. 
e BUM Pruning—BUM pruning is enabled on the VPLS instance. 
e Def BD VXLAN—VXLAN is enabled for the default bridge domain. 
e EVPN—EVPN protocol is enabled for this routing instance. 


e Def BD OVSDB—Open vSwitch Database (OVSDB) is enabled on the 
default bridge domain. 


e Def BD Ingress replication—VXLAN ingress node replication is enabled 
on the default bridge domain. 


e L2 backhaul—Layer 2 backhaul is enabled. 

e FRR optimize—Fast reroute optimization 

e MAC pinning—MAC pinning is enabled for this bridge domain. 

e MAC Aging Timer—The MAC table aging time is set per routing instance. 


e EVPN VXLAN-This routing instance supports EVPN with VXLAN 
encapsulation. 


e PBBN—This routing instance is configured as a provider backbone 
bridged network. 


Table 102: show route forwarding-table Output Fields (continued) 


Field Name 


Address family 


Destination 


Route Type 
(Type) 


Route Reference 
(RtRef) 


Field Description Level of Output 


e PBN—This routing instance is configured as a provider bridge network. 
e ETREE—The ETREE protocol is enabled on this EVPN routing instance. 


e ARP/NDP suppression—EVPN ARP NDP suppression is enabled in this 
routing instance. 


e Def BD EVPN VXLAN—EVPN VXLAN is enabled for the default bridge 
domain. 


e MPLS control word—Control word is enabled for this MPLS routing 


instance. 
Address family (for example, IP, IPv6, ISO, MPLS, and VPLS). All levels 
Destination of the route. detail extensive 
How the route was placed into the forwarding table. When the detail All levels 


keyword is used, the route type might be abbreviated (as shown in 
parentheses): 


e cloned (clon)—(TCP or multicast only) Cloned route. 


e destination (dest)—Remote addresses directly reachable through an 
interface. 


e destination down (iddn)—Destination route for which the interface is 
unreachable. 


e interface cloned (ifcl)—Cloned route for which the interface is 


unreachable. 


e route down (ifdn)—Interface route for which the interface is 
unreachable. 


e ignore (ignr)—Ignore this route. 
e interface (intf)—Installed as a result of configuring an interface. 


e permanent (perm)—Routes installed by the kernel when the routing 
table is initialized. 


e user—Routes installed by the routing protocol process or as a result of 
the configuration. 


Number of routes to reference. detail extensive 
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Table 102: show route forwarding-table Output Fields (continued) 


Field Name 


Flags 


Next hop 


Next hop Type 
(Type) 


Field Description 


Route type flags: 


none—No flags are enabled. 

e accounting—Route has accounting enabled. 

e cached—Cache route. 

e incoming-iface interface-number—Check against incoming interface. 
e prefix load balance—Load balancing is enabled for this prefix. 


e rt nh decoupled—Route has been decoupled from the next hop to the 
destination. 


e sent to PFE—Route has been sent to the Packet Forwarding Engine. 


e static—Static route. 
IP address of the next hop to the destination. 


NOTE: For static routes that use point-to-point (P2P) outgoing interfaces, 


the next-hop address is not displayed in the output. 


Next-hop type. When the detail keyword is used, the next-hop type might 
be abbreviated (as indicated in parentheses): 


e broadcast (bcst)—Broadcast. 

e deny—Deny. 

e discard (dscd) —Discard. 

e hold—Next hop is waiting to be resolved into a unicast or multicast 
type. 

e indexed (idxd)—Indexed next hop. 

e indirect (indr)—Indirect next hop. 

e local (locl)—Local address on an interface. 

e routed multicast (mcrt)—Regular multicast next hop. 

e multicast (mcst)—Wire multicast next hop (limited to the LAN). 

e multicast discard (mdsc)—Multicast discard. 

e multicast group (mgrp)—Multicast group member. 

e receive (recv)—Receive. 

e reject (rjct)—Discard. An ICMP unreachable message was sent. 

e resolve (rslv)—Resolving the next hop. 

e unicast (ucst)—Unicast. 


e unilist (ulst)—List of unicast next hops. A packet sent to this next hop 
goes to any next hop in the list. 


Level of Output 


extensive 


detail extensive 


detail extensive 
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Table 102: show route forwarding-table Output Fields (continued) 


Field Name 


Index 


Route 
interface-index 


Reference 
(NhRef) 


Next-hop 
interface (Netif) 


Weight 


Balance 


RPF interface 


Field Description 


Software index of the next hop that is used to route the traffic for a given 
prefix. 


Logical interface index from which the route is learned. For example, for 
interface routes, this is the logical interface index of the route itself. For 
static routes, this field is zero. For routes learned through routing 

protocols, this is the logical interface index from which the route is learned. 


Number of routes that refer to this next hop. 


Interface used to reach the next hop. 


Value used to distinguish primary, secondary, and fast reroute backup 
routes. Weight information is available when MPLS label-switched path 
(LSP) link protection, node-link protection, or fast reroute is enabled, or 
when the standby state is enabled for secondary paths. A lower weight 
value is preferred. Among routes with the same weight value, load 
balancing is possible (see the Balance field description). 


Balance coefficient indicating how traffic of unequal cost is distributed 
among next hops when a router is performing unequal-cost load balancing. 
This information is available when you enable BGP multipath load 
balancing. 


List of interfaces from which the prefix can be accepted. Reverse path 
forwarding (RPF) information is displayed only when rpf-check is 
configured on the interface. 


| Sample Output 


show route forwarding-table 


user@host> show route forwarding-table 


Routing table: default.inet 


Internet: 


Destination 
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Level of Output 


detail extensive none 


extensive 


detail extensive none 


detail extensive none 


extensive 


extensive 


extensive 


Type RtRef Next hop Type Index NhRef Netif 


























default perm 0 ETC 46 4 

OR OROR 0/32 perm 0 dscd 44 il 

ITZ 16.1 0/24 ifdn 0 resly 608 1 ge-2/0/1.0 
172 1G 1 OY S2 iddn O 172,16.1.,0 recv 606 Ue 21/A0)/ele© 
U2 U6 1. 1/32 user 0 wIICI 46 4 

II2.16 1.1/7 32 elastase @ L772. 1LGo1.i lice 607 ) 

VIZ UG. 1. Ly 32 iddn © L7Z2 16> si IkeesiL 607 2 
7216, 255/32 iddn ) HEI GARI QIEIEGIEIE RIEIE BIEIE «= JOSIE 605 1 ge-2/0/1.0 
10.0.0.0/24 aLTaNie Je 0 rslv 616 1 ge-2/0/0.0 
NO PLORNORA OLAS dest OM ROR OPORTO recv 614 1 ge-2/0/0.0 
10.0.0.1/32 alae ae OO Or Ore: level 615 2 
10.0,0,1/32 dest OM O RO Orel: Loe 615 2 

10.0 .0.255/ 32 dest OPLOMOR OR 255 best Gulls 1 ge-2/0/0.0 
10,1,1,0/24 ifdn 0 mgiky 612 1 ge-2/0/1.0 
IM, i, 10/32 iddn QO L0,1.1.€ recv 610 1 ge-2/0/1.0 
IM i, 1, 1/32 user 0 Peace 46 4 

IQ 1,1 1/32 ALTE 3e 0 LO, t,t eel 611 2 

IO. 1.1/7 32 iddn O LO ,2,2.i lee Gi 2 
1@.1,1.255/ 32 iddn Q) SEE Rib QI SIE SIRI Girie §6=lo@Sic 609 ge >2/0)/aka0) 
10,206.0 0/16 user OP ROM ZO O63. 34 WOSE 419 20) iexgol0) . 0 
10,2090 0/16 user IO ia Ke ea2 9/8710 ucst AVL) 20 fxp0.0 

NOR AO SR OrO7/eles Aisne 0 rslv 418 i ego. 0 
10.209..0.0/ 32 dest OOP AOS TOR© recv 416 i xgolll, © 
10.2092, 131/32 fiom OOF AO S eee mlaselt oe 417 2 

10.2092 131/32 dest 0 10,209 .2.131 eel 417 2 

10,209,217 ,55/ 32 dest OOS SO ACh sbi sird2 ucst 435 il ixgqo0). 0 
OPA OOmosee4 27432 dest 0) Me 258 Wels Bisse S25 Cel ucst 434 i iExgol0)., 0 

10) -209.,63 . 254/32 dest OO ia Ke vea 98710 ucst ALLS) 20 fxp0.0 
10.209,63,255/ 32 dest 0 10 ,209).,635 255 bese 415 i exgol0) 50) 
10.827 0 .0/16 user OOM AOS 635.24 ucst 419 20 fxp0.0 
Routing table: iso 

ISO: 

Destination Type RtRef Next hop Type Index NhRef Netif 
default perm 0 Hea Gils a) als 

AV OO OSE CO ees OOM OO OOM ONO S00 OSTO LO AR S524) 527,08 1010) 

intf 0 Logi, 28 iL 

Routing table: inet6é 

Internet6: 

Destination Type RtRef Next hop Type Index NhRef Netif 





default perm 0 EWC 


6 dL 
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HEOOR S/S 
ODS 21 / 12S 


Routing table: 
MPLS: 
Interface. Label 
default 


ccc 


perm 0 


perm 0) seic0Z9 9 Al 


Type RtRef Next hop 


perm 0 


100004 (top) fe-0/0/1.0 


show route forwarding-table detail 


user@host> show route forwarding-table detail 


Routing table: 
LIM ESNEINENC 8 
Destination 
default 
default 
10,1 ,0/24 
10/32 
plod f 32 
L 255/32 
21.0/24 
1.21 ,0/ 32 
Oil, Lf 3Z 
10.21.21 255/32 
127 60.0.1/32 
I72,17 28.19/32 
VIZ p17 28.44/32 


ey es eS oe S&S 
KS) TSS) Te) RS) eS 











Routing table: 
MIME UE NSKC. § 
Destination 
default 
10.0.0. 
ORIG 
10.0. 
ORO 


0/8 
ORO? 
OMA 
0.4/32 


Routing table: 


inet 








Type RtRef Next hop 

user A Os Ms sSeSgioll g ils 

perm 0 

aLJone 36 O i 6340.21 

dest QO 10.1.1. e 

ALi i€ @ LO. Leib 

dest 0 10,112,255 

aimiteds O xr .3 50,231 

dest 0 10,21 ,21 .0 

ALINE i€ Q 10,21 21.1 

dest O 10.21.21.255 

aLIONE JE @ 127.0.0.1 

calom 1 192. WSs o4 p24 

clon I 192). IGS stn 24 
privatel__.inet 


iso 


Type RtRef Next hop 


perm 0 
align i€ 0 
dest OO RIOR Or© 
aLioE i€ OM ROR Or Ors 
dest 0 10.0.0.4 
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mdsc 4 il 
mcst 5 1 

Type Index NhRef Netif 

eqjet, 16 al 

Type Index NhRef Netif 

ucst 132 4 fxp0.0 

12 CAE 14 il 

ucst 322 1 s6=5/3/0.0 
recv 324 1 s©=5/3/0.0 
oes Sab Ht 

best 323 il $0=5/3/0.0 
ucst 326 1 66=5/3/0.0 
recv 328 1 $6=5/3/0.0 
Loe S25) il 

best 327 1 s6=5/3/0.0 
korenls 320 1 

ucst 132 4 fxp0.0 
ues 132 4 fxp0.0 

Type Index NhRef Netif 

ie Gi, 46 iL 

rslv 136 il iexgel . 0 
recv 134 il sExqoyil . 0 
korea’ 135 2 

lkorealk 135 2 
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TS OR 
Destination Type RtRef Next hop Type Index NhRef Netif 
default perm 0 rjct 38 1 


Routing table: inet6é 


Interneté6: 





Destination Type RtRef Next hop Type Index NhRef Netif 
default perm 0 iP FGAE. ia il 
eEOOS 3/8 perm 0 mdsc all 1 
EOS SIL /I12s perm 0) se1c0)2 9 9:41 mMcishte 7) il 


Routing table: mpls 





MP ES 
Destination Type RtRef Next hop Type Index NhRef Netif 
default perm 0 eqVeE De 1 


show route forwarding-table extensive (RPF) 


The next example is based on the following configuration, which enables an RPF check on all routes that 
are learned from this interface, including the interface route: 


SO=LVIL/@ 4 
bbe momo ment 
family inet { 
rpf—-check; 
adcdeass 1920.22) 308 
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CHAPTER 30 


PCEP Operational Commands 


IN THIS CHAPTER 


@ clear path-computation-client statistics | 2675 

@ request path-computation-client active-pce | 2677 
@ show isis spring sensor info | 2678 

@ show path-computation-client active-pce | 2681 
@ show path-computation-client Isp | 2686 

@ show path-computation-client statistics | 2692 

@ show path-computation-client status | 2700 

td 


show spring-traffic-engineering | 2703 
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| clear path-computation-client statistics 


Syntax 


clear path-computation-client statistics 
<pce-id | all> 


Release Information 

Statement introduced in Junos OS Release 12.3. 

Statement introduced in Junos OS Release 16.1R3 for QFX Series switches. 
Command introduced in Junos OS Release 17.1R1 for ACX Series routers. 


Description 
Clear Path Computation Element (PCE) statistics. 


Options 
pce-id—(Optional) Clear statistics of the specified PCE. 


all—(Optional) Clear statistics of all available PCEs configured on the path computation client (PCC). 


Required Privilege Level 
clear 


RELATED DOCUMENTATION 


show path-computation-client statistics | 2692 


List of Sample Output 
clear path-computation-client statistics pce-id on page 2675 
clear path-computation-client statistics all on page 2676 


Output Fields 


When you enter this command, you are not provided feedback on the status of your request. 


| Sample Output 


clear path-computation-client statistics pce-id 


user@host> clear path-computation-client statistics pce1 
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clear path-computation-client statistics all 


user@host> clear path-computation-client statistics all 
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| request path-computation-client active-pce 


Syntax 


request path-computation-client active-pce pce-id 


Release Information 

Command introduced in Junos OS Release 12.3. 

Command introduced in Junos OS Release 16.1R3 for QFX Series switches. 
Command introduced in Junos OS Release 17.1R1 for ACX Series routers. 


Description 


Request a new active Path Computation Element (PCE). 


Options 
pce-id—Unique user defined ID for this PCE. 


retry-delegation—Retry label-switched path (LSP) delegation 


Required Privilege Level 
request 


RELATED DOCUMENTATION 


show path-computation-client active-pce | 2681 


Output Fields 

This command produces no output. To verify the operation of the command, run the show 
path-computation-client active-pce before and after running the request path-computation-client 
active-pce command. 


2678 


| show isis spring sensor info 


Syntax 


show isis spring sensor info 
logical-system (all |logical-system-name) 


Release Information 
Command introduced in 19.1R1 on MX Series routers with MPC and MIC interfaces, and PTX series 
routers. 


Description 
Displays a list of sensors associated with the label IS-IS route and next hops for segment routing traffic. 
The command only displays the information related to the sensors and not the traffic statistics. 


Options 


none— Display the sensor information of an IS-IS SPRING route. 


logical-system (all | logical-system-name)—(Optional) Perform this operation on all logical systems or on a 
particular logical system. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


sensor-based-stats 
source-packet-routing (Protocols IS-IS and OSPF) 
Understanding Source Packet Routing in Networking (SPRING) 


List of Sample Output 
show isis spring sensor info on page 2679 


Output Fields 


Table 1 describes the output fields for the show isis spring sensor info command. Output fields are listed 
in the approximate order in which they appear. 


Table 103: show isis spring sensor info Output Fields 


Field Field Description 


Sensor-name Represents the router or interface that the sensor is associated with. 


Table 103: show isis spring sensor info Output Fields (continued) 


Field Field Description 


Sensor-id Unique number associated either with route or interface. 


| Sample Output 


show isis spring sensor info 


user@host> show isis spring sensor info 





Per-interface-per-member-link Ingress Sensor: 





Sensor-name 


aggr_ingress_intf_sensor 





Per-interface-per-member-link 


Sensor-id 
3221225484 





Egress Sensor: 





Sensor-name 
ge-0/0/0.0 
ge-0/0/1.0 
ge-0/0/2.0 


Per-sid Ingress Sensor: 





Sensor-name 
16 

17) 

18 

19 

20 

Pal 

BD 

23) 

24 

Zo 
400001 
400002 
400005 
400006 
400009 
400010 


Sensor-id 
3221225497 
3221225498 
SZAZIZ BAS AI9 


Sensor-id 


SAGNAZ ASE 
32212254 
SAGA 24 
32212254 
32212254 
32212254 
SZ AilZ 254 
AGMA ASE 
SZ 22254 
32212254 
32212254 
32212254 
32212254 
32212254 
SABINA ASE 





32212254 


78 
WE 
74 
iis 
82 
oo 
80 
81 
89 
90 
galt 
Qe 
87 
88 
gis) 
94 
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| show path-computation-client active-pce 


Syntax 


show path-computation-client active-pce 
<brief | detail> 


Release Information 

Command introduced in Junos OS Release 12.3. 

Command introduced in Junos OS Release 16.1R3 for QFX Series switches. 
Command introduced in Junos OS Release 17.1R1 for ACX Series routers. 


Description 


Displays information about the current active Path Computation Element (PCE). 


Options 


none—Display brief information about the current active PCE. 


brief | detail—(Optional) Display the specific level of output. 


Required Privilege Level 


view 


RELATED DOCUMENTATION 


request path-computation-client active-pce | 2677 


List of Sample Output 
show path-computation-client active-pce on page 2684 
show path-computation-client active-pce detail on page 2684 


Output Fields 


Table 104 on page 2681 describes the output fields for the show path-computation-client active-pce 
command. Output fields are listed in the approximate order in which they appear. 


Table 104: show path-computation-client active-pce Output Fields 


Level of 
Field Name Field Description Output 
IP address IP address of the current active PCE. All levels 


Priority Active PCE priority. All levels 


Table 104: show path-computation-client active-pce Output Fields (continued) 


Field Name 


PCE status 


Session type 


PCE-mastership 


PCRpts 


PCUpdates 


Local Keepalive 


timer 


Local Dead timer 


Remote 
Keepalive timer 


Field Description 


Active PCE state: 


e PCE_STATE_NEW- Initial PCEP session state. 


e PCE_STATE_RECONNECT-—Trying to re-establish TCP connection with the 
PCEP peer. 


e PCE_STATE_CONNECTING—Establishing TCP connection with the PCEP peer. 
e PCE_STATE_CONNECTED-—TCP connection established with the PCEP peer. 


e PCE_STATE_SYNC—Open messages exchanged with the PCEP peer and entering 
SYNC state. 


e PCE_STATE_UP—PCEP session established. 
Active PCE type: 


e PCE_TYPE_STATELESS—Does not learn LSP state information form PCC. 


e PCE_TYPE_STATEFUL—Uses LSP state information learned from PCCs to 
optimize path computations, but does not actively update LSP state. A PCC 
maintains synchronization with the PCE. 


e PCE_TYPE_STATEFULACTIVE—Uses LSP state information learned from PCCs 
to optimize path computations, and actively updates LSP parameters in those 
PCCs that delegate control of their LSPs to the PCE. 


PCE mastership state: 


e main—Current active PCE. 


e backup—Backup PCE. 


Number of PC report (PCRpt) messages sent by PCC to a stateful PCE to report 
current state of LSP(s). 


Number of PC update (PCUpd) messages sent by a PCE to a PCC to update LSP 
parameters. 


Keepalive timer used by or for the PCC. 


Dead timer used by or for the PCC. 


Keepalive timer used by or for the PCE. 
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Level of 
Output 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


Table 104: show path-computation-client active-pce Output Fields (continued) 


Field Name 


Remote Dead 


timer 


PCErr-recv 


Max unknown 


messages 


Keepalives 
received 


Keepalives sent 


Dead timer 


Elapsed as main 
current 


Elapsed as main 
total 


Unknown 
msgs/min rate 


Session failures 


Delegation 
timeout in 


Delegation 
failures 


Connection down 


PCErr-sent 


Field Description 


Dead timer used by or for the PCE. 


Information about type, value, and number of PC Error messages received. 


Maximum number of unknown messages received for a PCEP session. 


Recommended value is 5. If the number of unknown messages received by a PCC 
or PCE is greater than or equal to the maximum number, the PCEP session is 


closed. 


Number of Keepalive messages received by a PCC from a PCE. 


Number of Keepalive messages sent by a PCC to a PCE. 


Dead timer used by the current active PCE. 


Time (in seconds) the PCE is in the main mastership state. 


Time (in seconds) the PCE became main from the last PCCD restart. 


Number of unknown messages received per minute. 


Number of PCEP session failures with the PCE. 


Time (in seconds) left for LSP delegation to timeout. 


Number of LSP delegation failures. 


Time (in seconds) since the PCEP session is down. 


Information about type, value, and number of PC Error messages sent. 
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Level of 
Output 


All levels 


All levels 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


All levels 


| Sample Output 


show path-computation-client active-pce 


user@host> show path-computation-client active-pce 





PCE pcel 
General 

IP address 
PICU GIELC 
PCE Status 


Session type 





Counters 


PCRegs 


PCReps 


PCRpts 








PCUpdates 


Timers 
Local 


Remote 





lthigierovies) 
IClieie IOC 
PIC Pirate SS mite 
ISISS E 
ICE SCC INES) 
POC PCa =I 

















PCE-mastership 


105209. 57s os 


























EFULACTIV 











last 


last 


last 


2 
PCE_STATE_NEW 
PCE _ TYPE STAT 
main 

Total: 0 

Total: 0 

Total: 0 

Toes (0) 


Keepalive timer: 


Keepalive timer: 


Ig) Value: 3 


show path-computation-client active-pce detail 


last 








Smee) last 

Brians (0) last 

Brains (0) last 

Siialing (0) last 

[s] Dead timer: 

[s] Dead timer: 
Count ae 


user@host> show path-computation-client active-pce detail 





PCE pcel 
General 
IP address 


PIES OEE 


V2 22 2S o O93 
al 


nour: 


Nour : 


Nour : 





nour: 
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ACh Sicacus) PCE_STATE_RECONNECT 
Session type PCE_TYPE_STATEFULACTIVE 
PCE-mastership main 
ax unknown messages i) 
Keepalives received 0 
Keepalives sent 0 
Dead timer O [sy] 
Elapsed as main current 1 [Ss] 
Elapsed as main total 2542 esi 
Unknown msgs/min rate 0 
Session failures B75 
Delegation timeout in 14 fs] 
Delegation failures DAZ 
Connection down Le [sy 
Counters 
PCReqs dla@ece ae O) last 5min: 0 
PCReps a@ ie ce aa O) last 5min: 0 
PCRpts Weyjeadls Silla lasic Simaling 7243 
7243 
PCUpdates tecals 80) last 5min: 40 
Timers 
Local Keepalive timer: 30 [si] Dead timer: 
Remote Keepalive timer: 30 [si] Dead timer: 
lieweOueS) 
ICihisie 1K 
I Ciicie = sKerane 
Type: 1 Value: 2 Count: 
PCH =2CCIN eS 
PCC IN ES 


12 


last hour: 


last hour: 


last hour: 


llasic levoiblies 


120 
120 


40 


(Sl 
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| show path-computation-client Isp 


Syntax 


show path-computation-client Isp 
<extensive> 


<p2mp> 


Release Information 
Command introduced in Junos OS Release 17.2R1 on MX Series routers. 
extensive and p2mp options introduced in Junos OS Release 18.3R1 on MX Series routers. 


Description 
Display the state of label-switched paths (LSPs) known to the Path Computation Client (PCC). 


Options 


none—Display information about LSPs known to the PCC. 


extensive—(Optional) Display extensive level of output about each known LSP - point-to-point and 
point-to-multipoint LSPs. 


p2mp—(Optional) Display information about known point-to-multipoint Path Computation Element 
(PCE)-initiated LSPs. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


show path-computation-client active-pce | 2681 
show path-computation-client statistics | 2692 


show path-computation-client status | 2700 


List of Sample Output 

show path-computation-client Isp on page 2689 

show path-computation-client Isp p2mp on page 2689 

show path-computation-client Isp extensive (PCE-Initiated Point-to-Multipoint LSP Mapping to 
MVPN) on page 2690 


Output Fields 


Table 105 on page 2687 describes the output fields for the show path-computation-client Isp command. 
Output fields are listed in the approximate order in which they appear. 
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Table 105: show path-computation-client Isp Output Fields 


Field Name 


LSP Name 


Status 


PLSP-Id 


LSP-Type 


Controller 


Path-Setup-Type 


Template 


P2MP name 


P2MP Branch Name 


PathName 


From 


To 


State 


Active Path 


Link Protection 


Field Description 


Name of the LSP. 


LSP status: 


e Primary(Act)—Primary LSP. 
e Bypass—PCE-initiated bypass LSP. 


PCEP-specific unique identifier for each LSP. The ID is created by the PCC for the 
lifetime of a PCEP session. 


Type of LSP: 


e External provisioned 


e Local 


Name of the external path computing entity. 


Protocol used to set up the LSP: 


e RSVP-TE 
e SPRING-TE 


Name of template used. 


Name of the point-to-multipoint tree that includes the sub-LSPs of the PCE-initiated 
LSP. 


Name of the branch sub-LSP that makes up the point-to-multipoint tree of the 
PCE-initiated LSP. 


Name of LSP path. 


Ingress IP address of LSP. 


Egress IP address of LSP. 


LSP state: up, down. 


Name of active path. 


LSP Link protection. 
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Table 105: show path-computation-client Isp Output Fields (continued) 


Field Name 


P2mp tree 


Path cspf status 


LSP-ID 


RSVP Error 


Priorities 


Bandwidth 


Requested AutoBw 


Controller 


Record Route 


From PCE ERO (received) 


From RPD ERO (reported) 


Configured ERO on PCC 


PCE Traffic Steering 


FS-ID 


Route Distinguisher 


Source Prefix 


Multicast Group Prefix 


State 


Last Rpt/Pcreqest received from 
RPD at 


Last Update sent to PCE at 


Field Description 


Name of the point-to-multipoint tree that includes the sub-LSPs of the PCE-initiated 
LSP. 


CSPF computation done by an external controller or local router. 


LSP identifier. 


RSVP error ID. 


Setup and hold priorities. 


LSP bandwidth. 


Requested bandwidth to controller for auto-bandwidth. 


Name of external controller. 


LSP record route object. 


Explicit Route Object (ERO) received by controller from the routing protocol process. 


ERO reported from the routing protocol process. 


ERO configured on router. 


MVPN flow specification capability. 


Flow specification ID. 


Route Distinguisher of MVPN instance. 


Matching source address of MVPN flow specification. 


Matching group address of MVPN flow specification. 


Flow specification state of specific flow specification ID. 


Time the last PC report or PE request message was received. 


Time the last update was sent to PCE. 


Table 105: show path-computation-client Isp Output Fields (continued) 


Field Name 


Last PcUpdate/PcCreate 
received from PCE at 


Last error sent to PCE at 


Last 5 reasons to send 
Report/Pcrequest 


| Sample Output 


Field Description 


Time the last PC update message was received from the controller. 


Time the last PC error was sent to the controller. 


e Reconfig 
e Down 

e Get_info 
e Up 


Active 


show path-computation-client Isp 


user@host> show path-computation-client Isp 


Name Status 


Path-Setup-Type 


ispl Primary (Act) 


default_pvc = 


lspl Bypass 


PLS Ie! LSP-Type Controller 
Template p2mp-name 

al ext-provised pcel 

2 ext—provised peel 


default_pvc = 


show path-computation-client Isp p2mp 


user@host> show path-computation-client Isp p2mp 


P2MP Branch Name: 


P2MP Branch Name: 











P2MP Branch Name: 


P2MP name: p2mp_treel 


P2MP name: p2mp_tree2 


p2mp_treel_leafl 


p2mp_treel_leaf2 


p2mp_tree2_leafl 


rsvp 


rsvp 
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P2MP Branch Name: 


p2mp_tree2_leaf2 


show path-computation-client Isp extensive (PCE-Initiated Point-to-Multipoint LSP Mapping to MVPN) 


user@host> show path-computation-client Isp extensive 


LSP Name 

PathName 

128 220 410,163 te 
Active Path 


From 


Link Protection none 
LSP Type 


P2mp tree 





Path cspf status 
Template 
2 1bjSy2)— 01D) 
ILySie) IE) 
RSVP 





Error 
Priorities 
Bandwidth 
Requested AutoBw 

















Controller 

Record Route 

1,1,0.0 (Ss) 
From PCE ERO (received) 
From RPD ERO (reported) 
Configured ERO on PCC 
PCE Traffic Steering 


S13 iL 
Route Distinguisher 
Source Prefix. 
Multicast Group Prefix 
State 

wS=lD3 2 
Route Distinguisher. 
Source Prefix. 
Multicast Group Prefix 
Sieaes 


Last Rpt/Pcregest received 





Last Update sent to PCE at 





lsp_test 
primary 
1A «2210-10. 1Si Saws = Wis 


primary 


ext-—provised 
p2mp_test 
external_cspft 
default_pvc 

2 

il 

0x0 

0 

98760 

0 

pcel 
Le4.0-2(8) Lel.O.4(8) So720c2(8) Del. 0.408) 7o8sO.2(S) 
123,220 . 10. 15 (ih) 
1235220 5110.15 (ib) 


128) 5420) 5 10) LS (ib) 





He SASL IL 8 L2.S) 
10.220 ,10 15/24 
HORA One Oras 2274) 


Active (MVPN instance configured) 


A) SANS) AL IL g 12} S} 

10.220 ,10 15/24 

10.220, 10 12/24 

Inactive (MVPN S,G already exist) 
23:46:12.000 
05:30:00.000 


from RPD at 





Last PcUpdate/PcCreat 


error sent to PCE at 








Last 


received from PCE at 





ADRAC BLA «OOO 
05:30:00.000 
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| show path-computation-client statistics 


Syntax 


show path-computation-client statistics 
<brief | detail> 


<all> 


Release Information 

Command introduced in Junos OS Release 12.3. 

Command introduced in Junos OS Release 16.1R3 for QFX Series switches. 
Command introduced in Junos OS Release 17.1R1 for ACX Series routers. 


Description 


Display statistics about the Path Computation Element (PCE). 


Options 
none—Display statistics about the primary PCE. 


brief | detail—(Optional) Display the specific level of output. 


all—(Optional) Display the statistics about all PCEs configured on the PCC. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


clear path-computation-client statistics | 2675 


List of Sample Output 

show path-computation-client statistics all on page 2695 

show path-computation-client statistics detail on page 2697 

show path-computation-client statistics (PCE-Initiated Point-to-Multipoint LSP Mapping to 
MVPN) on page 2698 


Output Fields 


Table 106 on page 2693 describes the output fields for the show path-computation-client statistics command. 
Output fields are listed in the approximate order in which they appear. 


Table 106: show path-computation-client statistics Output Fields 


Field Name 


IP address 


Priority 


PCE status 


Session type 


PCE-mastership 


Field Description Level of Output 
IP address of the PCE. All levels 
PCE priority. All levels 
PCE state: All levels 


e PCE_STATE_NEW- Initial PCEP session 
state. 

e PCE_STATE_RECONNECT-—Trying to 
re-establish TCP connection with the PCEP 
peer. 

e PCE_STATE_CONNECTING—Establishing 
TCP connection with the PCEP peer. 

e PCE_STATE_CONNECTED—TCP connection 
established with the PCEP peer. 

e PCE_STATE_SYNC—Open messages 
exchanged with the PCEP peer and entering 
SYNC state. 


e PCE_STATE_UP—PCEP session established. 
Active PCE type: All levels 


e PCE_TYPE_STATELESS—Does not learn LSP 
state information form PCC. 

e PCE_TYPE_STATEFUL—Uses LSP state 
information learned from PCCs to optimize 
path computations, but does not actively 
update LSP state. A PCC maintains 
synchronization with the PCE. 


e PCE_TYPE_STATEFULACTIVE—Uses LSP 
state information learned from PCCs to 
optimize path computations, and actively 
updates LSP parameters in those PCCs that 
delegate control of their LSPs to the PCE. 


PCE mastership state: All levels 


e main 
e primary 


e backup 
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Table 106: show path-computation-client statistics Output Fields (continued) 


Field Name 


PCRpts 


PCUpdates 


Local Keepalive 


timer 


Local Dead timer 


Remote 


Keepalive timer 


Remote Dead 
timer 


PCErr-recv 


PCErr-sent 


Max unknown 
messages 


Keepalives 
received 


Keepalives sent 


Elapsed as main 


current 


Elapsed as main 
total 


Field Description 


Number of PC report (PCRpt) messages sent 
by PCC to a stateful PCE to report current state 
of LSP(s). 


Number of PC update (PCUpd) messages sent 
by a PCE to a PCC to update LSP parameters. 


Keepalive timer used by or for the PCC. 


Dead timer used by or for the PCC. 


Keepalive timer used by or for the PCE. 


Dead timer used by or for the PCE. 


Information about type, value, and number of 
PC Error messages received. 


Information about type, value, and number of 
PC Error messages sent. 


Maximum number of unknown messages 
received for a PCEP session. Recommended 
value is 5. If the number of unknown messages 
received by a PCC or PCE is greater than or 
equal to the maximum number, the PCEP 
session is closed. 


Number of Keepalive messages received by a 
PCC from a PCE. 


Number of Keepalive messages sent by a PCC 
to a PCE. 


Time (in seconds) the PCE is in the main 
mastership state. 


Time (in seconds) the PCE became main from 
the last PCCD restart. 


Level of Output 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


All levels 


detail 


detail 


detail 


detail 


detail 
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Table 106: show path-computation-client statistics Output Fields (continued) 


Field Name 


Unknown 
msgs/min rate 


Session failures 


Delegation 
timeout in 


Delegation 
failures 


Connection down 


Local IP address 


LSP provisioning 
allowed 


P2MP LSP report 
allowed 


P2MP LSP 
update allowed 


P2MP LSP init 
allowed 


PCE Traffic 
Steering 


Field Description 


Number of unknown messages received per 
minute. 


Number of PCEP session failures with the PCE. 


Time (in seconds) left for LSP delegation to 
timeout. 

Number of LSP delegation failures. 

Time (in seconds) since the PCEP session is 
down. 


IP address of the PCC. 


LSP provisioning capability. 


Report capability of point-to-multipoint LSP. 


Update capability of point-to-multipoint LSP. 


Initiate capability of point-to-multipoint LSP. 


Traffic steering capability of the PCE. 


| Sample Output 


show path-computation-client statistics all 


user@host> show path-computation-client statistics all 





PCE pcel 


Level of Output 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 


detail 
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General 
IP address 
Priority 
PiCEwesieciets: 


Session type 





PCE-mastership 


Counters 


PCReqs 


PCReps 


PCRs 





PCUpdates 


Timers 
Local 


Remote 





lihi@ierouiess) 

IC Mei 1 SKN 
ICE 1 =SSIME 
PC PCC = INES 
RECSE CHS NES 




















PCE pce2 


General 
IP address 
DIPLO IIE 
PC ime sie etsy 


Session type 





PCE-mastership 


Counters 


PCReqgs 


PCReps 


PCRpts 








PCUpdates 








main 
uMo}or- Wren 0) Lasiz Simaae 
roils (0) devsic Symalin 
rorale ©) last 5min: 
totals 0 lFalsiteweomelbrass 
Keepalive timer: 0 Is] 
Keepalive timer: @ Is] 
10,31.32.i1 
10 
PCE_STATE_NEW 
PCE_TYPE_STATEFULACTIV 
backup 
Total: 0 Jasiz Simatims 
EoEals 0) ECS tee melee 
recalls (0) last 5min: 
lotals 0 Hfalsitewomelbrass 


10) -2A09) 5 Sl 5 LOG 
2B 
PCE_STATE_NEW 




















PCE_TYPE_STATEFULACTIV 


















































0 LASic 
0 last 
0 last 
0 last 


Dead timer: 


Dead timer: 


0 Last 
0 last 
0 last 
0 last 








lovoublie 8 


layeyblie B 


laveyblse B 


loy@yelie 8 


iIn@ukiats 


loyonblie 8 


layeyblie B 


lovoyblie 8 
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Timers 
Local Keepalive timer: 0 Is] Dead timer: 
Remote Keepalive timer: 0 [sl Dead timer: 
Hes Ones) 





12(Clibie Ie IRSA 
RIC hirate SS mite 
C= ICC INNS 
POC = 2a =I 

















show path-computation-client statistics detail 


user@host> show path-computation-client statistics detail 


PCE 





pcel 
General 

IP address 
PicLOrswLicy 
PCih Siesicws 


Session type 





PCE-mastership 


ax unknown messages 





Keepalives received 
Keepalives sent 

Dead timer 

Elapsed as main current 


Elapsed as main total 


ILO), 210). BY! 6 ISS 
2 

PCE_STATE_NEW 
PCE_TYPE_STATEFULACTIVE 
































main 

> 

0 

0 

OMeSa 
294 [s] 
294 [s] 


Unknown 
Session 


Replies 


msgs/min rate 
failures 


timedout 


Coun 


Delegation timeout in 





Delegation failures 


Connection down 











ters 
PCReqs Total: 
PCReps Total: 
PCRDpES Total: 
PCUpdates Total: 


fs 


fs] 


last 5min: 0 


Smee 0) 


last 


asics omen 





last 5min: 0 


las 


las 


last 


last 





c Joos 


c leyeyulie 8 


layoyblse B 


loveyblig 8 
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Timers 
Local Keepalive timer: 0 Is] Dead timer: 
Remote Keepalive timer: 0 [sl Dead timer: 
Hes Ones) 





12(Clibie Ie IRSA 
RIC hirate SS mite 
C= ICC INNS 
POC = 2a =I 

















show path-computation-client statistics (PCE-Initiated Point-to-Multipoint LSP Mapping to MVPN) 


user@host> show path-computation-client statistics 























PCE pcel 
General 
PCE IP address § 10, 220,11 58 
Local IP address 8 128.220.1156 
PISO eILiIOW 20 
PCE status 8 eC l, _SaryNiris (UI) 
Session type : PCE_TYPE_STATEFULACTIVE 

















LSP provisioning allowed : On 








P2MP LSP report allowed : On 
P2MP LSP update allowed : On 
P2MP LSP init allowed 8 lOnEi 
PCE-mastership : main 
PCE Traffic Steering : On 


Counters 











Se oe Se & © 


PCReqs Tocals @ alsiaomesnicmn 0) asic. Inoue s 

PCReps Toceis © laste Susling © Hesic laeulie g 

PERDES Total: 4 last 5min: 0 FATS eam orulbrars 

PCUpdates Hoceig 2 last 5min: 0 Fats n@Uunras 

PCCLSACSS ToOcais i Haste vom 0 Iausic. Inia § 
Timers 

Local Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 
S00 si 

Remote Keepalive timer: 30 [s] Dead timer: 120 [s] LSP cleanup timer: 


@ [sl 
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| show path-computation-client status 


Syntax 


show path-computation-client status 


<extensive> 


Release Information 
Command introduced in Junos OS Release 17.2R1 on MX Series routers. 
extensive option introduced in Junos OS Release 18.3R1 on MX Series routers. 


Description 
Display the status of the Path Computation Client (PCC). 


Options 
none—Display the status of the PCC. 


extensive—(Optional) Display extensive information about the PCC including point-to-point and 
point-to-multipoint PCE-initiated LSPs. 


For point-to-multipoint PCE-initiated LSPs, the extensive output displays the point-to-multipoint LSP 
tree and branches separately for a PCEP session. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


show path-computation-client active-pce | 2681 
show path-computation-client statistics | 2692 


show path-computation-client Isp | 2686 


List of Sample Output 
show path-computation-client status on page 2701 


Output Fields 


Table 107 on page 2701 describes the output fields for the show path-computation-client status command. 
Output fields are listed in the approximate order in which they appear. 
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Table 107: show path-computation-client status Output Fields 


Field Name Field Description 

Session Name of the PCE with which the PCEP session is established. 
Type Type of PCE. 

Provisioning Provisioning status of the PCE. 

Status PCEP session status. 

Total number of LSPs Number of LSPs in total. 

Static LSPs Status of point-to-point and point-to-multipoint static LSPs. 


Externally controlled LSPs | Status of point-to-point and point-to-multipoint LSPs that are controlled by a PCE. 


Externally provisioned Status of point-to-point and point-to-multipoint LSPs that are provisioned by a PCE. 
LSPs 


Orphaned LSPs Status of LSPs that are in the orphaned state because of PCEP session failure. 
Delegated Status of point-to-point and point-to-multipoint LSPs that are delegated to the PCE by 
the PCC. 


| Sample Output 


show path-computation-client status 


user@host> show path-computation-client status extensive 


Session Type Provisioning Status 


peel Stateful Active On Up 


LSP Summary 


Total number of LSPs 3 0) 
SEATING SPs e 0 
P2P 3 6) 


0/0 (primary/bypass) 
P2MP : 0/0 (branches/trees) 
Externally controlled LSPs cam) 
Bae 5 @ 





2702 





2703 


| show spring-traffic-engineering 
Syntax 


show spring-traffic-engineering (Isp | overview | sbfd) 
<brief | detail> 

<logical-system (all | logical-system-name)> 

<name Isp-name> 


Release Information 
Command introduced in Junos OS Release 17.2 on MX Series routers. 
sbfd option introduced in Junos OS Release 19.4R1 on all platforms. 


Description 


Display ingress details of SPRING traffic engineering. 


Options 
brief | detail—(Optional) Display the specific level of output. 


Isp—Display details of SPRING traffic-engineered LSPs on the ingress router or the Path Computation 
Client (PCC). 


overview—Display overview of SPRING traffic-engineered LSPs on the ingress router, or the PCC. 
sbfd—Display the SPRING traffic-engineered BFD session. 


name Isp-name—(Optional) Regular expression for LSP names to match for displaying SPRING 
traffic-engineering details. 


Required Privilege Level 
view 


RELATED DOCUMENTATION 


Enable Segment Routing for the Path Computation Element Protocol | 1431 


List of Sample Output 

show spring-traffic-engineering Isp name on page 2705 

show spring-traffic-engineering Isp detail on page 2706 

show spring-traffic-engineering Isp detail (BGP-SR-TE policies based tunnel) on page 2706 

show spring-traffic-engineering Isp detail (BGP-SR-TE policies based colored tunnels) on page 2708 
show spring-traffic-engineering Isp detail (BGP-SRTE filter in tunnel source) on page 2709 

show spring-traffic-engineering Isp detail (PCE-Delegated LSPs) on page 2709 

show spring-traffic-engineering overview on page 2709 
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show spring-traffic-engineering sbfd detail on page 2709 
show spring-traffic-engineering Isp detail name <name> on page 2710 


Output Fields 


Table 108 on page 2704 describes the output fields for the show spring-traffic-engineering command. Output 


fields are listed in the approximate order in which they appear. 


Table 108: show spring-traffic-engineering Output Fields 


Field Name 


To 


State 


LSP Name 


S-ERO 


Bandwidth 


Delegation info 


Field Description 


IP address of the SR-TE LSP destination. 


State of the SR-TE LSP: 


e Up 


e Down 


Name of the SR-TE LSP. 


Source Explicit Route Object (ERO), or LSP path. 


Bandwidth allocated for the SR-TE LSP. 


LSP control and routing status: 


e Control-status: 
e Externally controlled—PCE has control of the source-routing path. 


This can happen when: 


e The Isp-external-controller pccd statement is configured either under 
the source-routing path or under the primary segment list. 


e The request path-computation-client retry-delegation Isp-name 
command is issued for a delegated LSP that was not previously 
controlled by the PCE. 

e Locally controlled—PCC has control of the source-routing path. 


This can happen when: 


e The PCE has returned the control of the source-routing path. 


e Delegation timer with the PCE has expired. 


e Routing-status: Applicable to delegated source-routing paths only. 


e Externally routed—PCE provided the ERO for the source-routing path 
for a delegated LSP through PCUpdate. 


e Locally routed—PCE does not provide ERO for the source-routing path. 


2705 


Table 108: show spring-traffic-engineering Output Fields (continued) 


Field Name 


Route preference 


Number of LSPs 


External controllers 


BFD name 


BFD status 


Referencing LSPs 


SR-ERO hop count 


Hop 1 


Total displayed BFD sessions 


Tunnel source 


Ingress telemetry statistics 


Transit telemetry statistics 


ERO Valid 


Field Description 


Route preference of the SR-TE LSP. 


Statistics of the total number of SR-TE LSPs and the LSP state. 


Name of the LSP external controller. By default the only supported external 


controller is pcecd. 


Name of the BFD session. The name is auto-generated in the 
V4-srte_bfd_session-id for IPv6. 


The name is based on the Explicit Route Object (ERO) stack of the LSP path, 
that is, if multiple LSPs have same path they share the same BFD session 
name. 


Status of the BFD session: UP, DOWN. 


Name of referencing LSP. If the LSP does not have a path name, then the 
referencing LSP is displayed as unnamed path. 


Number of hops in the segment routing ERO. 


Represents the path of the BFD session. If any other LSP is on same path, it 
has the same BFD session. 


Total count of all the BFD sessions. 


Source of the tunnel configuration; for example, static configuration. 


Ingress telemetry statistics including the sensor name and ID. 


Transit telemetry statistics including the sensor name and ID. 


Indicates whether the received explicit route object (ERO) is valid or not. 


| Sample Output 


show spring-traffic-engineering Isp name 


user@host> show spring-traffic-engineering Isp name Isp-name 


To State LSP Name 
IO) 5 lk 5 ths 7 Up ico }RUl. 


show spring-traffic-engineering Isp detail 


user@host> show spring-traffic-engineering Isp detail 


MI). thy Ab a 7 
State: Up 


SSHNOg 24 oils, l(SOOOL) Oto les (4509) 125i. 4(9s75) 





Bandwidth: 100M 


The above line is in IP address(label) format. 


show spring-traffic-engineering Isp detail (BGP-SR-TE policies based tunnel) 


user@host> show spring-traffic-engineering Isp detail 


Name: tunnell15 

Tunnel-source: Static configuration 
TOS Oo6s656 

State: Up 





Retciag gil ILS—josenmesey 
Outgoing interface: NA 


Auto-translate status: Disabled Auto-translate result: 


Compute Status:Disabled , Compute Result:N/A , 
BFD status: N/A BFD name: N/A 
ERO Valid: true 





SREEROMMOpmCounicmS 





Beye il (Siera.eie)) < 
NAVE SEP VAN ACaacenc yelp us Of Om Ok OM eee len rte 
SID type: None 
nei 2 (SireiCie)) 8 
NAI: None 
SID type: 20-bit label, Value: 400050 
Ineo 3} (Sieweabete)) = 
NAT: None 
SID type: 20-bit label, Value: 400060 
Path sil > Sbackup 
Outgoing interface: ge-0/0/2.0 


Auto-translate status: Disabled Auto-translate result: 


Compute Status:Disabled , Compute Result:N/A , 
BFD status: N/A BFD name: N/A 
ERO Valid: true 





N/A 





Profile Name:N/A 


N/A 





Profile Name:N/A 
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SROEROMMOpmCouUniEcmS 


Hop 1 


NAIL: 


SID 
Hop 2 


NAIL: 


SD 
HOpas 


NAIL: 


SID 


(Sieieale@ic}) < 

ieWwl Melacsiney 10D, O.0.,0.0 => 21 .2.542 
type. None 

((Silesrasinoiten) ee 

None 
type: 20-bit label, Value: 400050 
(Sitieieic}) 8 

None 


type: 20-bit label, Value: 400060 


| =F hs ool Meet Mo bed eY-Kol able) 


Outgoing interface: ge-0/0/2.0 


Auto-translate status: Disabled Auto-translate result: 


Compute 


Status:Disabled , Compute Result:N/A , Comput 


BFD status: N/A BFD name: N/A 





ERO Valid: true 


SR-ERO© hop count: 3 





Hop 1 


NAIL: 


SID 
Hop 2 


NAIL: 


SLD 
Hop 3 


NAIL: 


SID 


Name: bgp- 





Tunnel-source: BGP SRTE 
MOS sats 


((Sitesraeikosites) ee 

IPy4l Aclijacesmoy ID, O.0.05,0 —S 2ila®oda# 
type: None 

(Sic iaLeic}) 3 

None 
type: 20-bit label, Value: 400050 
((Sitesrasineiten) me 

None 


type: 20-bit label, Value: 400060 


SweeE—0, 0.0 0-900 7 76%, Wola 





J-lill Stace: Ws <e> 


Outgoing interface: NA 


N/A 





Auto-translate status: Disabled Auto-translate result: 


BFD status: N/A BFD name: N/A 





ERO Valid: true 


SRS ROMMOpmCcounicnnsL 





Hop 1 


NAIL: 
SID type: 32-bit label, Value: 400050, TTL: 10, E 


Name: bgp- 





State: Up 


Tunnel—source: BGP SRTE 
TORE Stoo 


((Sitesrasineiten) ee 


None 





SreSs—0), 0.0, 0-900 —5 , 545, sail 





S=Wili<e> 


IAS) ie aL IL 


N/A 


Name:N/A 
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Outgoing interface: NA 
Auto-translate status: Disabled 
Auto-translate result: N/A 
BFD status: N/A BFD name: N/A 
ERO Valid: true 
SR-ER© hop count: 1 

Beye I (Sieraeie)) < 








NAI: None 


SID type: 32-bit label, Value: 400050, TTL: 10, Exp: 





Name: bgp-srte-0.0.0.0-900-6.6.6.6-111 





Tunnel—source: BGP SRT E 


@& 6.6,6,6—-lll<e> 
State: Up 


Outgoing interface: NA 
Auto-translate status: Disabled 
Auto-translate result: N/A 
BFD status: N/A BFD name: N/A 
ERO Valid: true 
SRE OmiO pm co uimier ame: 

Bley i (Sitwieis)) 2 

NAT: None 








SID type: 32-bit label, Value: 400050, TTL: 10, Exp: 





Total displayed LSPs: 4 (Up: 4, Down: 0) 


show spring-traffic-engineering Isp detail (BGP-SR-TE policies based colored tunnels) 


For colored tunnels, telemetry details is displayed. 


user@host> show spring-traffic-engineering Isp detail 


Name: bgp-srte-0.0.0.0-900-6.6.6.6-111 





Tunnel—source: BGP SRTE 


Oo: 





6565 656—1iLi 


State: Up Telemetry statistics: 
Sensor-neme: £42748-6.6.6.6-6f, Id: 3758096396 
Sensor-name: 6.6,6.6-6f, Id: 3758096395 


Outgoing interface: NA 


Auto-translate status: Disabled Auto-translate result: N/A 


BFD status: N/A BFD name: N/A 
ERO Valid: true 
SR-ERO hop count: 1 
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Iloye. IL (SieTeaSiE)) 8 
NAI: None 
SN) eyes SAloute Melos, Wellies AOOOSO, IWiting 10), jpeg IL 





show spring-traffic-engineering Isp detail (BGP-SRTE filter in tunnel source) 


user@host> show spring-traffic-engineering Isp detail 


show spring-traffic-engineering Isp detail (PCE-Delegated LSPs) 


user@host> show spring-traffic-engineering Isp detail 


srte_at_dlg_to_r5 

Oe 16 14s sei 

Name: srte_at_dlg_to_r5 
Tunnel-source: Static configuration 
to@g 123.220, 14.141 


State: Up 





Pathe SF auto to <5 
Outgoing interface: NA 
Delegation info: 


Control-status: Externally controlled 





Routing-status: Externally routed 
Auto-translate status: Disabled Auto-translate result: N/A 
BFD status: N/A BFD name: N/A 


show spring-traffic-engineering overview 


user@host> show spring-traffic-engineering overview 


Overview of SPRING-TE: 





| 


Route preference: 8 


Number of LSPs: 0 (Up: 0, Down: 0) 





External controllers: 


pecd 


show spring-traffic-engineering sbfd detail 


user@host> show spring-traffic-engineering sbfd detail 





BFD name: V4-srte_bfd_session-1 
BFD status: Down 
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Referencing LSPs: 
sie=Lsjoil sjosielatl 
Sia nso es Ochielnels 

SRS HROm Mop COlinits 





Rie i (Sibieeie)) ¢ 
IWAILS IP wal Acljeesimey ID, I.2,i,i1 = 1.2.1.2 
SID type: 20-bit label, Value: 299776 
Eig 2 (SiPeLCIE)) § 
IVAILG IP WA! AciieeSiney ID, 2.3,0,1 => 2.3.0.2 
SID type: 20-bit label, Value: 299824 





Total displayed BFD sessions: 2 (Up: 2, Down: 0) 


show spring-traffic-engineering Isp detail name <name> 


user@host> show spring-traffic-engineering Isp detail name sr_plcy1 


Name: sr_plcyl 


Tunnel source: Static configuration 





ates al sal g ales a 
State: Up 
Peiclas sli 


Ingress teleletry statistics: 
Semsor—Memes up siteOpitpsrjolevis sli, els S7Ss0IG3 
Transit teleletry statistics: 
SenisOG= Name ae er sitey1 Orne seme yur oHlele miclcmmon/ Slo O Ogawa 
Perelms siz 
Ingress teleletry statistics: 
SSmsoOr—Nemss apsicpOpissr jolevilssl2, ele SISsOOGS 0) 
Transit teleletry statistics: 
SEMSOrP-NeiNes ieASice Opps jolevwilpsl2, els S7SSOL Seu 





